Modelado de ejercicios para el soporte de simuladores de entrenamiento

Transcripción

1 Modelado de ejercicios para el soporte de simuladores de entrenamiento Matías Ezequiel Prado Camila Robles TRABAJO FINAL - INGENIERÍA DE SISTEMAS FACULTAD DE CIENCIAS EXACTAS UNIVERSIDAD NACIONAL DEL CENTRO DE LA PROVINCIA DE BUENOS AIRES DIRECTOR: DR. FEDERICO CASANOVA CODIRECTOR: DR. CRISTIAN GARCÍA BAUZA 2017

2 Contenidos Dedicatorias y reconocimientos... 6 CAPÍTULO Introducción... 7 Motivación... 8 Objetivos... 9 Estructura de la tesis... 9 CAPÍTULO Marco Teórico Introducción Simulación Hardware para simulación Visualización en simuladores Pantallas LED Cascos de Realidad Virtual CAVE (Cave Automatic Virtual Environment) La simulación como herramienta de entrenamiento Ventajas para el operador o aprendiz Ventajas en el entrenamiento Simuladores de entrenamiento existentes SIMUVEG: Simulador de conducción automotriz

3 CENACAF: Sistema de Simulación de Conducción Ferroviaria Diseño del Módulo Instructor Representación del Comportamiento Grafos Estructura de lista Estructuras matriciales Máquinas de estado Conclusiones del marco teórico CAPÍTULO Simuladores de conducción Introducción Sistema simulador de conducción de trenes subterráneos Características generales del sistema Otros usos del framework Diseño preliminar de la arquitectura Módulo: Visualización y Comportamiento Funcionalidad Solución Desarrollo Tecnologías Resultados

4 Módulo: Controles e Interfaz Funcionalidad Solución Tecnologías Módulo: Instrucción Funcionalidad Solución Arquitectura General Máquina de Estados: Diagramación y especificación de ejercicios Implementación del framework de simulación Creación de ejercicios Diseño de ejercicios Problemática encontrada en caso particular CAPÍTULO Desarrollo de la herramienta de edición de ejercicios Graph-master GraphControl Node NodeConnection NodeItem Interfaz de Usuario y uso de la herramienta

5 Implementación de verificaciones y seguimiento de ejecución Clase GraphHelper Seguimiento de una ejecución CAPÍTULO Uso de la herramienta de edición de ejercicios Introducción Creación de ejercicios Máquina de estado Simple Máquina de estado Combinada Máquina de estado Principal Máquina de estado Satélite Merge Detección de errores Estado inaccesible No se puede llegar a un estado final o error Ciclo en la máquina de estados Existencia de estado error Herramienta para debugging de ejercicios Utilización de la herramienta Seguimiento de ejercicios en tiempo real CAPÍTULO

6 Conclusiones y trabajos futuros Conclusiones Trabajos futuros BIBLIOGRAFÍA ANEXO I Instruction Functions ANEXO II Código de creación de ejercicios en C# Representación de ejercicios en XML

7 Dedicatorias y reconocimientos Queremos agradecer a nuestros seres queridos que nos han apoyado durante la carrera, ayudando a sortear obstáculos con mayor facilidad y permitiéndonos llegar al final de esta etapa profesional. Entre ellos incluimos a familiares, amigos, profesores, compañeros de trabajo y aquellas personas de quienes hemos podido aprender de diferentes formas. A todos ellos muchas gracias! 6

8 CAPÍTULO 1 Introducción La tecnología disponible en la actualidad y la disminución de costos de hardware brinda mayores posibilidades de acceder a simuladores, colocando a un individuo en condiciones de selección, entrenamiento y certificación de sus habilidades y competencias en entornos visuales. Existen distintas motivaciones para utilizar un simulador en lugar del equipo real: costo del equipo, costo de operación y de no producción, riesgo de accidente, posibilidad de entrenar situaciones poco comunes o en entornos realistas previamente capturados y digitalizados [1]. Además, la utilización de simuladores aumenta el interés y la motivación por parte de los individuos que reciben capacitación y, como consecuencia, logra un incremento en la transferencia de conocimiento y su retención [2]. En ese contexto, resulta de suma importancia implementar técnicas innovadoras para el diseño de simuladores de entrenamiento; sistemas que permitan instruir a los operarios en el uso de máquinas y vehículos a través de planes de capacitación compuestos de diversos ejercicios pedagógicos. De esta manera, el docente formador 7

9 podrá disponer de distintos tipos de ejercicios basados en procedimientos y normativas acordes al tipo de simulación realizada. El diseño e implementación de estos ejercicios implica un desafío ya que requiere del trabajo en conjunto de expertos técnicos con conocimientos acerca del funcionamiento del simulador, y expertos en el dominio, que serán los encargados de validarlos. Motivación El diseño de ejercicios para simuladores de entrenamiento implica una coordinación y comunicación constante entre los desarrolladores y los expertos en el dominio. Esto puede generar costos adicionales, confusión en la interpretación de los requisitos y un mayor tiempo de implementación. Como consecuencia de estas complicaciones surge la necesidad de contar con un software que permita disminuir los riesgos de error en el diseño de ejercicios, facilite su interpretación, provea validaciones automáticas de correctitud y brinde además la posibilidad de diseño de manera gráfica de los ejercicios por parte de un no experto en el desarrollo del simulador, como puede ser un instructor. Adicionalmente, dado que el simulador debe acompañar el uso que se le da al equipo real y las operaciones que sobre él se realizan, se requiere que en el tiempo los ejercicios sean flexibles para evolucionar en complejidad o cambiar acompañando nuevas normativas o planes pedagógicos, además de poder definirse nuevos con el transcurso del tiempo. 8

10 Objetivos El objetivo es desarrollar una herramienta que soporte la creación, visualización y seguimiento en tiempo de ejecución de ejercicios para un framework de simulación. Dado que los ejercicios se implementan mediante máquinas de estado, el software permitirá realizar verificaciones de consistencia de las mismas, como también un seguimiento de la ejecución de los ejercicios en tiempo real mediante una interfaz de usuario amigable. Gracias a la interfaz amigable que se pretende crear, será posible crear diversos ejercicios por parte de especialistas del dominio sin necesidad de intermediación, eliminando las malas interpretaciones y el tiempo consumido en coordinar reuniones. Esto también reduce los errores de implementación de ejercicios por parte de los propios desarrolladores. A su vez facilitará la validación de los ejercicios, ya que el evaluador tendrá la posibilidad de realizarlos por sí mismo, y dará la flexibilidad buscada para la evolución a futuro de la complejidad, cambios y agregados de ejercicios. Otra finalidad de este software es aportar al avance del área de diseño y desarrollo de simuladores de fabricación nacional, con la generación y transferencia de conocimientos y formación de recursos humanos. Esto permitirá la suplantación de importaciones por producción nacional, cuyo avance es necesario y brinda grandes beneficios. Estructura de la tesis continuación. El trabajo se encuentra estructurado en seis capítulos, cuyo contenido se resume a 9

11 En el Capítulo 1 se presenta una breve introducción a la problemática en relación al uso de simuladores para el entrenamiento de operarios y las motivaciones que llevan a la creación de herramientas para lograr los objetivos propuestos. En el Capítulo 2, a través de definiciones y ejemplos concretos, se detalla el marco teórico que permite el entrenamiento de operarios de diferentes áreas a través de simulaciones y al uso de máquinas de estado para la implementación de ejercicios pedagógicos creados con este fin. Además, se presenta un análisis de la situación actual en el país y el mundo. En el Capítulo 3, se explica la utilización del simulador de entrenamiento para capacitar operadores de trenes subterráneos. Además, se presentan los aspectos más importantes del framework de simulación desarrollado y la implementación de ejercicios mediante máquinas de estado. En el Capítulo 4 se presenta en detalle la solución mediante la cual está implementada herramienta de edición de ejercicios SMEditor. Tomando como referencia las bases teóricas mencionadas en los primeros capítulos, el capítulo expone las decisiones que se tomaron al desarrollar la plataforma. Justificando y explicando cada una de ellas, abarca tanto la arquitectura del sistema como soluciones a más bajo nivel. En el Capítulo 5 se realiza un análisis de los resultados que se obtienen a partir del uso de la herramienta de edición de ejercicios como complemento al simulador. Se comparan las diferencias de código al implementar un mismo ejercicio mediante código y con la herramienta de edición. Por otro lado, se incluye la descripción de una aplicación de soporte que, mediante el envío de eventos, permite hacer pruebas a la funcionalidad de la herramienta SMEditor que realiza un seguimiento de los ejercicios en tiempo de ejecución. El capítulo concluye con algunas ideas subjetivas a partir de la reflexión de los resultados obtenidos en los experimentos. 10

12 Finalmente, en el Capítulo 6, se presentan las conclusiones finales del trabajo junto con posibles extensiones del mismo. 11

13 CAPÍTULO 2 Marco Teórico Introducción Ante la responsabilidad de conducir un sistema dado, como por ejemplo un banco o un sistema de transporte, se deben tomar decisiones continuamente acerca de las acciones a ejecutar [3]. Para tomar la decisión más acertada es necesario saber cómo responderá el sistema ante una determinada acción. Esto podría hacerse por experimentación con el sistema mismo; pero factores como costos o seguridad, entre otros, hacen que esta opción generalmente no sea viable. Como respuesta a esto, se reemplaza el sistema real por otro que en la mayoría de los casos es una versión simplificada del mismo. Se utiliza este modelo de sistema simplificado para llevar a cabo las experiencias necesarias sin los inconvenientes planteados anteriormente. Al proceso de experimentar con un modelo se denomina simulación. Al proceso de diseñar el plan de experimentación para adoptar la mejor decisión se denomina optimización. Si el plan de experimentación se lleva a cabo con el solo objeto de aprender a conducir el sistema, entonces se denomina entrenamiento o capacitación. 12

14 Simulación Una simulación es la imitación del funcionamiento de un sistema real durante un intervalo de tiempo [4]. Los simuladores reproducen sensaciones y experiencias que pueden suceder en la realidad. Un simulador pretende reproducir las sensaciones físicas, como velocidad, aceleración o la percepción del entorno, como también el comportamiento de la máquina que se pretende simular. Para simular las sensaciones físicas se puede recurrir a complejos mecanismos hidráulicos comandados por ordenadores que mediante modelos matemáticos consiguen reproducir sensaciones de velocidad y aceleración. Los simuladores de equipos y procesos conocidos como de inmersión total, someten al usuario a condiciones visuales, auditivas y de movimiento realistas, permitiendo entrenar o verificar su comportamiento en condiciones extremas, pero sin poner en riesgo su propia integridad ni la del equipo. Lo mencionado en el párrafo anterior se consigue mediante la acción conjunta de complejos sistemas mecánicos, electrónicos y computacionales. Mientras que los sistemas mecánicos están encargados de transmitir los movimientos al usuario y soportar la interfaz correspondiente, los electrónicos deben ser capaces de ejecutar las acciones determinadas por la situación en ejecución y capturar las acciones del usuario. Por su parte, las plataformas computacionales, tanto de software como de hardware, son las encargadas de la visualización, sonidos, modelos de comportamiento y otras funciones. Todo esto se debe realizar de forma coordinada y en tiempo real. 13

15 Hardware para simulación Una de las partes más complejas de los simuladores son los dispositivos capaces de capturar los movimientos del usuario y de transmitir simultáneamente a este las sensaciones táctiles correspondientes a la acción ejecutada. Ejemplos de esto son los volantes de conducción, los pedales de freno, embrague y aceleración, o las palancas de cambio. Estos sistemas deben ser capaces de ejecutar dos funciones en paralelo: capturar la acción del usuario y retroalimentarla con fuerzas, momentos y vibraciones correspondientes, en caso de haberlas. A estos dispositivos capaces de simular sensaciones táctiles tanto de entrada como de salida entre el computador y el usuario se los denomina dispositivos hápticos, y resultan fundamentales a la hora de transmitir sensaciones realistas de la acción ejecutada sobre un equipo simulado computacionalmente. La háptica es la ciencia que estudia el tacto, como la óptica lo hace con la vista y la acústica con el oído. De este modo, los dispositivos hápticos son los que simulan una respuesta táctil [5]. Los dispositivos hápticos trasladan la sensación de presencia a un operador que puede tocar, sentir y manipular objetos tridimensionales simulados en un entorno virtual. La complejidad de su tecnología puede variar, pero no por ello lo hace su efectividad. Cuando durante una simulación de conducción sobre grava o a través de una zona de baches el dispositivo con el que se conduce sea un volante, un mando o un joystick, este vibra y reproduce de forma primaria lo que sucedería si esa situación fuera real, entonces estamos frente a un dispositivo háptico. Al añadir el sentido del tacto a la experiencia virtual, los dispositivos hápticos representan una parte muy valiosa del desarrollo de la industria de la simulación. 14

16 En el caso de los simuladores de maquinaria o automoción, la base del funcionamiento de estos dispositivos es la capacidad de enviar información al ordenador a través de alguna terminal externa y recibir, a su vez, una respuesta en forma de sensación física. Esta información que se recibe, en dependencia de si es en un solo punto, por ejemplo la vibración del volante, o si envuelve a todo el cuerpo, como es el caso de una plataforma de movimiento debajo del asiento o de toda la cabina, es lo que conforma una realidad más o menos inmersiva [6]. La complejidad en la respuesta háptica introducida a un sistema simulador dependerá del requerimiento de costo y las capacitaciones a realizar, en algunos casos el sólo hecho de tener instrumental (por ejemplo: palancas, botones o volantes) que en su forma y ergonomía se sientan como los reales es suficiente para lograr el objetivo, teniendo en cuenta que a más complejidad en el hardware, mayores serán los costos de desarrollo del sistema simulador. Visualización en simuladores Para que la experiencia del usuario sea completa, es necesario dar una sensación de realismo a la hora de simular el ambiente. De esta manera, el usuario se sentirá más cómodo y motivado al usar el simulador ya que se encontrará en un entorno realista. Para esto existen distintos niveles de visualización, desde pantallas a componentes más inmersivos como cascos de realidad virtual o CAVE (Cave Automatic Virtual Environment). 15

