简介基于C#的编组站调车系统是一份面向铁路运输信息化与C#开发学习者的完整项目资源适合用于理解编组站调车业务流程及Windows窗体程序的设计方法。资源包含完整Visual Studio工程共47个文件以16个.cs源码文件为核心涵盖窗体界面、业务逻辑与数据访问分层另有可执行exe直接运行观察效果txt说明文档记录操作思路resources/resx资源文件与配置文件保证项目编译运行完整。压缩包仅221KB轻量易用已有122人查看学习。项目通过隐藏与显示文本框的方式模拟货车在线路间的动态跳变直观展示了GUI控件控制与动画模拟技巧同时涉及登录窗体、主窗体、DAL与Model分层设计可作为综合运用集合、文件操作、事件驱动编程的练手项目。对希望掌握C#桌面应用开发、调度模拟系统设计的开发者有不错的参考价值。1. 先说结论基于C#的编组站调车系统解决的是“等排路、抄车号、对不上账”三件事编组站一个白班下来最耗调车区长精力的往往不是调车本身而是等排路、抄车号和对账。车还在到发线钩计划却要靠电话跟值班员、扳道员来回确认一钩溜放完了现车台账能不能跟上取决于底下人有没有记得报。基于C#的编组站调车系统做的是把“到达—解体—编组—出发”这条主线上最磨人的三件事——钩计划、车号核对、现车账目——收进一套桌面程序里让作业从人肉接力变成数据接力。这套东西适合谁还没上全套峰顶自动化系统的中小编组站、区段站货场兼办编组的车站以及车辆段取送车作业。这类场站不一定缺调车机缺的是一个能记录“现在每辆车在哪条股道第几位、下一步该干什么”的电子账本。用C#落地是因为现场跑的还是Windows要对接的设备接口又大多是串口和DLL这个场景本来就是C#上位机的舒适区。2. 拆需求编组站调车作业的主线、对象和C#选型的三个理由2.1 调车系统在干什么从到达解体到出发编组的作业主线编组站的作业主线并不复杂。一趟列车进到到发场后先做到达确报拿到完整的编组顺序然后调车机把车列牵出或推上牵出线按车辆去向把整列车切成若干组溜放到编组场对应的股道等出发方向的车集结得差不多了再把各股道上的车组连挂成一列做技检、试风拉到出发场。这条主线上现场的人最忙系统要管的信息流是六个节点到达确报、解体计划、钩计划、作业通知单、执行回执、现车更新。这里说的“钩”是调车作业的最小动作单位——把几辆车从车列中摘出、溜到另一条股道或者把两段车挂在一起都算一钩。一个白班下来一台调车机干几十钩到上百钩都很正常。系统要能回答的问题就两个下一钩去哪、刚才那一钩做完没有。回答不了这两个问题台账就是摆设。还要说清楚一个边界这套系统只做计划和台账的信息流不碰进路控制。车往哪条道走、信号怎么开放是联锁和车站行车组织的事调车系统别越界。2.2 按业务对象拆模块车号、股道、钩计划、现车台账调车系统里最核心的业务对象只有四个车、股道、钩计划、现车台账。这四个对象是相互咬合的。一辆车从A股道溜到B股道钩计划的状态要跟着变台账的顺序要跟着变如果程序里没把这三个变化放在一次事务里改就会出现“车动了台账没动”的翻车现场。常见做法是按对象拆模块不要按界面拆基础数据维护货车车号库车型、载重、轴数、换长、股道档案有效长、容车数、用途、封锁/禁溜/禁会标记、班组和人员。计划管理到达计划、出发计划、解体钩计划、编组钩计划。作业执行调车单生成、下发、确认、回执以及钩状态流转。现车管理按股道展示当前停放的车辆顺序支持溜放、连挂、牵出三类动作自动改账。统计与交接班钩数统计、作业时长、班次保留车数、交接班快照。这套边界划下来程序里的用户角色也就清楚了调车区长负责编计划和派单调车组负责收单和回执值班员盯现车和股道占用。三个角色对应到程序里就是计划模块、作业模块、现车监视三个界面别做成一个大杂烩窗体。2.3 技术选型为什么还是C#桌面端、设备接口与Access/SQL Server的现实选C#不是情怀是现场条件决定的。车站办公终端大量还是Windows 7和Windows 10 32位的老机器WinForms程序绿色部署、双击即用不需要装JRE、不需要配Web容器。数据文件用SQL Server Express或者Access的.accdb都可以直接拷贝备份车站的电务和信息技术人员看得懂,也敢动手。设备接口这一层是C#最明显的优势。轨道衡、车号自动识别AEI、防溜设备、平面无线调车灯显厂商多数给的是串口协议或者C/C的DLL。C#上位机用SerialPort和P/Invoke对接非常顺跟这些设备打交道本身就是C#工程师干惯了的活。换成Java或者Python光是封装一个厂商DLL的调用约定就要多花不少功夫。数据量方面一个中等编组站一天200钩现车台账也就是几千到上万条记录单机Access就能扛住。想要双机热备、断点续传再换成免费的SQL Server Express也不需要额外花钱买授权。选型结论通常是单站单机用Access起步等要接第二台终端或者做远程查询时再迁SQL Server表结构不用动C#代码里换个连接串就行。注意这类调车辅助系统只做计划与台账的信息流不参与进路控制。进路安全由联锁系统负责别把控制功能做进这套程序里。2.4 先跑通骨架三张基础表和一段建表SQL动手写界面之前我一般先把三张基础表建出来车辆档案表、股道档案表、钩计划表。这三张表能撑起“计划录入—拆钩—下发—回执—自动改现车”的最小闭环后面的模块都是在这个骨架上长出来的。-- 车辆档案表一车一条 CREATE TABLE tbl_Car ( CarNo VARCHAR(14) NOT NULL, -- 车号含车型字母全路唯一 CarType VARCHAR(10), -- 车型如 C64、P70 LoadFlag CHAR(1) DEFAULT E, -- E空车F重车 AxleCount INT DEFAULT 4, -- 轴数计算防溜和容车用 NoShuntFlag CHAR(1) DEFAULT N, -- Y禁溜车/关门车溜放时不能用 TrackNo INT, -- 当前股道冗余列台账展示快 Position INT, -- 股道内顺序位1为靠道口端 PRIMARY KEY (CarNo) ); -- 股道档案表 CREATE TABLE tbl_Track ( TrackNo INT PRIMARY KEY, TrackName VARCHAR(20), -- 显示名如“编3道” UseType VARCHAR(4), -- 到发/编组/存车/走行 EffLen INT, -- 有效长米 Capacity INT, -- 换算容车数 IsBlocked CHAR(1) DEFAULT N, -- Y封锁 NoHumpFlag CHAR(1) DEFAULT N, -- Y禁溜放 NoShuntFlag CHAR(1) DEFAULT N -- Y禁止调车作业 ); -- 钩计划表一条记录一个钩 CREATE TABLE tbl_Hook ( HookID INT IDENTITY PRIMARY KEY, TrainID VARCHAR(30), -- 开行ID日期车次到达时刻 TeamNo INT, -- 调车组/机车编号 HookSeq INT, -- 本作业内钩序 ActionType VARCHAR(4), -- HUMP溜放 COUPLE连挂 PULL牵出 SrcTrack INT, -- 源股道 DstTrack INT, -- 目标股道 CarCount INT, -- 本钩辆数 Status VARCHAR(4) DEFAULT PEND, -- PEND/DOING/DONE/CANCEL CreateTime DATETIME, DoneTime DATETIME );几个字段的逻辑说清楚。tbl_Car里冗余了TrackNo和Position看起来违反第三范式但现车台账的界面要频繁“按股道按顺序”整列展示冗余这两个字段能少两次联查。Position的语义是“从道口端数过来第几位”溜放一钩后后面整串车的Position都要前移这笔账必须在ApplyShunt里一次性算完。tbl_Hook里特别加了NoShuntFlag对应的字段提醒虽然它在车辆表里但钩计划的校验逻辑每钩都要查它别图省事只查股道容车数。骨架跑起来以后主界面就分三块左边按股道展示现车台账右边列待派的钩计划下面显示选中钩的明细和状态。能做到这一步一个可演示的最小系统就成立了后面加的模块不会推翻这个骨架。3. 核心算法钩计划生成与现车变更把这两块写对就成了一半3.1 钩计划生成股道存车约束下的“车厢移动清单”钩计划生成表面上是排顺序本质上是把一列“按现场顺序排列的车辆序列”切成若干连续段每段指定一个去向股道。因为溜放只能从车列端部逐钩连续进行钩序天然是线性的不能像排课表那样随意调换顺序。这也是为什么很多从订单系统转过来的开发会把钩计划做成“先定目标股道再排序”结果一到现场就被打回——物理动作决定了切分顺序。常见做法是半自动生成算法先把连续同去向的车组合并成一个候选钩再检查目标股道容车数、封锁状态和禁溜约束不满足的钩不自动拆直接标成“需人工确认”。这样既减少溜放次数又把安全判断留给人。public ListHookItem BuildHooks( ListCarInTrain cars, Dictionarystring, string carToDestTrack) { var hooks new ListHookItem(); int start 0; while (start cars.Count) { string dest carToDestTrack[cars[start].CarNo]; int end start; // 连续同去向的车合成一钩减少溜放次数 while (end 1 cars.Count carToDestTrack[cars[end 1].CarNo] dest) { end; } var hook new HookItem { Seq hooks.Count 1, DestTrack dest, StartIdx start, EndIdx end, NeedManual !ValidateTrack(dest, end - start 1, cars.GetRange(start, end - start 1)) }; hooks.Add(hook); start end 1; } return hooks; } private bool ValidateTrack(string destTrack, int carCount, ListCarInTrain group) { // 完整版要查库里三样东西 // 1) 目标股道未封锁 // 2) 目标股道剩余容车数 carCount // 3) 组内没有禁溜车/关门车 // 这里只写最小检查其余留给人工确认 return !group.Any(c c.NoShuntFlag Y); }这段代码的关键在两个地方。一是内层while把连续同去向的车合并成一钩这是提高解体效率的核心策略钩数越少调车机往返次数越少二是NeedManual标记而不是自动重排生产环境下“排错一钩”比“少排一钩”危险得多算法不确定时把决定权交还给调车区长界面标红让他确认。参数方面cars必须按现场车辆顺序传入不能按车号排序后又传进来carToDestTrack的映射来自到达确报里的到站/品类字段通常由调度员事先维护好“去向—股道”对照表。3.2 现车变更溜放、连挂、牵出对应三种数据结构操作现车台账用什么数据结构存直接决定改账逻辑好不好写。我用的是最朴素的方式每条股道一个ListCarInfo列表顺序就是股道内从道口到对岸的车辆顺序。三个调车动作对应三种列表操作溜放是源股道尾部取一组、挂到目标股道尾部连挂是目标股道整列挂到源股道尾部牵出是源股道靠道口一端取车、放到目标股道靠道口一端。public void ApplyShunt(ShuntAction action, TrackStore trackStore) { switch (action.ActionType) { case HUMP: // 溜放源股道尾部取一组 - 目标股道尾部 var group trackStore.PopTail(action.SrcTrack, action.CarCount); trackStore.AppendTail(action.DstTrack, group); break; case COUPLE: // 连挂目标股道整列挂到源股道车列尾部 var whole trackStore.TakeAll(action.DstTrack); trackStore.AppendTail(action.SrcTrack, whole); break; case PULL: // 牵出源股道靠道口一端取车 - 目标股道 var head trackStore.PopHead(action.SrcTrack, action.CarCount); trackStore.PrependHead(action.DstTrack, head); break; } trackStore.Version; // 每次变更全局版本1供增量同步使用 _audit.Append(new ShuntAuditRecord { Time DateTime.Now, Operator action.Operator, ActionType action.ActionType, SrcTrack action.SrcTrack, DstTrack action.DstTrack, CarCount action.CarCount }); }这三个动作的语义要跟现场工人的说法对齐。溜放从尾部取车因为溜放作业是把车列推到牵出线后车组从车列尾部逐段溜出牵出从头部取车因为牵出作业是机车带着靠咽喉区一端的一部分车转线连挂则是把另一条股道整列拉过来接上。代码里最容易踩坑的是方向搞反——如果现场把“道口端”定义成股道的另一端PopHead和PopTail全反台账会越改越乱。我一般会在股道档案里加一个字段注明“道口端方向”并在界面用箭头画出来。改账还有一个原则现车台账只能由回执驱动不能让人直接在台账界面上拖车改顺序。回执触发ApplyShunt审计表记一条版本号加一整个过程可回溯如果允许手拖出事后谁也说不清是哪一下改坏的。3.3 操作流与界面调车区长派单、现场收单、回执改账界面按三条栏来做比较顺手左侧是现车台账每个股道一行车号按顺序横向排列右上是待派的钩计划列表右下是当前选中钩的车辆明细和状态。调车区长选中一个计划点击“生成钩计划”系统按3.1的算法出钩序他逐个确认后选择调车组和机车点击派单。派单动作就是把钩计划落库并把状态置为PEND。现场终端的作业通知单可以做成网页也可以做C#精简客户端这个看终端硬件条件。每条钩在调车组侧有三个操作接单、开始、完成。接单时状态从PEND变DOING完成时从DOING变DONE同时把回执传回服务器触发ApplyShunt。状态流转的规则要写死不能让操作员跳状态。状态含义触发动作PEND计划已生成等待派单调车区长确认并派单DOING已开始执行本钩调车组点“开始”DONE本钩完成台账已变更调车组点“完成”并回传回执CANCEL计划取消/作废调车区长取消并写明原因现场网络差是常态终端离线时也要能收单和回执。常见做法是终端本地存一份作业缓存回执先落本地等网络恢复后按HookID批量上传服务器按ID去重。这个闭环能不能跑通决定了系统是“数字台账”还是“另一本手账”。4. 作业单下发与回执消息格式、增量同步和设备接入4.1 消息格式为什么落盘用XML、对外接口用JSON调车作业单是要跨终端传递的作业指令而且现场经常有离线作业、补传回执的场景消息必须“可缓存、可重发”不能依赖在线调用。常见做法是内部落盘用XML文件对外接口用JSON。XML在这条链路里的优势是Schema可校验、编码可控而且现场几年前的老终端即使没有JSON库也能读JSON则留给跟外部系统对接更轻量、更好解析。C#里做XML序列化很方便一个DTO加XmlRoot特性就行。下面是把一张作业单序列化成XML的核心代码[XmlRoot(WorkOrder)] public class WorkOrderMessage { [XmlAttribute(HookID)] public string HookID { get; set; } [XmlAttribute(Version)] public long MsgVersion { get; set; } [XmlElement(ActionType)] public string ActionType { get; set; } [XmlElement(SrcTrack)] public int SrcTrack { get; set; } [XmlElement(DstTrack)] public int DstTrack { get; set; } [XmlElement(CarCount)] public int CarCount { get; set; } [XmlElement(CarNumbers)] public string CarNumbers { get; set; } [XmlElement(Sign)] public string Sign { get; set; } } public string SerializeOrder(WorkOrderMessage msg) { var xs new XmlSerializer(typeof(WorkOrderMessage)); using var sw new StringWriter(); xs.Serialize(sw, msg); return sw.ToString(); }几个参数的讲究HookID必须全局唯一用“日期调车组HookSeq”生成它是幂等回执的凭据CarNumbers是车号拼接串终端收到后可以先本地比对车辆数再开工Sign是用HookID加Version加车号串做的哈希签名防现场有人手工塞一个假文件进来触发台账变更。文件命名建议用order_{HookID}_{Version}.xml终端按文件名就能判断版本不用打开文件体。到发确报如果是从既有系统带过来的Excel读的时候用NPOI或者ClosedXML不要用Office COM否则服务器上没装Office就直接罢工。对外接口如果用JSONC#端直接定义同名DTOSystem.Text.Json序列化就行字段务必和XML版保持一致免得两套字段名来回映射出错。4.2 增量同步与幂等回执C#代码里的三个关键点终端和服务器之间的同步最怕的不是网络断是“断完后续不上”。我采用的方案是全局版本号加增量拉取服务器每发生一次台账变更全局Version加一客户端每次拉取时上报自己本地已应用到的版本号服务器只返回比它新的数据。public ListWorkOrderMessage PullIncrement( string deviceId, long lastVersion) { return _db.WorkOrders .Where(o o.MsgVersion lastVersion) .OrderBy(o o.MsgVersion) .Take(200) // 一次最多拉200张防批量刷爆 .Select(o ToMessage(o)) .ToList(); } public bool SaveAck(string hookId, string ackResult) { if (_db.Acks.Any(a a.HookId hookId)) return false; // 幂等重复回执直接忽略 _db.Acks.Add(new AckRecord { HookId hookId, Result ackResult }); _db.SaveChanges(); ApplyHookDone(hookId); // 回执落库后才触发台账变更 return true; }这里三个关键点。第一增量查询条件用MsgVersion大于而不是用时间大于因为现场终端的时钟经常不准跨库比较时间没有任何可信度版本号是long型单调递增不存在回拨问题。第二Take(200)是给断点续传兜底的终端离线一整天后重新上线增量可能有上千条一口气全传过去会把老终端内存打爆客户端拿到一批后更新本地版本再带着新版本拉下一批。第三SaveAck的幂等不能只靠先查后插两个终端同时回执同一钩时存在并发窗口正确做法是给Acks表的HookId建唯一索引插入冲突就直接返回“已处理”。4.3 设备接入串口参数表与状态上报的留底原则调车系统要接的设备主要是车号自动识别AEI、轨道衡、防溜设备以及轨道占用状态的采集。这些设备大部分走串口参数是现场设备固死的不是程序想改就能改。常用的参数组合我整理成了一张表参数常见取值说明波特率9600 / 4800多数老设备固定9600新设备支持自适应数据位8少数老协议用7停止位1个别设备用2极罕见校验无 / 偶校验先看设备说明书猜了容易丢帧读超时500ms ~ 2000ms太短会把慢设备正常响应误判成断线重连间隔10s ~ 30s串口线接触不良时重连太快会刷日志刷爆AEI的对接逻辑通常是轨边设备触发后串口吐出一串车号和位置信息C#上位机接收后形成“车辆到达序列”再和到达确报里的“应有车号”做比对不一致就报“车号核对不符”让值班员人工介入。这个比对是替代人工抄号的关键一步别把它做成“只记录不提示”。轨道占用状态的上报要留底。程序收到的原始字节先写进原始报文表再做解析解析结果写状态事件表最后才影响现车台账。任何一步都不能直接改台账否则设备抖动一次台账就跟着错一次。解析状态字时按位拆用枚举把每一位的语义定义好别写一堆魔法数字在代码里到处飘。5. 避坑调车系统生产环境最常翻车的五个地方每条都是血泪经验5.1 同车次复用导致现车错乱问题出在开行ID没做够强的主键现象同一天两趟相同车次号的列车先后进站系统按车次查计划把后一趟的编组顺序盖到了前一趟车上现车台账整列串号。原因车次号不是唯一键。同一个车次在同一天会因上下行方向、区段运行图不同而出现两次如果不把“到达时刻”和“股道”纳入标识程序永远分不清这两趟车。解决给每趟车生成独立开行ID规则用“日期车次到达时刻精确到分钟”所有钩计划、回执、台账修改都挂这个ID查询只认它。车次号演变成展示字段不再参与任何逻辑判断。5.2 钩计划排好到现场“说不对”缺了股道约束和禁溜校验现象算法按去向分组合并生成了一份钩序现场反馈某钩溜不进去——目标股道已经有存车有效长不够或者钩组里混了一辆禁溜车。原因生成钩序时只看了“车辆去向相同”把目标股道的剩余容车数、封锁状态、禁溜/关门车约束全漏了。这是把钩计划当成排课表在排的通病。解决把ValidateTrack做成强制约束链先查目标股道未封锁再查剩余容车数够不够最后逐辆查组内有没有NoShuntFlag为Y的禁溜车。任一不满足就标NeedManual界面标红必须人工确认后才能派单。宁可让算法少排一钩也别让它排错一钩。5.3 现场终端显示旧台账增量同步的版本号被客户端拖死现象终端重启后显示的股道车列和调度室不一致刷新也无济于事过很久才恢复正常。原因客户端拿着自己缓存的旧版本号去拉增量服务器如果拿这个旧版本做基准中间跨越的版本会被当成“已同步”丢掉或者客户端版本号比服务器还高后续增量永远拉不到。解决版本号以服务器为唯一权威。客户端只上报“我看到的版本”服务器返回当前全局版本和增量列表客户端应用完直接把自己的本地版本覆盖成服务器的值。版本号用long型单调递增别用DateTime时间回拨一次就全乱。5.4 轨道占用闪烁误改了台账状态机没做消抖现象股道占用状态突然从空闲变成占用一秒后又跳回空闲系统在这段时间里把“占用”当成了真实溜放动作台账多出了几辆车。原因轨道电路或计轴设备受电气干扰串口丢帧后读到了异常状态字程序单次采样就直接写库。这就是典型的设备信号抖动。解决轨道占用状态用状态机管理空闲到占用必须连续N次采样确认才翻转N取3、采样间隔500ms起步翻转后把事件带时间戳写入EventLog台账变更与事件绑定事后可以逐帧回查。状态机这层消抖逻辑是设备接入层最值得花时间写对的地方。5.5 交接班两本账打架缺审计表的补课现象白班夜班交接时对不上现车A说溜了三钩、B说只收到两钩回执谁改过台账根本查不到。原因所有变更都是直接Update数据库记录没有审计表操作人、操作时间、变更前后内容全没留。解决第3章的ApplyShunt里强制写ShuntAudit表字段至少包括作业ID、操作人、动作类型、源/目标股道、辆数、时间戳。交接班时对每个股道打一次快照存表次日交班直接比对两次快照差异哪里对不上立刻定位到人、到钩、到时间。记录比解释重要这是这套系统最值得花的一笔投资。6. 验证与进阶让历史作业“重跑一遍”证明系统这次改对了6.1 回放模式算法层对不对让日志自己说话系统上线后最怕的不是没功能是“这次发版到底改坏没有”。我给系统加了一个回放模式把历史某一天的全部回执按原时间序重新执行一遍每一步调用ApplyShunt重算出当天的现车台账再和当天派单时保存的台账快照比对。两条账对得上算法层就是一致的对不上程序会把第一个不一致的钩子打印出来直接定位是哪个动作算错。这个回放跑在只读副本上不影响生产数据想跑几遍跑几遍。每次改完钩计划生成规则或现车变更逻辑我都先把过去一周的数据重放一遍再上现场比上线后拿真实作业去试错稳得多。6.2 模拟时钟压测把一昼夜的作业量塞进内存跑完真实现场没法加速时间但压测可以。做法是把系统里的时间源抽成一个可注入的Clock接口生产环境用真实时间测试环境用模拟时钟。模拟时钟连续推进24小时灌入上百张计划、上千钩回执跑完后检查股道列表的内存增长、版本号递增是否连续、增量同步是否丢数据。边界问题像“凌晨换班时来计划”“同一股道连续溜放十几钩”都会在压测里现形。6.3 交付前三个小功课自动备份、程序集合并、反编译防护交付前的三个小功课我一般不会省。一是自动备份每天下夜班前把数据库复制到另一台机器保留14天出问题有后悔药。二是程序集合并用Costura.Fody把所有依赖DLL合并进主程序免得现场漏带文件或者DLL版本冲突拷过去一个exe就能跑。三是反编译防护C#程序集用混淆工具处理一遍至少挡住“反编译就抄内部逻辑”的初级操作者连接串和关键密钥不要明文躺在配置文件里。回放这个习惯回头看看救了我好几次。早年我最自信的就是“算法写得对”后来发现系统上线后真正把台账搞乱的很少是纯算法问题大多是链路一致性——回执丢了、版本号过期、设备状态闪断。所以后来交付前我必先跑一遍历史回放再盯一整天现场交接班。这套系统的价值就在这它能把你从人肉接力里救出来但不能替你兜底所有边界边界要靠一遍遍重放和审计记录去磨平。希望帮到你。本文还有配套的精品资源点击获取
