Modelando el ascensor como una máquina de estados finitos

Obviamente hay muchas formas de diseñar esto, aquí hay un posible enfoque.

Para cualquier diseño, las señales no son menos críticas que la lógica de control en el proceso de diseño. Por ejemplo, hay sugerencias opuestas de asignación de estados para representar la posición (qué piso) del elevador y de no asignar. Mi opinión es que, de todos modos, debería haber señales que indiquen dónde se encuentra el ascensor, así que también podría definir las señales para indicar la posición. Parece que debería ser la forma más simple y más robusta.

Así que ahora la máquina de estado de movimiento del ascensor probablemente tendría al menos el siguiente estado: inactiva, arriba, abajo, parada. Las señales de entrada serían al menos la posición actual y el destino actual. La posición actual es la señal que está incorporada en el mecanismo del ascensor, como se explicó en el párrafo anterior. Al decir que el destino actual es una señal de entrada (interna) es otra opción de diseño: particionar la lógica de control. Para un modelado más realista, se pueden agregar aquí estados adicionales de movimiento de ascensores, como desaceleración, aceleración, apertura de puertas ...

Para generar el destino actual (señal), podría ser algo completo en función de algún tipo de mecanismo de cola. O podría ser una máquina de estado mucho más simple impulsada por algunas opciones de prioridad sin colas. La elección prioritaria de continuar en una dirección hasta que no haya más solicitudes pendientes en esa dirección (como lo sugiere Supercat) puede ser una de las opciones clave. En mi opinión, esta máquina tendría 7 estados, uno para cada piso de destino posible, y algunos más. Entre las entradas para esto se encuentran las señales de solicitud de los botones.

Las señales de solicitud para los botones probablemente serán generadas por simples máquinas de estado. 19 máquinas de estado para las 19 entradas como mencionó en EDITAR 1. Las máquinas de estado para los botones dentro del elevador serían algo así como: Cuando está inactivo, si se presiona el botón, vaya a Solicitar; Cuando se solicita si se detiene & & Current_position == Button_location goto Idle. Los botones de dirección en cada piso serían un poco más complicados.

Sugeriría que el elevador tiene 12 estados que combinan posición y dirección. Un ascensor debe continuar en su dirección actual si se presionan los botones de destino o de llamada entre su ubicación actual y el final del viaje. Debe invertir la dirección si no se presionan botones entre su ubicación actual y el final del viaje, pero algunos botones se presionan en otra parte.

Si, por ejemplo, el elevador acaba de entregar a alguien al sexto piso desde abajo, no se presionan los botones del séptimo piso, pero los botones "arriba" se presionan en los pisos tercero y quinto, el elevador debe comenzar a bajar. No debe detenerse en el quinto piso porque está bajando y ese es un botón "arriba", pero debe continuar más allá de ese piso porque hay otro botón debajo. Una vez que llegue al tercer piso, ya no habrá botones entre él y el final del viaje, sino que habrá botones que se presionarán en otros lugares, por lo que debe invertir la dirección. En ese momento, estará en el tercer piso hacia arriba, por lo que debe responder a la llamada del tercer piso.