17 Pantallas LED Se pueden utilizar pantallas LED de alta definición, ubicadas de forma que el usuario tenga la sensación de estar dentro de la maquinaria que se pretende simular. Un ejemplo de este tipo de visualización en simuladores es Simex: un simulador de retroexcavadoras desarrollado en el instituto de investigación y desarrollo PLADEMA, de la Universidad Nacional del Centro de la Provincia de Buenos Aires. La Figura 1 muestra la disposición de los monitores respecto del asiento del conductor de excavadoras hidráulicas, que permiten una representación clara de la realidad a simular. Figura 1: Simex (PLADEMA) Simex es un simulador de maniobras y operaciones para el manejo de excavadoras hidráulicas en entornos de trabajo relacionados a la minería y los trabajos pesados. Resulta de un convenio con la Fundación UOCRA, el Instituto de Estadística y Registro de la 16

18 Industria de la Construcción (IERIC) y Cámara Argentina de la Construcción. Financiado por el Ministerio de Trabajo, Empleo y Seguridad Social de la Nación. Cascos de Realidad Virtual Se trata de un casco de realidad virtual que contiene una serie de sensores, tales como acelerómetros, giroscopios y magnetómetros. Uno de los más populares es el Oculus Rift (Figura 2), pero existen varias marcas en el mercado y su costo está disminuyendo. En las últimas versiones de Oculus Rift se incluyó una cámara externa para trackear la posición de la cabeza del usuario. La información de cada uno de estos sensores se combina para determinar el movimiento de la cabeza del usuario en el mundo real y sincronizar la visualización virtual del usuario en tiempo real [7]. Figura 2: Oculus Rift CAVE (Cave Automatic Virtual Environment) Se trata de un entorno de realidad virtual inmersiva que consiste en un cubo, como se puede ver en la Figura 3, en el que el usuario está inmerso. Desde el exterior de las paredes del cubo son proyectadas imágenes que simulan la realidad. Existen CAVEs donde se proyecta las imágenes en 3, 4, 5 o 6 caras del cubo [8]. 17

19 Generalmente el usuario lleva gafas estereoscópicas que, sincronizadas con las proyecciones, le permiten ver en 3D las imágenes, e incluso contemplar objetos flotando dentro del cubo que puede observar desde diversos ángulos. Figura 3: CAVE en la que se visualiza una réplica de las instalaciones de Vaca Muerta (Instituto PLADEMA) La simulación como herramienta de entrenamiento Un simulador de entrenamiento permite la repetición de un determinado ejercicio tantas veces como el instructor considere necesario, así como la utilización de la maquinaria en situaciones que no son factibles con el equipo real: operación con fallas del equipo, condiciones meteorológicas extremas, operación en situaciones de presión, entre otras. Estos desarrollos tienen dos fases principales: la de los efectos gráficos de computadora, importantes para que sea impactante sensorialmente; y el modelado numérico mediante el cual se consigue modelar los comportamientos tal como ocurren en la realidad [9]. Esto último es importante ya que, a diferencia de un videojuego, no alcanza con que parezca sino que tiene que sentirse real. De no ser así, el operario no se estaría capacitando sino que simplemente estaría jugando. Por ejemplo, en un simulador de 18

20 embarcación no es lo mismo que la superficie del agua se mueva con ondas convincentes que modelar la fluido-dinámica de esa superficie y considerar el oleaje que produce el paso de una embarcación cercana. Hasta hace no mucho tiempo, este tipo de capacitación estaba restringida a pilotos de aeronaves y eventualmente a prácticos que manejan grandes embarcaciones. Esto se debía a que el costo de un simulador de realidad virtual era extremadamente alto, al punto que sólo existían una o dos instalaciones de este tipo en el país por las que se debió pagar varios millones de dólares. Hoy en día estos simuladores pueden ser completamente desarrollados aquí a una fracción de su costo internacional y a la medida de los requerimientos locales. El entrenamiento de operarios es una tarea que representa cierta complejidad. En la etapa de formación no existen herramientas de percepción y prevención de situaciones de riesgo, ya que son factores que se aprenden a base de práctica y monitoreo. En situaciones de peligro, el operador tiende a sentir pánico y a reaccionar de forma inadecuada, porque no existe este paso de la formación teórica a la práctica donde puedan recrear accidentes y emergencias y así aprender los procedimientos adecuados en cada uno de estos casos. El objetivo principal de un simulador para capacitación es que sus usuarios aprendan a operar máquinas reales sin tener que utilizarlas, evitando así los riesgos asociados a tales operaciones. Una capacitación de operarios bien definida requiere de la exposición a un conjunto de situaciones como son el trabajo en condiciones adversas, bajo mayores exigencias de rendimiento o de precisión que el trabajo real. Por esta razón la utilización de máquinas reales para el aprendizaje representa inconvenientes importantes como: 19

21 Costos: La dedicación de unidades de maquinaria para el aprendizaje supone un costo mucho más elevado que el uso de simuladores; Riesgos: Ciertos ejercicios benéficos del punto de vista pedagógico/didáctico pueden representar riesgos elevados, o ser irrealizables en un escenario real. Por ejemplo: condiciones meteorológicas, averías, accidentes, límites de cada máquina. La utilización de simuladores en los procesos de aprendizaje implica una oportunidad para las organizaciones, ya que posee las ventajas descritas a continuación. Ventajas para el operador o aprendiz Aplicación inmediata de lo aprendido en clases teóricas. Ambiente de trabajo para el aprendizaje realista y seguro. Curva de aprendizaje más rápida. Permite un acompañamiento detallado de los operarios por un profesional experto. Reducción del tiempo de formación, ya que se usan esquemas de instrucción que favorecen a la asimilación de habilidades en secuencias adecuadas. Uso de la maquinaria en situaciones excepcionales, tales como máquinas averiadas, condiciones meteorológicas extremas, situaciones de presión, estrés o emergencias. El entorno de simulación proporciona al alumno la posibilidad de desenvolverse en contextos ajenos a su realidad. 20

22 Ventajas en el entrenamiento Enfoque en áreas específicas de entrenamiento, con posibilidad de realizar ejercicios repetitivamente. Menor costo de entrenamiento. Menor tiempo de uso de la maquinaria fuera de sus tareas de productividad. Reducción de costos de reparación y mantenimiento. Repetición de determinado ejercicio tantas veces cuanto el instructor considere necesario, sin la necesidad de los gastos asociados al uso de una máquina real. Capacitación de usuarios para que sepan reaccionar ante situaciones de emergencia y averías de la maquinaria. Evaluación objetiva y fiable de los aprendices, facilitando la realización de pruebas de aptitud. Condicionamiento de los hábitos de los usuarios durante la operación, mejorando el rendimiento y reduciendo las averías a la maquinaria. Tareas de selección de personal, permitiendo realizar exámenes de habilidad y conocimientos de la operación antes de la contratación de personal. Seguimiento automatizado de los participantes de las sesiones de capacitación y aprendizaje por medio de la base de datos integrada al sistema [10]. Como consecuencia se puede afirmar que los simuladores de realidad virtual como método de aprendizaje son una herramienta segura que permite desarrollar las habilidades del alumno de forma confiable. Con un plan didáctico diseñado para llevar al alumno desde un nivel básico de ejercicios hasta un nivel con dificultades y condiciones adversas en las que se prueba la respuesta y el comportamiento del mismo ante situaciones difíciles. 21

23 Este aprendizaje por medio de un plan de estudios con ayuda de un método pedagógico y la posibilidad de vivenciar situaciones que con equipos reales no podría tener, proporciona mayores bases conceptuales al alumno, convirtiéndolo en un profesional en su campo. Es de suma importancia aclarar que el alumno debe acompañar estas prácticas simuladas con experiencia en la máquina real. Gracias a las simulaciones, el uso de la maquinaria real en el entrenamiento se disminuye en gran medida, viéndose menos afectada su productividad debido a que no deberá disminuir su uso para capacitar operarios, lo cual significa menos horas fuera de su trabajo habitual y también en la vida útil de la misma ya que la máquina estará menos tiempo sometida a operarios inexpertos que puedan causar averías por el mal uso. Todo esto hace de la formación de operarios de maquinaria pesada un proceso pedagógico y profesional, dejando de lado la formación empírica que implica altos riesgos tanto para el principiante como para la máquina. Simuladores de entrenamiento existentes El avance de las nuevas tecnologías ha permitido que los simuladores de equipamiento sean cada día más accesibles a las organizaciones y empresas. La complejidad de los procesos laborales actuales hace sumamente necesario capacitar en forma continua a los recursos humanos de las organizaciones. Los procesos de toma de decisiones que involucran equipamientos complejos y costosos tienen en el uso de simuladores una gran herramienta tecnológica para capacitar a los recursos humanos en un entorno lo más parecido a la realidad. Debido a esto en los últimos años ha habido un gran incremento en el uso de simuladores de entrenamiento en diversas áreas. A continuación se presentan algunos 22

24 ejemplos que muestran la variedad de aplicaciones que pueden tener los simuladores de entrenamiento. SIMUVEG: Simulador de conducción automotriz Simulador de conducción desarrollado por SINTEC-INTRAS, Universidad de Valencia, España. Utilizado en evaluación de conductores, carreteras, dispositivos IVIS y otras áreas. El simulador de conducción SIMUVEG (Figura 4) es un sistema avanzado, especialmente diseñado para representar escenas realistas dentro de un entorno inmersivo. El simulador fue desarrollado por el grupo de investigación SINTEC del INTRAS y su instrumental científico fue obtenido mediante la subvención de la Universidad de Valencia. Figura 4: SIMUVEG Simulador de conducción automotriz Este sistema se basa en una pantalla de grandes dimensiones y 160 grados de ángulo de visión, iluminada por 3 proyectores XGA de 2000 lumens. La cabina de conducción es un coche completo modelo Renault Twingo que ha sido modificado y al que se le han añadido diversos sensores en sus partes operacionales más importantes. 23

25 También dispone de un sistema de audio conectado a un PC que genera sonido 3D y efectos doppler. Sin embargo, la parte más importante del sistema es la estación gráfica que lleva a cabo la generación de las imágenes 3D en tiempo real en función de los datos de los sensores del coche. El simulador se ha utilizado como herramienta principal en numerosos proyectos con instituciones públicas y empresas privadas [11]. Figura 5: Partes que componen al simulador de conducción SIMUVEG. CENACAF: Sistema de Simulación de Conducción Ferroviaria El sistema de simulación de conducción ferroviaria ha sido instalado en el complejo edilicio del Centro Nacional de Capacitación Ferroviaria (CE.NA.CA.F.), situado en la localidad de Temperley, Lomas de Zamora, Provincia de Buenos Aires [12]. 24

26 Figura 6: Simuladores CENACAF El sistema de simulación consta de: Tres puestos de formación, réplicas que recrean en forma total la cabina de conducción del material rodante adquirido a las empresas chinas. Cuatro puestos de instructor con capacidad para controlar cualquier número de Puestos de Formación (PF) de manera simultánea. Ocho puestos de formación simplificados: Cuentan con pantallas táctiles que emulan los controles de las cabinas de conducción (Permiten una capacitación óptima, pero sin el grado de inmersión que proporciona una cabina réplica). Dos puestos de observación que permiten ver la sesión de simulación a un grupo de alumnos, en tiempo real o en modo repetición. 25

27 Figura 7: Imagen de proyección simulador CENACAF Diseño del Módulo Instructor Este módulo es la pieza del sistema simulador con la que interactuará el docente o instructor a cargo de la capacitación, desde la cual se podrá manejar y monitorear uno o varios de los simuladores que interactúan con cada alumno. Este módulo de software será el que contenga los diferentes ejercicios que se podrán presentar a los alumnos y realizará el control de la correcta realización de ejercicios por parte de los alumnos, permitiendo un seguimiento detallado de ellos por el personal experto, tanto en la operación de la maquinaria como en pedagogía y aprendizaje [13]. Con este fin, se incorpora una metodología de trabajo y herramientas que permiten la creación de situaciones de operación de acuerdo con el conocimiento del instructor. El simulador proporciona en definitiva una realidad experimental que sirve para: 26

28 Demostrar: El simulador permite realizar demostraciones por parte de operadores expertos a futuros operadores para una primera toma de contacto. Instruir: El alumno recibe las indicaciones y las lecciones que le permitirán conocer cuál es la forma correcta de operar. Practicar: Una vez recibidas las indicaciones oportunas, el alumno deberá practicar las diferentes operaciones y tareas hasta asimilar su correcta ejecución. Evaluar: Una vez finalizadas las prácticas, los operadores expertos podrán evaluar a los aprendices para ver el progreso de los mismos. Además permite la revalidación de conocimientos periódicamente, como recapacitaciones. Seleccionar: El simulador puede ser utilizado para una eventual selección de personal. Para cada una de estas actividades es necesario contar con diferentes tipos de ejercicios, cada uno con características específicas de lo que se desee simular. Representación del Comportamiento Para dar soporte a la creación de simuladores fue necesario encontrar una forma de representar su comportamiento. La representación que mejor se adapta a la lógica de pasos y procedimientos que generalmente se quieren ejercitar en un simulador es la de una máquina de estados. Como estructura de datos de soporte de la máquinas de estado de manera natural se llega a la utilización de los grafos, dadas sus características detalladas en la sección que sigue. 27

