另一个电梯(电梯)仿真建模问题

Question

我正在玩弄Lift Simulation的设计。我有一个升降机控制器，里面有一系列升降机。升降机通过特定的状态(例如静止、移动、DOORS_OPEN等)移动-在移动状态下，升降机过程将简单地休眠X ms。我目前关注的是Lift Controller进程和Lift进程集合之间的交互。

本质上，升降机控制器需要协调升降机，因此需要处理发言权请求，并确定哪个升降机最适合为该请求提供服务，然后通知该升降机。

我最初的想法是让每个电梯在收到楼层请求后，通过各种状态移动自己，然后在完成移动到特定楼层后通知电梯管理员。然而，通过这样的设计，电梯控制器可以查询电梯以查看它离哪个楼层近，为该电梯做出决定(即在下一楼层停止)，但是当它被告知电梯停止时，该电梯可能已经移过该楼层(由于网络闪烁造成的延迟)。

为了避免这种类型的问题(其中Lift Controller根据过时的信息做出决策)，我考虑让Lift Controller负责在其状态之间移动每个Lift。有了这个模型，Lift Controller知道Lift处于什么状态，告诉它进行转换，然后知道它将处于什么状态。因此，Lift Controller总是有关于Lift正在做什么的最新信息，并且它的动作永远不会与各个Lift状态不同步。

人们对这种方法(wrt )有什么顾虑吗？线程，可伸缩性)--有没有更好的建模方法？欢迎大家的想法！

Answer 1

你决定构建更复杂的升降机控制器的关键字是，一些升降机可能已经超过了控制器预期的状态。我认为这些“事件”的频率很低，因为它们对系统有效性的负面影响也很低。我会保持简单，并采用乐观的方法。期望从lift得到良好的响应，但(如果真的有必要)偶尔会处理lift没有做它应该做的事情的情况，和/或选择另一个lift。

Answer 2

即使您将所有控件移动到lift控制器，同步问题仍然会在其他地方出现。例如，如果控制器在电梯运输过程中发送消息，则控制器不能100%准确地知道收到消息时电梯将在哪一层。

我认为您最好的做法是坚持面向对象的设计最佳实践，并专注于逻辑上的关注点分离。即。让电梯操心与电梯相关的问题，让控制器操心日程安排。

可以向升降机发出命令，使得升降机确认它们是否可以执行所请求的动作。在这种情况下，您需要设计调度算法，以便控制器直到发出请求后的几分钟才知道请求是否会执行-如果控制器只是在进行路由/调度，这应该是可以的。

当然，这完全取决于您需要模拟的逼真程度。