设计也可以按图索骥

　　轨道信号灯控制系统到了设计建模阶段，与需求建模相比较，我认为除了增加OCL约束之外，我们主要是完成了对故障事件、并行事件、列车行驶连续性进行了具体的设计。

1.故障事件

　　安全性分析是轨道信号灯系统设计的重中之重。而在我们需求建模阶段，虽然一直有考虑系统可能面对的故障，但是没有全面系统的分析可能存在哪些故障，故障产生的原因以及故障的紧急程度和相应的故障处理措施。而在设计建模阶段，我们是通过故障树，较为全面的分析了系统可能存在哪些故障，以及故障的分级。设计建模阶段构建的故障树如下图所示。

 

 　　通过故障树可以直观的看到系统大概分为哪几种故障，以及各种故障可能的产生原因。关于具体的故障描述以及故障的监测、处理等内容，可参见设计建模文档。不过除了需要考虑故障的类型，故障分析这里还需要考虑故障的等级。不同故障对系统产生的影响不同，紧急程度也存在区别，这就需要我们根据故障的紧急程度对故障进行分析。当同时发生多个故障时，最紧急的故障要优先被处理。有关故障的具体分类标准，设计建模文档中已有描述。其中一级故障紧急程度最高，四级故障紧急程度最低。

2.并发事件

　　在需求分析阶段我们的模型大多是静态的，只考虑了单个事件的处理流程，但没有考虑当多个事件同时发生时，应该进行怎样的处理。为了让我们的模型“动”起来，我们在设计建模阶段增加了并发事件的处理机制。系统是采用了三级架构的形式，为此我们在考虑并发事件时，也是分三层进行了考虑。区间内部多个事件的并发属于区间控制系统级的并发；站间控制系统需要同时处理多个区间控制系统的请求，属于站间控制系统级的并发；轨道控制系统需要同时处理多个站间控制系统的请求，属于轨道控制系统级的并发。要进行事件的并发执行，就需要增加相应的中断机制，而增加中断机制首先需要确定事件的优先级。为此，我们首先详细的列举了各级系统可能要处理的各种事物，而后根据事物的紧急程度以及可能存在的关系，建立了事物的优先级表。优先级表确定之后，就需要考虑如何进行中断从而实现事件的并发。本系统的并发事件处理流程如下图。

 

 　　当控制系统需要处理并发事务时，首先按照优先级将事务进行排队。控制系统每次响应队列中的第一个事件。其中，事件会分为可以被抢占的低优先级事务与不可被抢占的高优先级事务。若可抢占的事务执行过程中，有更高优先级的事务需要执行，此时会在执行完某个原子操作之后，将该事务中断保存，去响应更高优先级的事务。若是不可抢占的事务，只有执行完当前事务后，才可以响应其它事务。

3.列车行驶连续性

 　　在需求分析阶段，我们默认列车是可以正常的从一个区间行驶到另一个区间的。但是在真实的场景中，区间控制系统的故障或列车本身的故障都有可能导致列车的行驶信息并不是连续的。为此，我们在设计建模阶段增加了列车行驶连续性监测模块，监测列车行驶的连续性。在列车行驶连续性监测模块，我们是将列车行驶的区间分为了起点站、中间区间以及终点站三类。在起点站，首先获取列车基本信息，以发车作为触发事件，当发车之后，起点站告知下一区间当前列车信息，并让下一区间做好列车即将到达的准备。在中间站，区间在列车进入当前区间后，告知上一区间列车已到达本区间，同时告知下一区间做好列车到达的准备。在终点站，列车到达后，告知上一区间列车已到达本区间，在列车完成客运或货运任务之后，清除列车信息。当列车从当前区间驶出后，若在一定时间内，当前区间未收到下一区间传来的列车到达信息，那么证明有异常情况发生，需要报告给故障处理单元当前区间发生列车行驶连续性故障。另外需要告知上级系统，当前区间丢失列车位置，交由上级系统在站间或轨道级别确定列车位置。当列车跨区段行驶，相邻站间控制系统也要参与列车行驶连续性的判断。