29 Grafos Un grafo se define como un par G = (V, E), donde V es un conjunto de elementos denominados vértices o nodos, y E es un subconjunto de pares no ordenados de vértices y que reciben el nombre de aristas o arcos. Si V = {v1,, vn}, los elementos de E se representan de la forma {vi, vj}, donde i!= j. Vi y Vj se dicen adyacentes si {Vi, Vj} E. Los elementos de una arista o arco se denominan extremos de dicha arista [14]. Las secuencias de aristas forman caminos o ciclos. Un ciclo es una sucesión de aristas adyacentes, donde no se recorre dos veces la misma arista, y donde se regresa al punto inicial. Se dice que un grafo es conexo si se puede llegar desde cualquier nodo hasta cualquier otro mediante un camino. De lo contrario no es conexo, pero puede dividirse en componentes conexas, que son subconjuntos de nodos y aristas del grafo original que si son conexos. Un grafo conexo sin ciclos es llamado un árbol. Desde un punto de vista práctico, los grafos permiten estudiar las interrelaciones entre unidades que interactúan unas con otras. Por ejemplo, una red de computadoras puede representarse y estudiarse mediante un grafo, en el cual los vértices representan terminales y las aristas representan conexiones (las cuales, a su vez, pueden ser cables o conexiones inalámbricas). Prácticamente cualquier problema puede representarse mediante un grafo. Luego se pueden aplicar diversos algoritmos sobre estos grafos para llegar a la resolución de dichos problemas. Un grafo en el ámbito de las ciencias de la computación es un tipo abstracto de datos, TDA a partir de ahora. Existen diversas implementaciones para representar este TDA. 28

30 La estructura de datos elegida depende de las características del grafo y de los algoritmos que se elijan para manipular el mismo. Las dos principales ramas de representación son las listas y las matrices, aunque frecuentemente se usa una combinación de ambas. Los tiempos de ejecución varian en función del número de vértices y el de aristas, por lo que la utilización de una representación u otra dependerá en gran medida de si el grafo es denso (cuando tiene muchas aristas) o disperso (muy pocas aristas) Las listas son preferidas en grafos dispersos porque tienen un uso eficiente de la memoria. Por otro lado, las matrices proveen acceso rápido, pero pueden consumir grandes cantidades de memoria. Estructura de lista Lista de incidencia: Las aristas son representadas con un vector de pares (ordenados, si el grafo es dirigido), donde cada par representa una de las aristas. Lista de adyacencia: Cada vértice tiene una lista de vértices los cuales son adyacentes a él. Esto causa redundancia en un grafo no dirigido (ya que A existe en la lista de adyacencia de B y viceversa), pero las búsquedas son más rápidas, al costo de almacenamiento extra. Lista de grados: También llamada secuencia de grados o sucesión gráfica de un grafo no-dirigido es una secuencia de números, que corresponde a los grados de los vértices del grafo. 29

31 Estructuras matriciales Matriz de adyacencia: El grafo está representado por una matriz cuadrada M de tamaño n2, donde n es el número de vértices. Si hay una arista entre un vértice A y un vértice B, entonces el elemento M [A, B] es 1, de lo contrario, es 0. Matriz de incidencia: El grafo está representado por una matriz de A (aristas) por V (vértices), donde [vértice, arista] contiene la información de la arista (1 - conectado, 0 - no conectado) Máquinas de estado Una máquina de estados se enmarca dentro de un modelo de comportamiento de un sistema que tiene entradas y salidas. Las salidas dependen tanto de las entradas actuales, como de las anteriores. Una máquina de estados tiene entonces un conjunto de estados que sirven de intermediarios en esta relación de entradas y salidas. Dicha relación hace que el historial de señales de entrada determine en cada instante un estado de la máquina, de tal manera, que la salida dependa únicamente del estado y las entradas actuales. De esta manera, una máquina de estados se denomina Máquina de Estados Finitos (MEF) si el conjunto de estados de la máquina es conocido o finito. Varios podrían ser los ejemplos en los cuales se podrían contextualizar las (MEF), sin embargo, el más popular es la máquina de Turing, la cual se define como una cinta en la que se lee y también se escribe [15]. Es posible clasificar las máquinas de estado en aceptoras o transductoras: Aceptoras: Son aquellas en donde la salida es binaria, depende únicamente del estado y existe un estado inicial. Puede decirse, entonces, que cuando la máquina produce una salida "positiva", es porque ha "reconocido" o "aceptado" 30

32 la secuencia de entrada. En las máquinas de estado aceptoras, los estados con salida "positiva" se denominan estados finales. Transductoras: Convierten una secuencia de señales de entrada en una secuencia de salida, pudiendo ésta ser binaria o más compleja, dependiendo de la entrada actual, no sólo del estado y pudiendo también prescindir de un estado inicial. Las máquinas de estado cumplen todos los axiomas de los autómatas finitos. Un autómata finito es un vector de tres elementos M = (I, S, d, F) donde I es el conjunto finito de entradas, S es el conjunto finito de estados el cual no debe ser vacío, d es la función de transición de estados y F es el conjunto finito de estados finales, incluidos en S [16]. Al igual que en las máquinas secuenciales, la representación de los autómatas finitos puede llevarse a cabo de dos formas diferentes: mediante un diagrama de estados o mediante una tabla de estados. De estas dos representaciones, la más intuitiva para una traducción partiendo de unas especificaciones de diseño es el diagrama de estados. Como se mencionó, estos diagramas de estados pueden ser representados mediante grafos. Los grafos son solo abstracciones matemáticas, pero son útiles en la práctica porque ayudan a resolver numerosos problemas. Estos grafos deben ser acíclicos, ya que en caso de existir ciclos puede darse la situación en la que no se llegue a un estado final. Estas representaciones sirven como base para trasladar la realidad al plano lógico en el que están implementados algunos de los simuladores mencionados en el presente capítulo. 31

33 Conclusiones del marco teórico Se brindó una idea general de los principales temas que sirven para comprender tanto el contexto que engloba a los simuladores como los fundamentos teóricos que se utilizaron para llevar a cabo su implementación. A su vez, los conceptos desarrollados anteriormente se utilizan a lo largo de los capítulos para justificar decisiones y explicar la implementación del framework de conducción y la herramienta de edición de ejercicios que lo complementa. 32

34 CAPÍTULO 3 Simuladores de conducción Introducción Dentro de la gran variedad de simuladores de conducción se encuentran aquellos que sirven para entrenar a quienes conducen transporte de pasajeros. Se trata de algo particularmente sensible ya que requiere de especial atención en su formación, capacitación y recertificación de conocimientos a través del tiempo. El entrenamiento de conductores ferroviarios conlleva diferentes problemas tanto desde el punto de vista de la prevención de riesgos laborales como desde una perspectiva de seguridad y prevención de accidentes. La utilización de estos equipos por un usuario inexperto implica un alto riesgo, además de volverse más propensos al deterioro. Por otra parte, la utilización de equipos reales para tareas de entrenamiento supone un alto costo e impedimentos operativos. La utilización de simuladores de trenes para tareas de aprendizaje y entrenamiento proporciona una solución a estos inconvenientes y se presenta como una herramienta imprescindible en el marco de la prevención de riesgos y la seguridad laboral, además de reducir los costos asociados a la formación de los operarios. 33

35 Sistema simulador de conducción de trenes subterráneos El proyecto de desarrollo del simulador de conducción de trenes subterráneos para la formación de personal surge de un convenio de la Universidad Nacional del Centro de la Provincia de Buenos Aires con Subterráneos Buenos Aires Sociedad del Estado (SBASE). Su ejecución se lleva a cabo en el área Media.Lab del Instituto PLADEMA (perteneciente a la Facultad de Ciencias Exactas), área que es un espacio multidisciplinario centrado en la investigación y desarrollo de aplicaciones de computación gráfica, realidad virtual e interacción humano-computadora [17]. El simulador es capaz de recrear ejercicios de conducción para todo el material rodante de subterráneos de la ciudad de Buenos Aires, principalmente los nuevos trenes de la empresa: CAF6000, Alstom metrópolis, CNR y Nagoya. En particular, el proyecto contempla la fabricación de cuatro puestos de formación con una cabina en tamaño real con controles en hardware y modelos computacionales de comportamiento que simulan cada modelo de tren. Adicionalmente, el sistema incluye nueve puestos micro-simuladores para dar soporte a la ejercitación colaborativa con controles mediante interfaz gráfica. La visual se recrea mediante técnicas de computación gráfica, posibilitando el recorrido virtual de las seis líneas de subte con todas sus estaciones. Desde la Instrucción, el docente formador dispone de distintos tipos de ejercicios basados en procedimientos y normativas de conducción. Una de las diferencias fundamentales con los simuladores de conducción mencionados en el marco teórico reside en la funcionalidad que incluye la resolución de averías. Ofrece toda la variedad necesaria en la simulación de los escenarios y situaciones reales a los que se enfrenta el personal de conducción, tanto en condiciones espaciales 34

36 como temporales y tanto en condiciones normales como en condiciones extraordinarias. Permite la simulación de situaciones poco frecuentes o de una complejidad específica. Entre los desafíos tecnológicos que el proyecto implica, se encuentra el modelado del comportamiento físico de las formaciones, la simulación de los desplazamientos de multitud de personas, la representación en forma realista de varios kilómetros de túneles y vías, y la construcción de la geometría de más de un centenar de estaciones. Todo esto en un sistema que funciona en tiempo real. El sistema de formación y simulación para conductores de trenes subterráneos es a la vez una herramienta formativa segura y flexible que permite al alumno enfrentarse a situaciones reales y resolver los posibles problemas que surjan en las tareas de conducción, posibilitando la obtención de conocimientos prácticos que permitan evitar o mitigar dichas dificultades. Dentro de sus objetivos primarios se encuentran: La formación recurrente y el perfeccionamiento del personal de conducción, tanto actual como el de los ingresantes futuros. Una mejora en la circulación de las líneas de subte de la Ciudad Autónoma de Buenos Aires (C.A.B.A), reflejada en los índices de seguridad. Como se mencionó, el sistema está diseñado para permitir a los alumnos practicar escenarios en los que se puedan realizar operaciones de explotación de la red de subterráneos de la C.A.B.A, en un entorno real, tanto en situaciones normales de conducción como en las que se degraden por incidentes y en situaciones de emergencia, es por ello que el sistema incluye: Simulación de situaciones de conducción normal y degradada, siendo esta última una de las características que lo distinguen del resto del mercado. 35

37 Herramientas que faciliten el adiestramiento y la formación en contexto de situaciones de conducción simuladas. Réplica con suficiente realismo de las consecuencias de actuación del alumno, en el ámbito de la seguridad. Seguimiento histórico de la formación y capacitaciones de cada alumno en el simulador. Características generales del sistema El parque de material rodante que contempla el sistema, está compuesto por las siguientes unidades: Coches eléctricos CAF Serie 6000 alimentados por 600 Vcc por catenaria rígida, fabricados por Construcciones y Auxiliar de Ferrocarriles (CAF). Coches eléctricos Alstom Metrópolis alimentados por 1500 Vcc por catenaria convencional, fabricados y provistos por Alstom. Coches eléctricos CNR alimentados por 1500 Vcc por catenaria convencional, fabricados y provistos por CNR-CITIC. Coches CNR (Línea A), Coches CAF Serie 6000 (Línea B), Coches Nagoya (Línea C) y Coches Alstom (Líneas D y H). El simulador está compuesto por 4 (cuatro) puestos de Instructor (PI); 9 (nueve) puestos micro simuladores (PMS) y 4 (cuatro) puestos de formación (PF); cuenta con todo el hardware, software e instalaciones necesarias para el correcto funcionamiento del simulador, dentro de un entorno virtual de gran realismo que permita el mayor grado de compromiso de los alumnos. El sistema es escalable y permite incrementar fácilmente la cantidad de puestos. 36

38 Otros usos del framework Además de utilizar el framework para el simulador de conducción de trenes subterráneos, este provee funcionalidades que permiten la implementación de simuladores de diversos de ámbitos. En la actualidad es utilizado en los proyectos listados a continuación: SIMEx (2013): Es un simulador que permite el entrenamiento en la operación de una máquina excavadora hidráulica. Surgió de un pedido explícito de la Secretaría de Empleo, del Ministerio de Trabajo y Seguridad Social de la Nación Argentina para ser utilizado en capacitación y formación de operarios. Actualmente el proyecto se encuentra en la fase final de implantación, la cual contempla la colocación de tres unidades del simulador en un camión escuela que recorrerá el país capacitando operarios, generando más y mejor empleo. RUBIKA (2014): RUBIKA es una CAVE (Computer Assisted Virtual Environment), instalación que combina software y hardware permitiendo al usuario sentirse totalmente inmerso en un mundo que parece real pero es generado de manera virtual. El desarrollo es el único en su tipo para Argentina y uno de los pocos de América. La CAVE tiene aplicaciones importantes en áreas muy diversas; permitiendo por ejemplo emular el recorrido por instalaciones complejas como una plataforma de extracción de petróleo o una central nuclear, o visualizar información tridimensional compleja como la que se genera en prospección petrolera para entender que hay en el subsuelo. El proyecto fue financiado por Secretaría de Políticas Universitarias del Ministerio de Educación de la Nación Argentina, concibiéndolo como un proyecto para aplicar en las Universidades Nacionales. 37

39 Ingeniería de Petróleo y Perforación (2015): El proyecto contempla el desarrollo e implantación de nueve CAVEs en universidades que componen la Red Nacional de Universidades Petroleras (RUP). Adicionalmente se implementó un Simulador de perforación y un visualizador de datos geológicos. El desafío se centra en interactuar con diversos actores como las universidades nacionales y el sector empresario relacionado a la exploración y perforación de pozos de petróleo como YPF. El relevamiento inicial para el desarrollo del sistema contempló la visita a pozos del complejo Vaca Muerta y entrevistas con ingenieros, geólogos y distintos campos profesionales. Simulador de Subtes (2015): El simulador es capaz de recrear ejercicios de conducción para todo el material rodante de subterráneos, principalmente los nuevos trenes de la empresa: CAF6000, Alstom, CNR y Nagoya. En particular, el proyecto contempla la fabricación de cuatro puestos de formación con una cabina en tamaño real con controles en hardware y modelos computacionales de comportamiento que simulan cada modelo de tren. El proyecto fue financiado por la empresa Subterráneos de Bs. As. Sociedad del Estado (SBASE), dueña de la red subterránea de la Ciudad Autónoma de Bs. As y será utilizado por la empresa encargada de la operación de los subtes en la ciudad, Metrovías S.A., el concesionario actual que la explota. Los choferes e instructores de Metrovías son los usuarios de este sistema. Todos estos proyectos son un hito importante en la transferencia de tecnología, siendo trascendente también para la sustitución de importaciones debido a que este tipo de sistemas generalmente es adquirido fuera del país y conllevan inversiones más importantes. 38

40 Diseño preliminar de la arquitectura La arquitectura del software de simulación está compuesta por tres módulos con funcionalidades específicas: visual, controles e instrucción. Estos interactúan mediante un administrador de mensajes que comunica a los distintos módulos del sistema. Cada módulo se suscribe a los mensajes con datos que le son de interés recibir, y el administrador se encarga de distribuir correctamente dichos mensajes y mantener el estado de conexión o desconexión entre cada módulo del sistema. La Figura 8 presenta esto de manera gráfica. Los mensajes enviados por los distintos módulos al servidor son representados por flechas. Como se puede observar, cada módulo envía variedad de eventos al servidor, y éste último los distribuye a sus suscriptores 39

41 Figura 8: Arquitectura Cliente-Servidor del simulador Módulo: Visualización y Comportamiento El módulo de visualización busca plasmar de manera realista los recorridos de cada una de las líneas de subterráneos junto con la simulación del comportamiento de los diferentes trenes, de acuerdo a los requerimientos particulares de la empresa SBASE en conjunto con los aportes de la operadora Metrovías. Se desarrolló un módulo visualizador utilizado en los puestos micro simulador (PMS) y los puestos de formación (PF) de todos los modelos de trenes y líneas de subterráneos a representar. 40

42 Funcionalidad La funcionalidad prevista para el módulo Visualizador corresponde a: Visualización realista y eficiente de los escenarios Simulación del comportamiento físico de los modelos de coche subterráneos según especificaciones técnicas Reproducción de sonidos originados en la cabina del coche, de la interacción del coche con las vías, o provenientes de las estaciones (anuncios, bocinas, murmullo de gente, entre otros) Configuración del escenario o del coche de acuerdo a la definición de ejercicios propuestos por el módulo de Instrucción Recopilación de información para que el módulo Controles actualice el estado de los indicadores del tablero Recepción e interpretación de los comandos provenientes del módulo Controles, para controlar el comportamiento físico del coche Visualización de otras formaciones circulando por la línea (línea ascendente o descendente, según corresponda) Visualización y animación de personas en los andenes de cada estación. La cantidad de personas depende de la configuración del ejercicio propuesto por el módulo Instructor. Solución El módulo Visualizador se diseñó como una estructura modular de componentes. Cada componente posee la mayor independencia posible, y trabajando en conjunto implementan la funcionalidad descrita. Este diseño favorece la extensibilidad y flexibilidad 41

43 del sistema para adaptarse a cambios que surgieron durante el desarrollo o puedan surgir en el futuro, o bien para la inclusión de nuevas líneas de subterráneos, nuevas formaciones de trenes o nueva funcionalidad referente a ejercicios u operatoria. En la Figura 9 se muestra un esquema de los componentes principales que forman el módulo Visualizador y la interacción entre ellos. Figura 9: Diagrama de los componentes principales del módulo visualizador y su interacción. Desarrollo Visualización realista El primer desafío es lograr una visualización realista de la escena de forma de maximizar la inmersión durante las prácticas. Para ello, se implementaron modelos de iluminación avanzados y una amplia biblioteca de materiales para representar las 42

44 secciones de túnel y estaciones, junto con diferentes efectos visuales como luces reflejadas sobre las diferentes superficies, o espejos ubicados en las estaciones. Se ha trabajado en una arquitectura flexible y extensible que permite administrar de forma eficiente los materiales. De esta manera, se simplificó la tarea de carga, eliminación o reutilización de recursos en los distintos escenarios; asegurando que se respeten las restricciones de tiempo real y manteniendo control del consumo de memoria. Relevamiento para el diseño de modelos 3D Esta etapa tiene como objetivo capturar un escenario real para su reconstrucción virtual, por lo que es fundamental la organización y el uso de un método que se pueda repetir para relevar todas las estaciones, logrando a su vez una buena calidad de imagen teniendo en cuenta las tecnologías utilizadas. Para obtener un correcto adiestramiento de los conductores, el simulador recreó de manera fidedigna cada uno de los recorridos de las líneas de subterráneos. La razón principal de esto que los conductores utilizan referencias visuales que van adoptando a medida que adquieren experiencia en la línea y luego les sirven para tomar decisiones operativas sobre la marcha (por ejemplo, al pasar por determinada caja eléctrica de determinado color debe comenzar a desacelerar para entrar a una curva) y también deben conocer a la perfección el recorrido para lograr un uso eficiente y seguro del material rodante. Por esta razón, la representación de la línea considera todas las particularidades y elementos de referencia que puedan ser utilizadas como ayuda durante la conducción del coche. 43

45 Una vez que los modelos 3D son diseñados, se visualizan mediante un motor de rendering y se les aplica movimiento mediante un motor de física. En las siguientes secciones se explica lo que implican dichas acciones. Tecnologías A continuación se describen las tecnologías y herramientas seleccionadas para realizar la implementación del módulo visualizador del simulador. Motor de rendering: OGRE OGRE (Object-oriented Graphics Rendering Engine) es un motor 3D flexible y orientado a la escena escrito en C++ diseñado para hacer más fácil e intuitivo producir aplicaciones que utilicen gráficos 3D acelerados por hardware. La biblioteca de clases abstrae todos los detalles del uso de las bibliotecas de sistemas subyacentes, como DirectX y OpenGL, y provee una interfaz basada en objetos del mundo y otras clases intuitivas. OGRE está diseñado para proveer una solución gráfica que se adapte a la mayoría de los casos; y se pueden encontrar varios frameworks o wrappers que permiten integrar rápidamente distintas bibliotecas para funcionalidad adicional como audio, interacción, etcétera. El código fuente de OGRE está disponible bajo licencia MIT, que básicamente significa que puede ser utilizado de la forma que sea. La única condición es que se distribuya el texto de licencia incluido en OGRE con cualquier software que utilice el motor. Un gran punto a favor del motor de rendering OGRE es la documentación disponible; ya que cuenta con una vasta cantidad de tutoriales, foros de discusión y ejemplos; y una gran comunidad activa de desarrolladores y usuarios que contribuyen al 44

46 crecimiento y actualización permanente del motor gráfico. Esto hace que un sistema programado sobre OGRE sobreviva en el tiempo y pueda ser extendido o modificado en el futuro. Motor de física: Bullet Physics Library Un motor físico es un software que permite resolver diferentes situaciones de simulación computacional, principalmente cuestiones como la dinámica de cuerpos rígidos (incluyendo detección de colisiones), dinámica de cuerpos blandos, e incluso dinámica de fluidos. Su principal aplicación es en videojuegos y simuladores, en cuyo caso las simulaciones deben ser resueltas con bajo costo computacional, permitiendo el tiempo real. Un motor físico permite también aplicar impulsos, fuerzas y velocidades en los objetos, de manera tal que se puede recrear un modelo matemático de comportamiento. En el caso de los trenes, se implementa el modelo matemático de comportamiento y se utiliza un motor físico para aplicar las fuerzas resultantes en los objetos. Existen varios motores físicos disponibles para uso libre o comercial. Entre los más reconocidos se pueden mencionar a Newton Game Dynamics, Open Dynamics Engine, Bullet Physics Library, Havok y PhysX [18]. Bullet Physics Library es uno de los motores físicos más reconocidos y ampliamente utilizados en videojuegos comerciales, películas y aplicaciones de diseño. En el sitio web de la referencia 18 se muestran muchos casos de uso exitoso del motor. Ha sido elegido por el equipo de visualización debido a que Media.lab del Instituto PLADEMA cuenta con vasta experiencia en el uso de Bullet Physics Library. El mismo fue empleado para simular los mecanismos de máquinas excavadoras y su interacción con el suelo en el proyecto citado anteriormente; y en otras aplicaciones como un simulador de 45

47 periscopio de submarino en que fue utilizado para recrear el movimiento de buques de superficie en diferentes condiciones de mar. Adicionalmente es una herramienta que el equipo ha utilizado hace ya varios años en diversos proyectos académicos y trabajos de investigación para formación de posgrado. Resultados La red de subterráneos de la Ciudad de Buenos Aires se encuentra representada en su totalidad por el sistema de simulación. La misma está compuesta de seis líneas (A, B, C, D, E y H), con una extensión total de 60,8 km (de los cuales 53,9 km son para servicio comercial) y 86 estaciones en operación. A continuación, se presentan diferentes capturas de los resultados obtenidos en el módulo visualizador para diferentes líneas y coches. Figura 10: Una de las 86 estaciones representadas por el sistema de simulación. 46

48 Figura 11: Visual desde el punto de vista del conductor entrando a la estación Puán en Línea A. Figura 12: Visual desde el punto de vista del conductor saliendo de Plaza de Mayo hacia Perú en Línea A. 47

49 Figura 13: Visual desde el punto de vista del conductor entrando a la estación Los Incas en Línea B. Figura 14: Visual desde el punto de vista del conductor viajando de la estación Medrano a la estación Ángel Gallardo en Línea B. 48

50 Figura 15: Visual desde el punto de vista de los pasajeros desde andén en la estación Constitución. Módulo: Controles e Interfaz Este módulo es el encargado de controlar un puesto alumno del simulador. Para ello se recrea un puesto de mando, con ergonomía y usabilidad para los operarios. En los PMS los controles se recrean con imágenes y animaciones (básicamente una interfaz gráfica o GUI), emulando los botones de la cabina real y en los puestos de formación se recrean con una combinación de hardware y software. El puesto puede instanciarse en cada uno de los tipos de trenes existentes en el parque rodante. Funcionalidad La funcionalidad del Módulo de Controles e Interfaz o Puesto Alumno, ya sea puesto de formación (PF) o los puestos micro simulador (PMS) es la siguiente: 49

51 Contar con un conjunto de controles que permita la operatoria completa de conducción de un tren subterráneo. Permitir la utilización de sistemas e instrumentos del tren como ATP, TCMS (SICAS), mediante interfaces idénticas a las reales. Permitir la comunicación con el puesto Instructor, mediante el intercambio de mensajes de audio de forma bidireccional. Solución Se implementó una arquitectura Modelo-Vista-Controlador (Model-View-Controller o MVC) [19]. Esta se basa principalmente en tres niveles: Modelo: representa la información con la que trabaja la aplicación, es decir, su lógica de negocio. Vista: transforma el modelo en una representación visual (o adaptador del hardware) que permite al usuario interactuar con ella. Controlador: se encarga de procesar las interacciones del usuario y realiza los cambios apropiados en el modelo o en la vista. La arquitectura MVC (Figura 16) separa la lógica de negocio (el modelo) y la presentación (la vista) con lo cual se consigue escalabilidad y mantenibilidad. Si un mismo control (por ejemplo, un botón) debe implementarse tanto de manera visual en una pantalla táctil como de manera física o en hardware en un tablero real, solamente es necesario crear un adaptador para dicho control o dispositivo; manteniendo el controlador y el modelo original. El controlador se encarga de aislar al modelo y a la vista de los detalles del protocolo utilizado para las peticiones. El modelo se encarga de la abstracción de la lógica relacionada con los datos, haciendo que la vista y las acciones sean independientes de la representación final del estado del subte. 50

52 Figura 16: Arquitectura MVC del módulo de controles. Tecnologías Para implementar un módulo encargado de visualizar y administrar controles se buscó el diseño de una plataforma de software extensible y lo suficientemente adaptable para distintas configuraciones. Asimismo, el sistema permite utilizar la misma base arquitectónica para los PMS (mayoría de controles en software y GUI) y los PF (mayoría de controles en hardware). 51

53 Tecnología: Qt / QML / C++ Qt es un framework para desarrollo de software de alta performance del tipo Crossplataform. Cuando hablamos de Qt hablamos de uso de bibliotecas/módulos como Qt- Quick, Qt-Core, Qt-Widgets, Qt-GUI y herramientas del tipo IDE como Qt-Creator. El uso Qt Quick permite moverse rápidamente entre el sketch de una idea y el prototipo. La clase QtWidget es la clase base de todos los objetos de interfaz de usuario. El widget es el átomo de la interfaz de usuario: éste recibe eventos del mouse, teclado y otros eventos del sistema de ventanas y pinta una representación de sí mismo en la pantalla. Cada widget es rectangular, y pueden ordenarse para ser dibujados en pantallas, permitiendo capas. El módulo de Qt GUI proporciona los habilitadores básicos para aplicaciones gráficas escritas con Qt [20]. Módulo: Instrucción Un puesto de instrucción podría definirse como el coordinador de un conjunto de puestos de pupitres y micro simuladores de entrenamiento. El puesto de instrucción puede ser más de uno, donde cada instructor administra un conjunto de simuladores. A continuación se enumeran las capacidades funcionales del puesto instructor. Previo a ello se aportan algunas definiciones. Instructor es quien se sitúa en el puesto de instrucción y lleva adelante la capacitación de los alumnos. Alumno quien se sitúa en el puesto de alumno (micro-simulador o pupitre) para realizar el entrenamiento correspondiente. 52

54 Operador Administrador es aquel que administra al resto de los operadores instructores. Funcionalidad El instructor puede seleccionar un simulador y elegir las estaciones inicial y final, configuración del coche, ejercicio y avería. El instructor puede seleccionar del catálogo un ejercicio para que realice el alumno en un simulador. En caso de seleccionar una falla o avería, el instructor puede indicar el lugar de aparición, el cual dependiendo del caso puede ser en una estación y/o en un circuito de vía aleatorio. El instructor puede ver un registro de acciones (log) que va realizando el alumno en el simulador en orden cronológico. El instructor será alertado por el sistema cuando un alumno cometa un error en el ejercicio. Por otro lado, sistema proporciona soporte para una base de datos de alumnos, organizados en grupos. También una base de datos de instructores, cada uno de los cuales cuenta con permisos concretos para la modificación de las bases de datos. Además, permite asociar una sesión de simulación con el alumno que la realizó, de manera que se puedan obtener históricos de la actividad y capacitación de cada alumno, así como de la efectividad didáctica de cada ejercicio. El sistema cuenta, en su interface, con una función que permite realizar backups a soporte digital de manera sencilla, mediante conexión en red, tanto de los ejercicios de la librería didáctica como de las sesiones de simulación de los alumnos, además de la base de datos de alumnos, instructores, etc. 53

55 Solución Cada puesto de instructor del sistema tiene bajo su control uno o más simuladores de entrenamiento, con los que se encuentra comunicado mediante una red local de alta velocidad, gestionando el funcionamiento de cada simulador, el inicio de los ejercicios de entrenamiento, la definición de los ejercicios, y el análisis de resultados y reportes. Se tiene además un repositorio centralizado donde se aloja el catálogo de ejercicios disponibles, como así también los datos de entrenamientos realizados, alumnos e historial de resultados y evaluaciones. La Figura 17 muestra una vista esquemática general de relación entre instrucción y los puestos. Figura 17: Vista esquemática general de puestos de Instrucción y puestos Alumno. 54

56 Arquitectura General Se creó una plataforma tecnológica desarrollada en lenguaje C# que pone a disposición del Módulo Instructor un conjunto de componentes de software que permiten brindar la funcionalidad mencionada. La Figura 18 muestra los principales componentes del módulo. Figura 18: Principales componentes de la arquitectura del módulo instructor. Como se puede observar existe un núcleo de componentes que gobiernan el puesto instructor propiamente dicho, y luego varios de ellos que se replican para cada simulador que se encuentre en funcionamiento en un momento dado. Máquina de Estados: Diagramación y especificación de ejercicios Uno de los componentes principales de la arquitectura propuesta es la máquina de estados, ya que es la que permite especificar y llevar adelante la evaluación de un ejercicio. 55

57 Cada ejercicio que el instructor selecciona en el simulador tiene asociada una máquina de estados. Se provee un catálogo de ejercicios del cual el instructor seleccionará el que será cargado a un simulador en particular. La máquina de estados permite especificar secuencialmente los pasos que deben seguirse de manera correcta para lograr satisfactoriamente el ejercicio propuesto. Esto se logra mediante la definición de la secuencia de estados a partir de un estado de inicio, y continuando hacia un estado final del ejercicio. El pasaje de estado a estado se da mediante transiciones, las cuales están ligadas a condiciones que deben cumplirse para ser realizadas. Estas condiciones se relacionan con eventos que se reciben en el puesto de instructor desde los simuladores y reflejan las acciones que lleva a cabo el alumno, por ejemplo el alumno mueve el selector de marcha a la posición AD en el pupitre. La Figura 19 muestra a modo de ejemplo los estados y transiciones principales que conforman el ejercicio de Tracción hacia Adelante. Figura 19: Estados y Transiciones para el ejercicio Puesta en Tracción. La máquina de estados resultante puede hacerse más compleja, definiendo más de un camino de ejecución entre el estado inicial y el final, agregando nuevos estados y transiciones. Se definen también estados erróneos a los que se llega mediante transiciones que son disparadas por acciones del alumno que serán consideradas erróneas en el contexto del ejercicio del puesto simulador. 56

58 La máquina de estados permite además la definición de ejercicios que se basen en otros previamente creados, por ejemplo, puede evaluarse individualmente el ejercicio de Puesta en Servicios del Tren, y aparte la puesta en tracción hacia adelante. Pero también se permite definir un nuevo ejercicio basado en los dos anteriores, que requiera al alumno primero poner en servicio el tren, y luego dar tracción hacia adelante. Para poder reutilizar la definición de las máquinas de estado de cada sub-ejercicio del ejercicio principal seleccionado, se definen estados compuestos, los cuales en su interior contienen máquinas de estado de un ejercicio ya definido previamente. A continuación la Figura 20 muestra la máquina de estados que podría definir el ejercicio que requiera al alumno poner en servicio el tren, ponerlo en movimiento y luego frenar y realizar apertura de puertas al arribar a la siguiente estación: Figura 20: Ejercicio basado en otros ejercicios (composición de estados). Los estados en color anaranjado representan aquellos que por sí mismos son ejercicios ya definidos en la librería de ejercicios y que están definidos mediante su propia máquina de estados. Por ejemplo, el estado inicial requiere la ejecución correcta por parte del alumno del ejercicio de Puesta en Servicio del tren. 57

59 Implementación del framework de simulación A partir de lo explicado anteriormente se puede afirmar que el framework desarrollado tiene como base teórica máquinas de estado finitas adaptadas para este propósito. Mantienen el estado del sistema mediante un seguimiento de las transiciones válidas que representan las acciones ejecutadas por el alumno. Estas llevan a estados que simbolizan la situación del ejercicio en un momento determinado a partir de dichas acciones [21]. Cada máquina de estados finita representa un ejercicio pedagógico. En adición a esto, es posible crear máquinas de estado que representen alguna alteración al curso normal de los ejercicios, como pueden ser averías que se activen en determinado momento de la ejecución. Estas máquinas son llamadas satélite y se activan ante alguna condición específica, siempre y cuando el instructor haya decidido incluirlas en el ejercicio en curso. El framework está compuesto por un conjunto de clases que permiten la creación mediante código de los ejercicios del catálogo. En la figura 21 se puede ver un diagrama de clases correspondiente al framework de simulación, y las de mayor relevancia se detallan a continuación. 58

60 Figura 21: Diagrama de clases del framework de simulación creado por MediaLab PLADEMA. StateMachine La clase StateMachine posee los atributos y métodos propios de las máquinas de estado finitas como representación lógica de los ejercicios pedagógicos. Según la definición presentada en el marco teórico, se puede afirmar que las máquinas de estado utilizadas para implementar los ejercicios son de tipo transductoras [22]. 59

61 Una característica importante que se mencionó en el capítulo anterior es la posibilidad de que una máquina esté contenida dentro de un estado de otra. Si durante la ejecución se llega a un estado que contiene una máquina, ésta comienza su ejecución y pasa al siguiente estado una vez que la misma haya finalizado. La propiedad Type indica que una máquina cumple con esta característica mediante la constante COMBINADO. En el caso de que no haya estados que contengan máquinas el valor de la propiedad sería SIMPLE. Al iniciar una simulación se obtiene el primer estado de la máquina y se procesa mediante el método ProcessState(). Este hace que se ejecuten las instrucciones del estado siempre que no sea estado final o su propiedad tipo sea Máquina de estado (State 60

62 machine), en cuyo caso se iniciaría la ejecución de la máquina interna. Durante el procesamiento del estado se obtienen sus eventos de transición, ejecutándose una vez que el servidor hace entrega de los mensajes recibidos por parte de los módulos de controles y visual. De esta manera se obtiene el siguiente estado, continuando la ejecución de la misma manera. Tipos de State Machine Existen distintos tipos de máquinas de estado según sus características: Simples: Son aquellas cuyos estados son todos simples, es decir, sin otra máquina anidada. Combinadas: Máquinas cuyos estados pueden contener una máquina internamente. Principales: Corresponden a los ejercicios principales, como puede ser uno de Curso normal. Satélite: Corresponden a máquinas de estado que modelan fallas o averías que se usan como complemento a máquinas principales. State Los estados que componen a las máquinas de estado se encuentran representados lógicamente por la clase State. Al instanciarla es posible incluir sus transiciones hacia otros estados, las instrucciones que se ejecutarán al llegar a esos estados y otras propiedades que permiten identificarlos. Por ejemplo, la propiedad Type indica si se trata de un estado inicial, intermedio, final o error. Los objetos de esta clase pueden representar estados propiamente dichos como en el planteamiento clásico de máquinas de estado, o bien englobar una completa máquina de estados que sólo se ejecuta cuando dicho estado esté activo. Este anidamiento de 61

63 máquinas sobre estados se puede hacer de forma recursiva. Para identificar de qué tipo de estado se trata se utiliza una propiedad (TypeState) cuyo valor será Normal cuando se trate de máquinas simples, o State Machine cuando una máquina contenga al menos otra anidada. Existen instrucciones que se ejecutan antes o después de llegar a un estado. Estas se encuentran en las propiedades StartInstructions y FinishInstructions, y son ejecutadas mediante los métodos ExecuteInstructionsStart() y ExecuteInstructionsFinish(). Estas instrucciones intervienen para indicar al resto de los módulos el estado de la simulación en un momento determinado. En el caso de que el instructor haya elegido incorporar al ejercicio alguna avería o situación alternativa al curso normal, representadas por máquinas satélite, las mismas se 62

64 activan una vez que se arriba a un estado disparador. El método Merge(State) une ambas máquinas mediante el nombre del estado que las dispara, formando así otra máquina completa que incorpora tanto el curso normal como la situación alternativa deseada. Esto permite la reutilización de máquinas satélite, ya que distintas máquinas de curso normal puedan hacer uso de las mismas. En las figuras a continuación se presentan los grafos correspondientes a un ejemplo de máquina principal mergeada con una máquina satélite. Figura 22: Máquina principal genérica. Figura 23: Máquina satélite genérica. 63

65 Figura 24: Resultado del merge entre máquina principal (Figura 22) y máquina satélite (Figura 23). Transition Las transiciones representadas mediante la clase Transition indican el siguiente estado a activarse cuando lo esté el estado de origen, es decir, dado un estado activo y del que se origina una transición a otro, si se cumplen las condiciones agregadas a la transición, dejará de estar activo el primero para pasar a estarlo el segundo (NextState). Si una transición no tiene ninguna condición se produce cada vez que se evalúa. Se trata de transiciones vacías, en las que no existe un evento que dispare la transición, pero puede o no tener una condición que debe evaluar. En el caso de que no tenga condición, implicaría que siempre que llega al estado mediante esta transición vacía va a pasar al otro estado. El tema es que seguramente la evaluación de esta transición vacía se hace una vez se haya recorrido y verificado que no se cumplen ninguna de las restantes transiciones salientes del estado, vendría a ser entonces como una transición por default. Sin embargo, 64

66 en general, las transiciones tienen alguna condición que debe cumplirse para que se produzcan, y estas se encuentran representadas por InstructionConditions: una lista de objetos de la clase ItemInstructions. Event Como se explicó anteriormente, el sistema funciona mediante el envío de eventos. Los mismos están compuestos por un nombre (Name), una clave (Value) y una subclave opcional (SubName). La clase Event provee estas propiedades para realizar verificaciones a los mensajes recibidos por el cliente, en este caso el módulo de instrucciones. Al recibir un mensaje se realizan chequeos mediante funciones de la clase InstructionFunction para transicionar de un estado a otro en la máquina de estados correspondiente al ejercicio en curso. 65

67 EventTransition Indica el evento que provocará que sea evaluada la condición de la transición. Todas las transiciones reaccionan ante los eventos que se producen en el desarrollo de funcionamiento de la máquina. Cada vez que se produce un evento provoca que se evalúen los estados y transiciones. InstructionFunctions Se pueden ejecutar funciones de instrucción tanto en las transiciones como en los estados, en las distintas opciones que contemplan, descritas en los apartados correspondientes. Entre las operaciones que son permitidas en la ejecución de instrucciones se encuentran las operaciones lógicas, chequeos de valores, envío de mensajes al servidor, entre otras. La totalidad de las funciones pertenecientes al framework pueden verse en detalle en su correspondiente Anexo I. Las funciones de instrucción reciben como parámetro objetos de la clase ItemParameter. ItemParameter Es la representación lógica de los parámetros pasados a las funciones de instrucción que se ejecutan en transiciones y estados. Por lo general están formados por una cadena 66

68 de caracteres que representan la clave y el valor (y opcionalmente subclave) enviados al servidor y luego recibidos por los suscriptores. De esta forma, cada vez que se reciba un evento por parte del servidor, el módulo instructor verifica que los valores del evento sean los correctos mediante los ejercicios implementados como máquinas de estado, como se explicó con anterioridad. ItemInstruction Al producirse un evento, expresa qué condición debe ser cierta para que se active la estado o transición y se ejecute la acción correspondiente. Las acciones pueden realizarse previo a ejecutarse un estado o luego de la ejecución del mismo. Como se mencionó al comienzo del capítulo, el framework de simulación se utiliza para una vasta diversidad de simuladores, se seleccionó el simulador de conducción de trenes subterráneos como ejemplo de instanciación. 67

69 Además, se tratará la implementación de la herramienta de soporte como es el caso del editor de ejercicios el cual es de suma importancia ya que el simulador es utilizado para capacitación de operarios, por lo tanto es necesario abarcar todos los escenarios posibles que se pueden dar en la realidad, para que los operarios finalicen su capacitación con una vasta experiencia que puedan reflejar a la hora de utilizar los equipos reales. Creación de ejercicios Uno de los principales usos del simulador, además de entrenar para la conducción, es hacer que los operarios enfrenten y resuelvan conflictos o averías que puedan encontrarse en el propio tren o en elementos de vía a modo de entrenamiento. El sistema incluye una amplia cantidad de ejercicios de catálogo, por ejemplo: puesta en servicio, puesta en marcha, resolución de avería en freno de emergencia. La cantidad de ejercicios de catálogo depende del simulador a implementar, incluyendo aquellos con resolución de fallas, operación y de seguridad. Además, el sistema permite la definición de ejercicios nuevos a partir de la modificación de ejercicios del catálogo. Dicha definición consiste en la selección sucesiva de valores para cada uno de los parámetros de configuración. Estos son modificables en cada ejercicio y son acordados con los expertos en el dominio, ajustando así las capacidades del simulador a los objetivos y criterios de formación. Mediante todos los parámetros modificables, el simulador es capaz de reproducir situaciones de línea degradada y ejercitar todos los diferentes tipos de bloqueo, así como introducir elementos no habituales en la circulación, como por ejemplo, estacionar el tren en una parada no prevista. 68

70 Diseño de ejercicios Como se mencionó en el Capítulo 2, la creación de ejercicios requiere de ciertos conocimientos por parte del desarrollador tanto de la lógica del sistema como de las características específicas del simulador a implementar y los ejercicios que éste necesite. Para esto es imprescindible que quien desarrolle los ejercicios tenga algún conocimiento del dominio a implementar, por lo que se requiere que los instructores o aquellos que tengan dicho conocimiento realicen una transferencia del mismo. Generalmente, la transferencia se realiza mediante documentos que explican el funcionamiento de la maquinaria replicada y que incluyen los procedimientos a seguir ante situaciones determinadas. Estos manuales de capacitación son interpretados por el equipo de desarrollo, que luego implementa los ejercicios según la lógica del simulador. Una vez realizados requieren de validación por parte de los instructores. Para ilustrar mejor esta situación se presenta un ejemplo de los pasos a seguir para la resolución de una de las averías presentes en el simulador desarrollado para los subterráneos de la Ciudad Autónoma de Buenos Aires, de los trenes CAF6000. Como se puede ver, el diagrama presenta el procedimiento que deben seguir los operarios al enfrentarse con una avería de Freno de estacionamiento. 69

71 Figura 25: Diagrama de flujo para la resolución de averías de freno de estacionamiento en la línea B. El diagrama sirve como referencia a los desarrolladores de ejercicios que deben tener en cuenta las distintas precondiciones y variables para configurar el simulador e implementar los ejercicios de acuerdo a las situaciones que se presentan en la realidad. Los ejercicios implementados utilizando el framework de simulación están representados mediante instanciaciones de las clases presentadas anteriormente. Esto significa que existe un objeto de la clase StateMachine por cada ejercicio pedagógico. Estos ejercicios se almacenan en archivos xml, ya que resulta simple su serialización mediante el método Serialize() del lenguaje C# en que está implementado el framework. 70

72 La serialización en formato xml, consiste en transformar los datos de manera tal que puedan ser transferidos por un canal (Internet, archivo plano, memoria, etc) a otro sistema [23]. En otras palabras, sirve para compartir información con otras aplicaciones transformando la información contenida en los objetos en un documento xml que será interpretado por el sistema destino. El código XML en el Anexo II representa la máquina de estados perteneciente al ejercicio de Freno de Estacionamiento de la línea B de la Figura 25. Como se puede observar, esta representación de las máquinas de estado resulta difícil de comprender a simple vista y requiere de un amplio conocimiento del framework de simulación. Problemática encontrada en caso particular Al obtener un simulador de entrenamiento, no solo se adquiere una herramienta de realidad virtual, sino que también un paquete pedagógico de formación que contiene las bases teóricas que debe poseer un operario y que serán reforzadas por prácticas en un ambiente virtual muy cercano a la realidad, para luego ser comprobadas en la máquina real. Para llevar a cabo esto, la tarea de la creación de ejercicios debe ser sencilla de manera tal de poder brindar un paquete pedagógico completo e incremental de acuerdo a las necesidades de quien adquiera el simulador. Es de suma importancia la creación de diversos ejercicios para cubrir toda la rama de situaciones necesarias para que un operador reciba el entrenamiento adecuado para desempeñar correctamente su labor en el mundo real. Esta tarea no es sencilla debido a que dichos ejercicios deben ser diseñados por un experto en el área y programados por un 71

73 desarrollador, acarreando así problemas de interpretación y aumentando los tiempos y costos de desarrollo. Como solución a estas problemáticas se propuso el desarrollo de un editor de ejercicios que utilice el framework de simulación ya desarrollado como sustento lógico para la creación o edición de ejercicios. Este editor de ejercicios sirve como herramienta de diseño gráfico interactiva que modela y simula sistemas dirigidos por eventos. Cuenta con un diseño intuitivo para que cualquier miembro del departamento de entrenamiento pueda diseñar y crear un ejercicio, sin la necesidad de contar con un programador experto que lo asesore. También sirve como ayuda para los desarrolladores ya que el editor posee verificaciones para disminuir la posibilidad de que los ejercicios contengan errores, ya sean ciclos en las máquinas de estado, estados no conectados o ausencia de estados claves para el desarrollo del ejercicio. Esto simplifica aún más la tarea de la creación de ejercicios. Estas máquinas además de tener un estado inicial deben ser acíclicas, ya que de lo contrario el ejercicio podría entrar en un bucle y nunca salir de él. El editor de ejercicios cuenta con verificaciones para que esto se cumpla. Además, permite hacer un seguimiento en tiempo real de la ejecución de los ejercicios. Reduciendo así costos operacionales, debido a que se simplifica en gran medida la tarea de crear un ejercicio y testearlo. 72

74 CAPÍTULO 4 Desarrollo de la herramienta de edición de ejercicios El editor como herramienta complementaria al framework de simulación, entonces, brinda la posibilidad de crear de manera fácil e intuitiva diversos ejercicios y visualizarlos inmediatamente. Facilita la transición desde un nivel pedagógico a uno lógico, representando acciones secuenciales gráficamente sin la necesidad de tener conocimientos de programación. Para incorporar correctamente al editor como complemento a los simuladores fue necesario hacer un análisis de las maneras en que pueden interactuar, siendo el envío de mensajes mediante el uso del servidor la más simple de lograr y la que finalmente se utilizó. A partir de su incorporación se puede hacer una representación de la nueva arquitectura del sistema, esta vez incluyendo al editor de ejercicios como suscriptor de eventos del módulo instructor, como se puede observar en la Figura

75 Figura 26: Arquitectura del sistema de simulación con el Editor incorporado como cliente suscrito a los eventos del módulo instructor. Por su parte, la estructura interna del editor se puede dividir en dos grandes módulos con funcionalidad específica: uno visual, conformado por clases de la biblioteca incluida y modificada para este fin; y uno lógico, conformado por las clases del framework de simulación descritas anteriormente. 74

76 Figura 27: Estructura interna de SMEditor. La herramienta utiliza el framework para obtener la representación lógica de las máquinas de estado creadas y editadas en ella, que posteriormente son utilizadas por el módulo instructor para la ejecución de los ejercicios. Por su parte, la biblioteca de visualización de grafos Graph-master ofrece un conjunto de clases que posibilitan la creación de nodos y conectores, adaptada para implementar correctamente la visualización y edición de las máquinas de estado que representan a los ejercicios. Las mismas se pueden asociar directamente a las del framework, ya que crea una representación visual de sus elementos. Fue creada por Sander van Rossen para Windows Forms y permite la creación de grafos direccionados de manera visual e intuitiva. Brinda la posibilidad de crear diagramas de flujo como representación de las máquinas de estado [24]. 75

77 Graph-master Las clases que se describen a continuación especifican el comportamiento de la biblioteca Graph-master. GraphControl La clase representa el control de usuario (UC) creado específicamente para manipular nodos y aristas de manera gráfica y simple. Tiene distintas propiedades que permiten el manejo de eventos y funciones del control. Así como ítems particulares de cada uno. 76

78 Node La clase Node facilita la manipulación de nodos. Como estos son utilizados para representar estados dentro de una máquina (ejercicio pedagógico), se ven asociados directamente con un objeto de la clase State del framework de simulación. NodeConnection Esta clase sirve como representación para las transiciones Transition del framework. Realiza conexiones entre nodos de un grafo con propiedades que determinan el nodo origen y el destino, así como el nombre (o evento) de transición. 77

79 NodeItem Representa los ítems de un nodo y ofrece los métodos para poder manipular sus acciones ante alguna interacción por parte del usuario. La incorporación de esta clase facilita en gran medida la manipulación de objetos de forma visual. Esto da como resultado una interfaz simple y amigable al usuario, en la que se integran todas las funcionalidades mencionadas a lo largo del capítulo. 78

80 Interfaz de Usuario y uso de la herramienta Uno de los atributos de calidad con mayor prioridad en la herramienta es su usabilidad. Es por esto que se decidió implementar la interfaz de la aplicación mediante el uso de DevExpress para Windows Forms [25]. Se trata de un framework de desarrollo muy difundido y con varios años en el mercado, con gran variedad de controles que permiten llevar a cabo la implementación de un software con una interfaz que resulta fácil de utilizar e intuitiva para el usuario. La herramienta también facilita el desarrollo de las principales funcionalidades del software de edición de ejercicios representados mediante máquinas de estados. Los más importantes se mencionan a continuación. 1. Creación de nuevos ejercicios Uno de los mayores beneficios que brinda la herramienta es la posibilidad de crear un ejercicio de manera simple, utilizando la lógica de máquinas de estado. Estas se representan mediante grafos, como se explicó anteriormente, y se muestran de forma gráfica al usuario, dándole la posibilidad de modificar todos los parámetros necesarios para su correcto funcionamiento. 2. Edición de ejercicios existentes Es posible cargar varios ejercicios existentes de manera simultánea usando el editor. Para esto solo es necesario seleccionar la línea a la que pertenecen el o los ejercicios que se desean visualizar o modificar utilizando la herramienta. 3. Almacenamiento de archivos en formato XML reconocidos por el framework de simulación Los ejercicios manipulados en el editor se cargan y almacenan en un directorio predeterminado. El mismo que utiliza el simulador para cargarlos. 79

81 4. Visualización de propiedades de los elementos que conforman a los ejercicios Permite visualizar y modificar las propiedades de máquinas de estado, sus estados, transiciones, y otros elementos que los componen, como ItemInstructions e ItemParameters (Capítulo 3 - Framework de simulación). 5. Generación de máquinas satélite Como ya se explicó, existen máquinas satélites que representan averías que pueden dispararse en distintos ejercicios principales. Es posible crear estas máquinas de manera simple a partir de otra existente, seleccionando la opción en el estado desde el que se desea que esa avería o máquina satélite comience. Esto generará automáticamente una nueva máquina de tipo satélite en una nueva pestaña del editor. Para realizar la unión de la máquina con otra principal ya creada, se puede utilizar la función de mergeo. 6. Mergeo de máquinas satélite con principales La herramienta permite hacer una combinación de máquinas principales con satélites, siempre y cuando estén creadas, guardadas y cargadas en la aplicación. El merge se realiza por nombre, es decir, el punto de unión entre dos máquinas es el estado cuyo nombre coincide en ambas. Esta funcionalidad existe en el framework y es utilizada en la implementación de SMEditor. Implementación de verificaciones y seguimiento de ejecución Como se mencionó anteriormente, la idea de complementar al framework con una herramienta de edición de ejercicios de manera gráfica surgió a partir de la necesidad de los desarrolladores de visualizar las máquinas que fueron creadas mediante código. Es por esto último que se incorporó como funcionalidad la verificación automática de algunas restricciones que exige la lógica en la que las máquinas se implementaron: la existencia de 80

82 ciclos en un grafo, o de un único estado inicial; asegurar que todos los estados de una máquina pueden llegar a un estado final o de error; o que no existan nodos a los que no se pueda acceder. Existen otras verificaciones que no requieren de algoritmos complejos que se realizaron mediante la interfaz, como es el caso de no permitir crear más de un estado inicial, o verificar que exista al menos un estado error. Otras verificaciones requieren de ciertos algoritmos para su ejecución. A continuación se presenta la clase que fue utilizada para implementarlos. Clase GraphHelper Para dar soporte a las verificaciones se creó la clase GraphHelper. Tomando como entrada una máquina de estados esta clase crea un grafo implementado como una lista de adyacencias. De esta manera se pueden ejecutar sobre el mismo los algoritmos de verificación que sean necesarios a la hora de crear un ejercicio. También se creó la clase NodeHelper que representa cada estado de la StateMachine. La clase GraphHelper posee tres métodos que son los encargados de realizar las verificaciones: HasCycle, HasEndedAndErrorState y CanArriveFromInitialState. Son tres algoritmos que fueron creados en base a Depth-First Search, DFS a partir de ahora, en el cual se recorre un grafo en profundidad. 81

83 El algoritmo DFS brinda una forma sistemática de encontrar todos los vértices alcanzables de un grafo desde un vértice de origen. Su funcionamiento consiste en ir expandiendo todos y cada uno de los nodos que va localizando, de forma recurrente, en un camino concreto. Cuando no quedan nodos por visitar en dicho camino regresa, repitiendo el mismo proceso con cada uno de los hermanos del nodo ya procesado. public void DepthSearch(ref int[] padre) { bool[] visitado = new bool[nodes.count + 1]; for (int i = 0; i < nodes.count; i++) { visitado[i] = false; padre[i] = -1; } for (int vertice = 0; vertice < nodes.count; vertice++) { if (!visitado[vertice]) { Dfs(vertice, ref visitado, ref padre); Print(padre); } } } private void Dfs(int v, ref bool[] visitado, ref int[] padre) { visitado[v] = true; List<NodeHelper> Adyacentes = DevolverAdyacentes(v); int it = 0; while (it < Adyacentes.Count) { if (!visitado[adyacentes.elementat(it).getid()]) { padre[adyacentes.elementat(it).getid()] = v; Dfs(Adyacentes.ElementAt(it).GetId(), ref visitado, ref padre); } it++; } } El método HasCycle tiene como objetivo encontrar ciclos en las máquinas de estado. Se dice que hay un ciclo cuando tomando un vértice como origen existe algún camino que permita volver a él. Para detectar si hay ciclos en un grafo se puede adaptar el algoritmo de DFS de la siguiente manera. 82

84 public bool HasCycle() { NodeHelper n = nodes.elementat(0); int[] visit = new int[nodes.count]; bool cycle = false; for (int i = 0; i < nodes.count; i++) { visit[i] = 0; } cycle = HasCycle(0, visit); return cycle; } private bool HasCycle(int v, int[] visit) { bool found = false; visit[v] = 1; List<NodeHelper> ady = nodes.elementat(v).getady(); int i = 0; while ((i < ady.count) && (!found)) { if (visit[ady.elementat(i).getid()] == 0) found = HasCycle(ady.ElementAt(i).GetId(), visit); else { if (visit[ady.elementat(i).getid()] == 1) { found = true; } } i++; } visit[v] = 2; return found; } De esta forma, se usa un vector que indica si un nodo ya ha sido visitado, en caso de visitar el mismo nodo dos veces se reconoce que hay un ciclo. Según la lógica por la cual se rigen los ejercicios del simulador, todos los estados deben poder llegar a un estado final. Este estado final puede ser un estado de acierto o de error, por lo tanto para que los ejercicios representados en máquinas de estado estén correctamente implementados, no debe haber un camino en la máquina que no llegue a alguno de estos dos tipos de estado final. Para poder verificar esto se creó HasEndedAndErrorState, un algoritmo que también toma como base al DFS. 83

85 public List<string> HasEndedAndErrorState() { List<string> error = new List<string>(); bool[] visitado = new bool[nodes.count]; for (int vertice = 0; vertice < nodes.count; vertice++) { for (int i = 0; i < nodes.count; i++) { visitado[i] = false; } bool found = false; if (DfsHasEndedAndErrorState(vertice, ref visitado, ref found)) { Console.WriteLine(vertice + " llega a un estado final o de error"); } else { Console.WriteLine(vertice + " no llega a un estado final o de error"); error.add(nodes.elementat(vertice).getname() + " no llega a un estado final o de error"); } } return error; } Este método devuelve una lista con todos los nodos que no alcanzan un estado final, de éxito o de error. private bool DfsHasEndedAndErrorState(int v, ref bool[] visitado, ref bool found) { visitado[v] = true; List<NodeHelper> Adyacentes = DevolverAdyacentes(v); int it = 0; if((nodes.elementat(v).gettipo()=="error") (nodes.elementat(v).gettipo()=="final" )) { found = true; } else { while (it < Adyacentes.Count) { if (!visitado[adyacentes.elementat(it).getid()]) { if((adyacentes.elementat(it).gettipo()=="error") (Adyacente s.elementat(it).gettipo() == "Final")) { found = true; } else 84

86 } } } return found; } it++; { } DfsHasEndedAndErrorState(Adyacentes.ElementAt(it).Get Id(), ref visitado,ref found); Recorriendo el grafo en profundidad, cuando encuentra un estado de error o final, devuelve true, en caso contrario sigue recorriendo el grafo. En caso de no encontrar un estado de error o final, devolverá false, y el vértice se añadirá a la lista de los que no llegan a estados finales. Todos los estados deben poder ser alcanzados en el momento que se está ejecutando la simulación y, para que esto sea posible, cada estado de la máquina tiene que poder ser arribado desde el estado inicial. Para corroborar eso se implementó CanArriveFromInitialState, un algoritmo similar al anterior. public List<String> CanArriveFromInitialState() { bool[] visitado = new bool[nodes.count]; List<String> error = new List<string>(); List<NodeHelper> IGraf = InvertirGrafo(); for (int vertice = 0; vertice < nodes.count; vertice++) { for (int i = 0; i < nodes.count; i++) { visitado[i] = false; } bool found = false; if (DfsCanArriveFromInitialState(IGraf, vertice, ref visitado, ref found)) { Console.WriteLine(vertice + " puede ser arribado desde el inicial"); } else { Console.WriteLine(vertice + " no puede ser arribado desde el inicial"); error.add(nodes.elementat(vertice).getname() + " no puede ser arribado desde el inicial"); } } return error; 85

87 } El algoritmo es similar al utilizado para detectar que se pueda llegar a un estado final. La diferencia es que se invierte el grafo y se verifica si se puede arribar al estado inicial, que luego de invertir el grafo, pasaría a ser un estado final. Esta función devuelve todos los nodos que no pueden ser arribados desde el estado inicial. private bool DfsCanArriveFromInitialState(List<NodeHelper> IGraf, int v, ref bool[] visitado, ref bool found) { visitado[v] = true; List<NodeHelper> Adyacentes = IGraf.ElementAt(v).GetAdy(); int it = 0; if (nodes.elementat(v).gettipo() == "Initial") { found = true; } else { while (it < Adyacentes.Count) { if (!visitado[adyacentes.elementat(it).getid()]) { if (Adyacentes.ElementAt(it).GetTipo() == "Initial") { found = true; } else { DfsCanArriveFromInitialState(IGraf, Adyacentes.ElementAt(it).GetId(), ref visitado, ref found); } } it++; } } return found; } Adaptación del DFS, en el cual se recorre el grafo en profundidad, cuando llega al estado inicial, devuelve true en caso contrario sigue recorriendo el grafo. En caso de no llegar nunca a un estado inicial, el vértice se añadirá a la lista de los vértices que no pueden ser arribados desde el estado inicial. 86

88 Seguimiento de una ejecución Una de las mayores complicaciones que surge a la hora de crear ejercicios es la búsqueda de posibles errores. Las verificaciones mencionadas anteriormente sirven para salvar algunos de estos errores, ya que tienen que ver con la parte sintáctica de las máquinas de estado. Pero existen errores que sólo se pueden detectar realizando pruebas mediante la ejecución del ejercicio completo. Es por esto que fue necesario agregar una funcionalidad que muestre en tiempo real el estado de la ejecución del simulador. Para esto se utiliza la representación gráfica del ejercicio, creada a partir de la máquina de estados del mismo. Como ya se sabe, dicha representación es un grafo, cuyos nodos cambiarán de color a medida que vaya avanzando la ejecución del ejercicio. A la hora de probar es necesario que los ejercicios hayan sido implementados correctamente. Facilita en gran medida la tarea de crear ejercicios complejos, en los cuales es muy fácil cometer errores a la hora de ser desarrollados. Esta funcionalidad se logra mediante la interacción del módulo instructor y el SMEditor. Para llevar a cabo la misma se requiere que el SMEditor sea informado del cambio de estado, es decir en qué estado de la máquina se encuentra la ejecución actual del simulador, y cuál fue la transición que provocó este cambio. Lo que se busca es implementar esto sin tener que modificar el código del instructor, y para lograr esto se estudiaron distintos enfoques. Al tener esta problemática, intuitivamente se pensó en la programación orientada a aspectos, POA a partir de ahora, y en usar reflexión para llevar a cabo este cometido, ya que proporciona objetos que describen ensamblados, módulos y tipos. Se puede utilizar 87

89 para crear, invocar sus métodos o tener acceso a sus campos y propiedades. Esto permite agregar comportamiento a una clase, sin necesidad de modificarla. Luego se optó por descartar POA debido a que C# no tiene una funcionalidad incorporada para esto, se necesita un framework, como PostSharp, para hacer 'bytecode weaving'. Se trata del proceso de aplicar Aspectos a los Objetos Destinatarios para crear los nuevos objetos resultantes, lo cual en un principio nos dio desconfianza debido al desconocimiento de cómo el framework trabajaba y a que nunca habíamos usado POA para resolver una problemática. Una vez descartada esta solución se optó por usar el patrón de diseño Observer tradicional. Este permite reaccionar a ciertas clases llamadas observadores sobre un evento determinado. Es usado en programación para monitorear el estado de un objeto en un programa en tiempo de ejecución. Está relacionado con el principio de invocación implícita. La motivación principal de este patrón es su utilización como un sistema de detección de eventos en tiempo de ejecución. El problema de esta solución era que obligaba a tener al SMEditor y al módulo de instructor en el mismo ejecutable. Luego de evaluarlo se decidió que era mejor que sean dos aplicaciones separadas, para dar más libertad al uso del SMEditor ya que esto permite que el mismo se utilice para la creación de ejercicios de distintos simuladores en un futuro. Por lo tanto, se decidió hacer una adaptación del patrón observer utilizando el servidor como canal para el envío de mensajes desde el instructor hacia el editor, manteniendo a este último al tanto de la ejecución de los ejercicios en el simulador. A partir de la información que obtiene por estar suscrito a los eventos del instructor, el editor puede realizar un seguimiento de la ejecución en tiempo real, reflejando exactamente el estado en el que se encuentra la misma en un momento determinado. 88

90 Luego de implementar la funcionalidad utilizando esta técnica se pudo ver que la solución era desprolija y que introducía código y comportamiento en una clases y funciones del framework. Es decir, se había agregado comportamiento que no era inherente a clases cómo State y StateMachine, existiendo la posibilidad de evitarlo, ya que en un diseño con una buena separación de concerns deberían ser métodos propios de otro módulo encargado de monitorear a esas clases en tiempo de ejecución. Esto derivó en volver a optar por el camino del uso de POA. Para esto se hizo uso del framework PostSharp. Si bien este framework tiene una versión paga, la versión gratuita contiene las suficientes características para ser funcional a la problemática a resolver. La solución usando POA no llevo más que unas pocas líneas de código y no fue para nada intrusiva, en contraposición a la solución POO (Programación orientada a objetos). Para llevar a cabo esta solución en primer lugar se creó el aspecto TracingSender, que incluye tanto los Aspectos de PostSharp como el framework de simulación: using PostSharp.Aspects; using Simulator.StateMachine; using System; namespace Simulator.StateMachine { [Serializable] class TracingSender : OnMethodBoundaryAspect { public static void Update(string data, Simulator sim) { var key = "i_data"; var value = data; sim.sendmessage(key, value); } public override void OnEntry(MethodExecutionArgs args) { object[] parametros = args.arguments.toarray(); StateMachine statemachine = (StateMachine)parametros[0]; Transition transition = (Transition)parametros[1]; State next = statemachine.getstatebyname(transition.nextstate); 89

91 } transition); } } var position = next.getpositiononeventtransitionlist(next, var data = string.join(",", next.name, position); Update(data, statemachine.simulatorparent); Luego se incorporó este aspecto al método que requería ese comportamiento: public class State : ICloneable... [TracingSender] private bool ProcessTransition(StateMachine sm, Transition t, Event eventtransition){ }... Luego de haber implementado ambas soluciones se pudo concluir que la solución POA es ampliamente mejor que la POO, ya que el uso de aspectos proporcionó un bajo acoplamiento, mayor cohesión y reducción de líneas de código. Todo esto lleva a un código más entendible, mantenible y testeable. 90

92 CAPÍTULO 5 Uso de la herramienta de edición de ejercicios Introducción En el presente capítulo se muestran distintas instanciaciones de los ejercicios que pueden ser editados utilizando la herramienta SMEditor para probar sus aspectos más relevantes. El objetivo fue evaluar la las funcionalidades implementadas y detalladas en el Capítulo 4 y la facilidad de integrar la herramienta al sistema de simulación en términos de arquitectura. Inicialmente se explica cómo crear cada uno de los distintos tipos de máquinas y se hará una comparación de cómo debería crearse cada una si no se hiciera uso del SMEditor. Luego, se detalla cada una de las verificaciones que soporta el editor, con una demostración de cómo encontrar cada uno de esos potenciales errores sin el uso de la herramienta. También se mostrará un ejemplo de seguimiento y se explicará cómo 91

93 configurar el editor para realizarlo. Por último se presentan algunas conclusiones generales acerca del uso de la herramienta y las ventajas que presenta. Además, es necesario mencionar que para probar correctamente algunas de las funcionalidades fue necesaria la creación de una herramienta que soporte el envío de eventos al servidor, emulando una simulación, cuyo uso se detalla al final del presente capítulo. Creación de ejercicios Como se ha mencionado en el capítulo anterior, existen distintos tipos de máquinas de estado que representan a sus respectivos tipos de ejercicios del catálogo que acompaña a los simuladores. A continuación se presenta la forma en que estos ejercicios pueden ser creados utilizando la herramienta de edición, haciendo una comparación con la forma en que se crean mediante código en C# (ver Anexo II) y se visualizan en archivos XML. Los ejercicios utilizados como ejemplo forman parte del catálogo correspondiente a la línea B de subtes de la Ciudad Autónoma de Buenos Aires. Máquina de estado Simple Las máquinas de estado simples corresponden a aquellos ejercicios con estados simples, es decir, que no tienen máquinas anidadas. Como se puede ver en las capturas presentadas a continuación, la representación de un ejercicio simple en el editor mediante máquinas de estado permite una mejor visualización de los estados del simulador y los eventos que permiten la transición entre ellos, en comparación a su representación en formato XML. Resulta complicado 92

94 comprender la totalidad de un ejercicio leyendo el archivo XML en el que está almacenado, y mucho más detectar posibles errores (ver ejercicio de Tracción Hacia Adelante en formato XML en el Anexo II). Figura 28: Visualización del ejercicio Tracción hacia adelante de la línea B en la herramienta de edición SMEditor. A su vez, se puede realizar una comparación con la forma en que las máquinas deben ser creadas mediante código C# (Anexo II). Como se puede observar en el código anexado, la creación de una máquina implica un amplio conocimiento tanto del lenguaje que se usa para implementarla como de las características del framework de simulación. Por otro lado, resulta muy difícil detectar errores simples, como puede ser la ausencia de alguna transición o estado importantes. 93

95 Máquina de estado Combinada Las máquinas de estado combinadas son aquellas en las que al menos uno de sus estados contiene otra máquina que será ejecutada al arribar a él. Como se puede observar en la Figura 30, el atributo Type tiene como valor Combinado. Esto significa que alguno de los estados de la máquina contiene otra anidada. Figura 29: Máquina de estados correspondiente al ejercicio de Curso Normal de la Línea B. Figura 30: Atributos de la máquina de estados del ejercicio de Curso Normal. 94

96 En el ejemplo, al seleccionar el estado CNEstadoTraccionHaciaAdelante (Figura 31), se puede notar cómo su atributo TypeState, que indica si un estado es simple o si contiene una máquina, tiene el valor StateMachine (Figura 32). Esto significa que hay una máquina anidada en el estado seleccionado, cuyo nombre se encuentra en el atributo FileNameExercise: TraccionHaciaAdelante.xml. Figura 31: Estado seleccionado CNEstadoTraccionHaciaAdelante. Figura 32: Atributos del estado CNEstadoTraccionHaciaAdelante. 95

97 El ejemplo a continuación (Figura 33) muestra la forma en que se puede agregar una máquina de estados a un estado de otra, haciendo click derecho sobre el mismo y seleccionando la opción Combinada. Esto despliega un diálogo que permite seleccionar una máquina creada anteriormente para que pase a estar anidada a la actual. En la Figura 36 se puede observar el resultado de la selección: el atributo TypeState cambió a StateMachine y el valor del atributo FileNameExercise pasó a ser el nombre de la máquina seleccionada, Puesta En Servicio Manual. Figura 33: Pop-up que se despliega al hacer click derecho sobre el estado al que se desea anidar otra máquina. 96

98 Figura 34: Diálogo de selección de la máquina que se desea anidar. Figura 35: Resultado del anidamiento. La máquina principal se conserva pero los atributos del estado seleccionado muestran la nueva incorporación. 97

99 Figura 36: Detalle de los atributos del estado DAEstadoConmutadorPuestaEnServicioAutomatica al que se incorporó la máquina Puesta en Servicio Manual. Máquina de estado Principal Las máquinas principales corresponden a aquellas que representan a los ejercicios normales. Es decir, aquellos de los que luego se desprenden averías representadas por máquinas satélites. Figura 37: Máquina de estados principal que representa el ejercicio de Desconexión Automática. 98

100 Figura 38: Detalle de los atributos de la máquina de estados principal del ejercicio Desconexión Automática. Máquina de estado Satélite Como se explicó antes, una de las ventajas que ofrece la plataforma es la posibilidad de crear y visualizar máquinas de manera simple. A esto se suma la facilidad que ofrece para crear máquinas que representan averías como son las máquinas satélite. Una de las características de las máquinas satélites es que, a diferencia de las principales, no poseen estados iniciales o finales. Esto se debe a que el merge entre éstas se realiza utilizando el nombre del estado en el que se desea que ocurra la unión. En el ejemplo de la Figura 39 se observa la máquina perteneciente a la avería Térmico lazo de emergencia y repone, cuyo estado disparador es CNEstadoMovimiento (que pertenece a la máquina principal con la que desea unirse). Como se puede observar, el estado de inicio de la avería es uno de tipo intermedio. Esto es posible ya que la restricción de tener siempre un estado inicial no aplica a las máquinas de tipo satélite y, como se puede ver en la Figura 40, se trata de una máquina con esta característica. 99

101 Figura 39: Máquina de estado satélite perteneciente a la avería Térmico lazo de emergencia y repone. Figura 40: Detalle de los atributos de la máquina de estado satélite Térmico lazo de emergencia y repone. Merge Otro de los beneficios que brinda la herramienta es su capacidad de realizar la unión automática de máquinas principales y satélites, permitiendo ver el resultado de este merge de manera inmediata. 100

102 Las imágenes a continuación presentan la avería Coche Frenado y Desfrena - Resuelve con Resolución de Avería (Figura 42) correspondiente al ejercicio principal Curso normal (Figura 41) de la Línea H, uniendo ambas máquinas de estado y obteniendo como resultado final su visualización en una nueva ventana (Figura 43). Figura 41: Máquina principal correspondiente al ejercicio Curso normal de la línea H. 101

103 Figura 42: Máquina satélite de la avería Coche Frenado y Desfrena - Resuelve con Resolución de Avería. Figura 43: Resultado final - Merge automático entre máquina principal y máquina satélite seleccionada. 102

104 Detección de errores Como ya se ha dicho, la creación de ejercicios implica muchas restricciones del dominio. Estas restricciones pueden generar errores si no son tomadas en consideración por quien los crea. Gracias a la implementación de la plataforma de edición, estos errores son detectados de manera automática. La forma en que los errores son presentados se puede ver en la Figura 44, donde se dan varias situaciones no deseables. Al intentar guardar el ejercicio aparecerá en el extremo inferior derecho una sección de warnings que lista dichas situaciones. El ejercicio será guardado, pero el usuario está notificado de las situaciones que pueden llegar a causar errores al momento de ejecutar el ejercicio. Figura 44: La creación de una máquina de estados que presenta errores y los warnings indicando cada uno de ellos en el extremo inferior izquierdo. 103

105 Estado inaccesible Un error fácil de cometer es el de crear un estado al que no puede accederse desde el estado inicial, es decir no hay un camino lógico que permita llegar a él. Antes de que se creen las verificaciones automáticas, el desarrollador debía mirar el XML, prestar atención a que cada estado creado tenga un predecesor y que exista un camino desde el estado inicial para llegar a él. Con las verificaciones automáticas el desarrollador será informado en caso de que esto suceda. En la Figura 45 se observa un estado que no puede ser accedido desde el estado inicial de la máquina y, como consecuencia, al intentar guardar los cambios realizados se muestra en la sección del margen inferior izquierdo un warning indicando cual es el estado que no puede ser alcanzado. Figura 45: Estado inaccesible desde el estado inicial. 104

106 No se puede llegar a un estado final o error Por mera distracción podría suceder que haya estados que no lleguen de ninguna manera a un estado final o de error. Para evitar que el error pase inadvertido se creó una verificación automática que notifica al desarrollador la presencia del mismo. La única forma de detectarlo sin usar SMEditor es una ardua búsqueda y análisis del archivo XML correspondiente al ejercicio. El editor, en cambio, emite un warning que avisa al desarrollador que esto sucede. Figura 46: Máquina de estados con un estado que no tiene acceso a uno final. Ciclo en la máquina de estados Si bien no es un error, se decidió advertir al desarrollador que la máquina de estados posee un ciclo, ya que es posible que este ciclo no haya sido creado adrede, lo cual podría generar ciclos infinitos en la máquina de estado y conflictos en la ejecución del ejercicio. Detectar esto desde un archivo XML resulta casi imposible, pero con la 105

107 incorporación de SMEditor se facilita, ya que muestra al usuario un mensaje de warning como puede apreciarse en la figura 47. Figura 47: Máquina de estados que contiene un ciclo. El warning a la derecha facilita su detección, además de poder visualizarse de manera clara en el grafo. Existencia de estado error El editor posee la comprobación de que exista un estado de tipo error en la máquina de estados. En caso de no tenerlo, un warning advertirá esto en el inferior izquierdo del a pantalla, como se observa en la Figura

108 Figura 48: Máquina de estados que no contiene un estado de tipo error. Se presenta una advertencia en el margen inferior izquierdo. Herramienta para debugging de ejercicios Para poder hacer el debugging de ejercicios mediante un seguimiento en tiempo real fue necesaria la implementación de una herramienta que facilite el envío de eventos al servidor. La misma permite realizar el envío de eventos por parte de uno o más clientes conectados y de esta forma simular la ejecución de los diversos componentes del simulador. Los eventos y sus valores se encuentran en archivos.csv generados automáticamente por el servidor al realizar la ejecución manual de los ejercicios en el simulador (log), o.xlsx creados por el usuario. A su vez se pueden editar y guardar cambios a los archivos desde la herramienta 1. 1 Para guardar cambios en los archivos.csv es recomendado hacerlo desde la herramienta, ya que desde otro programa se cambia el formato necesario para ejecutar en la misma. 107

109 Figura 49: CSV generado por el servidor Figura 50: CSV generado por el servidor y cargado en la herramienta de envío de eventos La herramienta además posee funcionalidades que permiten un debugging más eficiente. Una de ellas es la utilización de flags que permite determinar un punto de inicio (I) y fin (F) de la ejecución automática, colocando el flag correspondiente en la segunda columna. Además existe otro que permite saltear el envío del evento correspondiente a la línea en la que se coloca el flag S. En combinación con la opción de ejecutar automáticamente el envío de mensajes, esto facilita enormemente el testeo de ejercicios. 108

110 Utilización de la herramienta Cargado y guardado de archivos Se puede seleccionar un archivo con formato.csv,.xlsx o.xls, modificarlo dentro de la herramienta, y guardar los cambios con los botones situados a la izquierda (Figura 51). Figura 51: Vista inicial de la herramienta de envío de eventos. A su vez, seleccionando la opción de Guardar con flags, la segunda columna que contiene los flags de ejecución se guardará para uso futuro. Por el contrario, la opción Guardar como, solo guarda de la columna de Timestamp en adelante. 109

111 Conexión de clientes Se pueden seleccionar y conectar los clientes al servidor, ingresando IP y puerto, tildando Conectar cliente, y presionando el botón Conectar clientes del panel inferior izquierdo. Por cada uno: Figura 52: Conexión del cliente v_simulador_1. Los clientes que se encuentran conectados se identifican como se muestra a continuación. Pueden desconectarse tildando Desconectar cliente y presionando el botón Desconectar clientes del panel inferior izquierdo. Figura 53: Desconexión del cliente c_simulador_1. 110

112 Ejecución automática Como se explicó anteriormente, se creó una funcionalidad que consiste en el envío automático de los mismos para facilitar el envío de mensajes contiguos. Esto disminuye el tiempo que toma el testeo, ya que se pueden colocar flags que permiten detener la ejecución automática según las necesidades del desarrollador en cada caso. Para activar la ejecución automática de ejercicios, se posiciona en On, se coloca el selector en la primera fila de la columna Clave y se inicia con el botón Enviar. Se puede elegir el tiempo de retardo entre mensajes enviados al servidor. Se puede pausar una ejecución automática y reanudarla con el botón Enviar. Para ejecutar el envío de mensajes manualmente la opción de Automático debe estar en Off, se debe posicionar el selector en una celda de la columna Claves y pulsar el botón Enviar. Figura 54: Activación del envío automático, con tiempo de demora (izquierda). Botones para control del envío de eventos: inicio y pausa (derecha). Se puede resetear una ejecución mediante el botón Resetear Ejecución. Esto eliminará las marcas de la ejecución actual. A su vez, pueden colocarse breakpoints con el flag B en la segunda columna. Estos permiten detener la ejecución automática y reanudarla mediante el botón Enviar. Se 111

113 puede configurar la ejecución para que tenga en cuenta los breakpoints colocados en los mensajes de cada cliente (Figura 55). Figura 55: Activación de los breakpoints del cliente v_simulador_1. Como también el uso o no del tiempo de ejecución de la columna Timestamp (Figura 56). Figura 56: Activación de Saltear timestamp para los eventos del cliente v_simulador_1. Flags de ejecución Las marcas de ejecución son asteriscos que se insertan en la primera columna luego de que el mensaje ha sido enviado al servidor. En caso de que algún mensaje no se haya enviado, el asterisco de la fila correspondiente a ese mensaje será de color rojo. Como ya se explicó, en caso de que no se desee ejecutar el ejercicio completo se pueden insertar flags para indicar el inicio y fin de la ejecución. Estos se indican con una I o 112

114 F, respectivamente, en la segunda columna. Además, se puede saltear una fila marcando la columna con una S, y colocar breakpoints con un B. A continuación, se muestra un ejemplo de ejecución automática. Figura 57: Vista completa de la herramienta de envío de eventos en medio de una ejecución. Como se puede observar en la Figura 57, el cliente i_simulador_1 se encuentra desconectado, por lo que los mensajes i_iniciar_simulador, i_config_vagones e i_tramo_inicial no han sido enviados y su marca es roja. La ejecución comenzó en la segunda fila, donde se encuentra la marca I y finalizó en la fila anterior a la marca de finalización (F). Las filas con la marca S fueron salteadas, por lo tanto, los mensajes no fueron enviados. La fila con marca B ha sido saltada, la ejecución pausada y reanudada manualmente por el usuario. 113

115 El simulador en la columna Simulador debe coincidir con el seleccionado para que el mensaje pueda ser enviado (Figura 58). Caso contrario, el mensaje no será enviado y la marca será roja. Figura 58 Stress Test En la versión 4.2 de la herramienta se agregó la función de ejecutar un test de stress, enviando los mensajes de manera automática, sin mostrar la ejecución de forma visual. El objetivo de un test de stress es determinar la solidez de la aplicación ante una carga extrema. Es decir, realizar el envío de muchos mensajes al servidor en un tiempo reducido para detectar posibles errores por sobrecarga. La ejecución se realiza con el botón de la esquina superior izquierda Ejecutar > Stress Test. 114

116 Figura 59: Selección de la ejecución de un test de stress. Se puede seleccionar un tiempo de demora entre el envío de un mensaje y otro, utilizando el selector de segundos del panel inferior. NOTA: Para que funcione correctamente, las filas con mensajes deben ser consecutivas. Evitar líneas en blanco. Seguimiento de ejercicios en tiempo real El seguimiento de un ejercicio en tiempo real utilizando el editor es de gran utilidad a la hora de crearlos, ya que es la única forma de detectar algunos de los errores de diseño 115