Modelado de escenarios para electromovilidad en entornos urbanos

Proyecto Fin de Carrera Ingeniería de Telecomunicación Formato de Publicación de la Escuela Técnica Superior de Ingeniería Autor: F. Javier Payán Somet Tutor: Juan José Murillo Fuentes Dep. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2013 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías Industriales Modelado de escenarios para electromovilidad en entornos urbanos Autor: Juan Carlos García Brenes Tutor: Carlos Vivas Venegas Dpto. Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2023 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías Industriales Modelado de escenarios para electromovilidad en entornos urbanos Autor: Juan Carlos García Brenes Tutor: Carlos Vivas Venegas Profesor Titular Dpto. Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2023 Trabajo Fin de Grado: Modelado de escenarios para electromovilidad en entornos urbanos Autor: Juan Carlos García Brenes Tutor: Carlos Vivas Venegas El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores: Presidente: Vocal/es: Secretario: acuerdan otorgarle la calificación de: El Secretario del Tribunal Fecha: Agradecimientos En primer lugar quisiera darle las gracias a mi familia que siempre me ha estado apoyando y me han dado la oportunidad de realizar estos estudios universitarios. También me gustaría mostrar mi agradecimiento a mi tutor, Carlos Vivas Venegas por ayudarme resolviendo o aclarando algunas dudas que me iban surgiendo durante la realización de este trabajo. Sus sugerencias y comentarios han sido importantes para la realización de este. Para terminar quería darle las gracias a todos aquellos que, de una u otra manera, han contribuido en este trabajo y han sido parte fundamental de mi formación académica. Juan Carlos García Brenes Sevilla, 2023 I Resumen Los vehículos eléctricos representan cada día un mayor porcentaje del parque móvil global. Por ello, existe la necesidad de dotar de infraestructuras y procedimientos de carga adecuados a estos vehículos, lo que presenta un problema aún no resuelto que implica grandes retos desde el punto de vista de la generación eléctrica y de la distribución de estas infraestructuras. En este proyecto se pretende utilizar herramientas de simulación apropiadas para escenarios de este tipo. Se busca adaptar el simulador de código abierto llamado Eclipse SUMO (Simulation of Urban Mobility) e integrarlo con Matlab o Python como herramienta de monitorización y control de gestión de tráfico. La idea principal es crear un conjunto de escenarios en SUMO donde circulen continuamente un gran número de vehículos eléctricos. Estos circularán respetando los semáforos, límites de velocidad y prioridades en las intersecciones, con el fin de que la simulación sea lo más realista posible. En este escenario de simulación también se incluirán numerosas estaciones de carga donde los vehículos se pararán a cargar su batería. Dicha simulación se controlará a través de un código por medio de Matlab, empleando las funciones de la librería traci4matlab que nos permite la comunicación entre Matlab y el simulador SUMO. El control consiste en monitorizar el estado de la batería con el objeto de tomar las acciones apropiadas para garantizar un estado mínimo de carga en los vehículos en circulación. En este control también se incluirán diferentes procedimientos en el caso de que los vehículos no se paren de forma correcta en la estación con el fin de evitar atascos. El objetivo de estas simulaciones es obtener estadísticas de uso de la red de carga de modo que permitan desarrollar procedimientos para la toma de decisiones en relación a la mejor ubicación geográfica y capacidad de las mismas. III XÍndice 4.1.5 Control con Matlab 37 Cambio de color en función del nivel de batería 39 Prueba de la parada de un vehículo en una estación de carga 45 4.1.6 Control con Python 52 Prueba de la parada de un vehículo en una estación de carga 53 Prueba del estacionamiento de un vehículo cerca de una estación de carga 57 4.2 Simulación final 62 4.2.1 Escenario (granadasim.net) 63 4.2.2 Fichero adicional (granadasim.add) 63 4.2.3 Propiedades de los vehículos y rutas (granadasim.rou) 64 4.2.4 Fichero de configuración de SUMO (granadasim.sumocfg) 65 4.2.5 Control 65 5 Resultados 73 5.1 Ficheros de análisis 73 5.2 Primer análisis: Número máximo de vehículos en circulación 75 5.3 Segundo análisis: Estación más usada y más lenta (1) 77 5.4 Tercer análisis: Estación más usada y más lenta (2) 81 5.5 Tercer análisis: Estación más usada y más lenta (3) 86 6 Conclusiones y trabajos futuros 93 6.1 Introducción 93 6.2 Conclusiones 93 6.3 Trabajos futuros 93 Índice de Figuras 95 Índice de Tablas 97 Bibliografía 99 Glosario 101 1 Motivación del proyecto Debido al aumento del precio del carburante de estos últimos años y a las cada vez más frecuentes restricciones de acceso a los vehículos de combustión interna a ciertas zonas de circulación en las ciudades, los usuarios se han planteado cada vez más la idea de comprar un vehículo eléctrico o de cero emisiones. A este aumento desde el punto de vista económico se le une que la Comisión Europea quiere conseguir que el 90% de los vehículos que circulen por carretera en el año 2050 sean de cero emisiones con el objetivo de reducir drásticamente la contaminación derivada de los vehículos de combustión interna, para conseguir esto se espera que todos los automóviles nuevos que se destinen a la venta en Europa en 2035 sean vehículos eléctricos, híbridos o enchufables. [12] Para ayudar e incentivar la compra de vehículos eléctricos se están llevando a cabo una serie de iniciativas por parte de nuestro país. Estas consisten en destinar dinero para la reestructuración de la industria del automóvil. Dentro de estas medidas se encuentra el programa de ayudas directas a las comunidades autónomas llamado Plan Moves III [ 15 ], que sirve para incentivar la compra de vehículos eléctricos y la instalación de infraestructuras necesarias para su recarga. Recientemente se aprobó en España el Real decreto 266/2021, aprobado en Abril de 2021 [ 19 ] que pretende que en 2023 se hayan instalado 100.000 puntos de recarga de uso público con el fin de dinamizar la movilidad sostenible. Además en este decreto también se contempla la creación de un mapa oficial en el que se puedan encontrar todos los puntos de recarga existentes. Para incentivar la compra de estos vehículos no contaminantes es esencial la mejora de las infraestructuras y estudiar cuidadosa y responsablemente la distribución de estas en las ciudades, ya que uno de los principales problemas de estos vehículos junto a su poca autonomía, es que la relación entre el tiempo de carga y la distancia que puede recorrer con una sola carga es bastante superior a la que se daría para los vehículos de combustión interna. A continuación, se muestran una tabla comparativa 1.3 donde se puede ver la diferencia entre un vehículo de combustión y uno eléctrico. Los tiempos de carga y distancias recorrida suele variar por ello se ha tomado tiempos y distancias medias. Para rellenar la tabla comparativa se van a tomar las características de un modelo de vehículo eléctrico puro como es el Volvo EX30 [2]. En la tabla 1.1, se muestran los datos que se van a usar para obtener el tiempo de carga y la distancia media. 1 2Capítulo 1. Motivación del proyecto Tabla 1.1 Características de un vehículo eléctrico puro. Vehículo Volvo EX30 eléctrico puro Capacidad batería 51.0 kWh Consumo energía eléctrica (combinado) 16.7 kWh/100 km Consumo energía eléctrica (ciudad) 12.1 kWh/100 km Estación carga CC 175 kW Estación carga CA 11 kW Una vez conocido las especificaciones del vehículo eléctrico se va a calcular el tiempo de carga y la distancia media para el caso más y menos desfavorable. • Cálculo caso más desfavorable: para este cálculo se va a tomar la estación de carga más lenta de las dos que se han considerado y el mayor consumo de energía eléctrica que es el combinado. Para realizar este cálculo la eficiencia de la estación de carga se va a tomar de un 95%. tcarga =CapBateria Pestacion ∗E ficiencia =51000 11000 ∗0.95 =4.88 h=17570 segundos (1.1) distmedia =CapBateria Consumoenergia(combinado)∗100 =51000 16700 ∗100 =305 Km (1.2) • Cálculo caso menos desfavorable: para este cálculo se va a tomar la estación de carga más rápida de las dos que se han considerado y el menor consumo de energía eléctrica que es el que se da por ciudad. Para realizar este cálculo la eficiencia de la estación de carga se va a tomar de un 95%. tcarga =CapBateria Pestacion ∗E ficiencia =51000 175000 ∗0.95 =0.307 h=1104 segundos (1.3) distmedia =CapBateria Consumoenergia(ciudad)∗100 =51000 12100 ∗100 =422 Km (1.4) Al igual que se ha hecho para obtener unos valores reales del vehículo eléctrico, también se va a tomar las especificaciones reales de un vehículo de combustión interna, que es el Volvo XC60 diésel [ 4 ], a continuación se muestra una tabla con las especificaciones necesarias para realizar los cálculos. Tabla 1.2 Características de un vehículo de combustión interna. Vehículo Volvo XC60 diésel Capacidad depósito de combustible 71 l Consumo combustible 6.1 l/100 km Una vez presentadas las especificaciones de un vehículo de combustión interna, ya se pueden realizar los cálculos a comparar. 1.1 Objetivos del proyecto 3 distmedia =CapDep Consumocombustible ∗100 =71 6.1∗100 =1164 Km (1.5) El tiempo repostaje de un vehículo de combustión interna se va a tomar entorno a 5 minutos. Tabla 1.3 Comparativa entre un vehículo eléctrico y uno de combustión. Vehículo Tiempo repostaje o carga (s) Distancia media (km) Relación (s/km) Eléctrico puro -Más desfavorable 17570 305 57.6 -Menos desfavorable 1104 422 2.62 Combustión 300 1164 0.26 Sería necesario disponer a lo largo de todo el núcleo urbano y de las carreteras de puntos de recarga bien distribuidos sin que supongan un grave problema para la correcta circulación de los vehículos. Por ello será muy importante el estudio del comportamiento de los vehículos eléctricos en el tráfico urbano, ya que en estos núcleos van a existir un gran flujo de vehículos y grandes zonas con estaciones de carga, lo que podría provocar grandes problemas de movilidad en las ciudades.[12] 1.1 Objetivos del proyecto El propósito de este proyecto es analizar mediante simulación el impacto de la infraestructura de carga en el el flujo de tráfico de un área geográfica determinada. Para ello se emplearán herramientas de micro simulación de tráfico de código abierto, como SUMO [ 18 ] , que se describirá más adelante, con el fin de ver el comportamiento de los vehículos y controlarlos en función de sus niveles de batería. Para conseguir esto, primero se va a estudiar la herramienta SUMO y sus prestaciones. Este estudio sobre SUMO se realiza para ver el realismo que se puede conseguir con los escenarios de SUMO y con el modelo del vehículo eléctrico. Este trabajo se centra en la simulación de vehículos eléctricos por lo que se va a estudiar como se pueden incluir estos en los diferentes escenarios y como se van a incluir las diferentes infraestructuras necesarias como son las estaciones de carga. Además, de incluir las estaciones de cargas se van a incluir en la configuración del escenario todo lo necesario para que la simulación sea lo más realista posible, incluyendo la interacción con otros vehículos, semáforos, límites de velocidad y otros elementos del tráfico real. Tras estudiar todo lo anterior se va a realizar un control de la simulación por medio de MATLAB, que será nuestra herramienta de monitorización para controlar el tráfico del escenario. Para adaptar el simulador SUMO a MATLAB se va a utilizar la toolbox traci4matlab.Traci4matlab carece de una documentación amplia para entender su funcionamiento, pero la propia web de MATLAB que nos permite descargar esta toolbox [ 5 ] contiene un apartado de funciones donde se puede ver el código de cada función y un pequeño resumen de su funcionamiento. Si este resumen no es suficiente para entender el funcionamiento de la función que se va a utilizar, se puede buscar la función equivalente en traci y ver la documentación que nos aporta la web de SUMO [ 13 ] que suele ser más amplia y de gran ayuda. Traci4matlab permitió dar los primeros pasos de integración de SUMO con un entorno de programación versátil (MATLAB). No obstante, debido a varios errores no documentados en el código de traci4matlab, se decidió pasar a usar traci, con Python, que está 4Capítulo 1. Motivación del proyecto bastante mejor mantenida y documentada. El control que se va a realizar con Python sobre la simulación se basa en monitorizar en todo instante la batería de los vehículos del escenario y las estaciones de carga. Tras realizar un control efectivo de la red de vehículos, se van a realizar diferentes configuraciones de la simulación para obtener un campo de resultados amplio para poder analizar. 1.2 Fases del proyecto Para realizar el proyecto, se comenzó con la búsqueda de varios simuladores de tráfico con el fin de elegir el más adecuado, tras esta búsqueda se eligió el simulador SUMO ya que dispone de una amplia documentación en su web para entender su funcionamiento y con él se puede simular vehículos eléctricos y sus estaciones de carga. Se puede ver el desarrollo de esta fase en el apartado 2.3.1. En la segunda fase se instaló SUMO y las librerías necesarias y se añadió a MATLAB la toolbox traci4matlab que se utilizó para comunicar MATLAB con SUMO. Se podrá ver en el apartado 3.2. La tercera y cuarta fase consistió en familiarizarse con el entorno de SUMO y en ver la estructura de los diferentes ficheros que se utilizan en la simulación. En concreto en la tercera fase se centró en la obtención de escenarios de simulación conocidos para utilizarlos en la simulación. Esta fase se puede ver en el apartado 3.3.2. Mientras que en la cuarta fase, se estudió cómo se pueden añadir las propiedades de los vehículos eléctricos y las estaciones de carga a la simulación, hecho que se puede seguir en el apartado 3.3.3. En la quinta fase se realizan las primeras pruebas de simulación con MATLAB y se comienzan a probar las diferentes funciones que se utilizarán para las simulaciones finales. En esta fase surgieron varios problemas ya que existen algunos errores en la toolbox descargada. El apartado 4.1.5 refleja los estudios realizados en esta fase. En la sexta fase debido a los errores no documentados del software de traci4matlab empleado en la fase anterior, se decidió migrar a la versión python, mejor mantenida y documentada, decisión que se mostró acertada con posterioridad. Fase que se refleja en el apartado 4.1.6. En la séptima fase se realizó la simulación final con Python y se explicó el escenario y en que consistía dicha simulación. Esta fase se representa en el apartado 4.2. En la octava y última fase que se asemeja al apartado 5 se ejecutaron varias veces la simulación final y se obtuvieron y analizaron los resultados. 1.3 Material utilizado En el desarrollo de este Trabajo Fin de Grado se va a utilizar las siguientes herramientas o software: •Simulador Eclipse SUMO (1.14.1). Enlace instalación •Herramienta Netedit (1.14.1) proporcionada por SUMO. •MATLAB (2021b). Enlace instalación •Herramienta OSM Web Wizard proporcionada por SUMO. •Herramienta Netconvert proporcionada por SUMO. 1.3 Material utilizado 5 •Toolbox traci4matlab.Enlace instalación •PYTHON (3.10). Enlace instalación •Spyder (anaconda3). Enlace instalación •Módulo Traci proporcionada al instalar SUMO. 2 Estado del Arte Actualmente , en España en 2023 hay contabilizados alrededor de 250.000 vehículos eléctricos que se encuentran en circulación, cantidad significativamente insuficiente si se quiere alcanzar el objetivo de la agenda 2030 para España que prevé 5 millones de vehículos eléctricos, aproximadamente un 16% del parque móvil. [17] Cabe destacar que España se encuentra en los puestos de cola en la implantación de la movilidad eléctrica debido a los altos precios de estos vehículos y a la falta de una red de carga pública operativa. Debido a todo esto el salto a los vehículos 100% eléctricos se ve muy complicado de asumir ya que se sabe que España cuenta con uno de los parques automovilísticos más envejecidos de la Unión Europea con una media de 13,5 años por vehículo, por lo que esto sería una magnífica oportunidad para aprovechar los fondos de ayuda europeos y el proyecto PERTE [ 10 ] con el fin de incentivar la compra de vehículos eléctricos. Llegar a la cifra de 5 millones de vehículos enchufables al cierre de 2030 se antoja un objetivo muy ambicioso ya que las infraestructuras de carga de nuestro país no están preparadas para este flujo de vehículos eléctricos. Solo se disponen de aproximadamente 15.000 puntos de carga en todo el país, cifra baja en relación al objetivo de 100.000 puntos de carga que se marcó el Gobierno para 2023. Además cabe destacar que la distribución de estos puntos debería mejorar ya que existen grandes diferencias entre las diferentes comunidades autónomas del país. La distribución de estos puntos de carga es muy importante debido a que uno de los principales problemas de los vehículos eléctricos es la autonomía de las baterías que suele estar en torno a 200 y 350 kilómetros, condicionando la duración de los trayectos y por eso de la necesidad de una buena distribución de puntos de carga por todo el país. Para ayudar a la ubicación de los diferentes puntos de carga el Gobierno decretó la publicación del primer mapa de recarga pública del país.[16] 2.1 Vehículos eléctricos El vehículo eléctrico se define como un automóvil que es propulsado por uno o por varios motores eléctricos, estos pueden alimentarse de una fuente externa que les suministre energía eléctrica o pueden ser autónomos al tener instaladas baterías, paneles solares o generadores eléctricos que tranforman un combustible en electricidad. A partir de la década de los 90, los vehículos eléctricos han tenido un rápido desarrollo en la industria del automóvil con el principal objetivo de impulsar su utilización para poder disminuir los 7 8Capítulo 2. Estado del Arte problemas relacionados con las emisiones de gases y la dependencia de los combustibles fósiles. Además de los beneficios que se han nombrado anteriormente, usar vehículos eléctricos tienen otras ventajas para el usuario, ya que estos vehículos requieren de menos mantenimientos que los de combustión interna y son menos ruidosos lo que ayuda a reducir considerablemente la contaminación acústica que sufren las ciudades debido al tránsito de vehículos. A pesar de todas estas ventajas la movilidad eléctrica se enfrenta a grandes retos como la inversión inicial que requiere la adquisición de un vehículo eléctrico, la menor autonomía que presentan en relación a los vehículos convencionales y al tiempo requerido para recargar las baterías, a todo esto se le une que en la actualidad existe una desconocimiento por parte del consumidor sobre las ganancias que se lograrían con el uso de un vehículo eléctrico, lo que conlleva que los consumidores se lo piensen a la hora de cambiar el coche convencional por el eléctrico. A la hora de hablar de vehículos eléctricos se pueden distinguir en la industria automovilística varios tipos de coches electrificados: [1] •Vehículo eléctrico híbrido Estos utilizan la combinación de dos fuentes de energía para mover el vehículo, ya que se combina el motor de combustión interna con el motor eléctrico. Con esta tecnología se consigue reducir el consumo de combustible en un 40% gracias a la utilización de una batería y del motor eléctrico que se utilizan con el fin de mejorar el rendimiento del combustible en relación a un vehículo convencional. Existen dos tipos de vehículos híbridos: – Convencional (HEV): cuyo motor principal es de combustión y se ayuda por medio de un motor eléctrico cuya batería se auto-recarga mediante un sistema de frenado regenerativo que convierte la energía cinética en energía eléctrica. – Enchufables (PHEV): el motor eléctrico es mayor y tiene capacidad para mover por sí solo el vehículo durante una determinada distancia. La batería de este no se auto-recarga por lo que necesitará de una recarga externa. Su contribución a la sostenibilidad, al ahorro de consumo, su autonomía y el precio elevado de su competidor directo el vehículo eléctrico puro hacen de estos vehículos una buena alternativa para el consumidor [6]. Figura 2.1 Esquemas de los dos tipos HEV y PHEV [22]. 2.1 Vehículos eléctricos 9 •Coche eléctrico de pila de combustible (FCEV) Se trata de un tipo de vehículo eléctrico que no usa una batería recargable por medio de la red eléctrica para almacenar la energía necesaria para alimentar el motor, si no que usa una celda de combustible que produce energía a medida que el vehículo la necesita, esta se crea a partir del hidrógeno y del oxígeno que recibe mediante un proceso electroquímico. El hidrógeno utilizado se almacena en una serie de tanques y se canalizan hasta la celda de combustible donde se mezcla con el oxígeno del aire produciendo electricidad, al realizar este proceso se obtiene agua que se expulsa por el tubo de escape en estado gaseoso. Estos vehículos también se pueden considerar híbridos, ya que se recupera la energía de frenado y se almacena en una pequeña batería con el fin de ser utilizada para reducir la demanda máxima de la celda de combustible [16][9]. Figura 2.2 Esquema del vehículo eléctrico de pilsa de combustible (FCEV) [16]. •Vehículo eléctrico puro (EV) o vehículo eléctrico de batería (BEV) Son vehículos propulsados totalmente por un motor eléctrico alimentado por baterías que se recargan gracias a la red eléctrica. El sistema básico de un vehículo eléctrico puro está compuesto por un motor eléctrico, una batería y por un controlador que se encarga de regular la energía que se transmite al motor eléctrico proveniente de la batería. Figura 2.3 Esquema del vehículo eléctrico de batería (BEV) [22]. El mayor problema de estos vehículos se debe a su autonomía ya que está limitada por la capacidad y el peso de las baterías. 16 Capítulo 2. Estado del Arte Figura 2.7 Interfaz de VanetMobSim [8]. Veins Figura 2.8 Interfaz de Veins [21]. Veins es un software de código abierto que permite realizar simulaciones de redes vehiculares. Se basa en dos simuladores OMNeT++ y en SUMO. Las simulaciones de tráfico por carretera las realiza SUMO, mientras que las simulaciones de red la realiza OMNeT++. Veins es muy flexible, esta flexibilidad se debe a que Veins se apoya en el simulador SUMO que es el que permite que se pueda trabajar en otros entornos como Python y Matlab. Este simulador permite a nivel macroscópico importar escenarios completos de cualquier parte del mundo con OpenStreetMap, incluido todos los edificios, señales de tráfico de las vías, restricciones de velocidad y giro dependiendo de la vía y sus características. También trabaja a nivel microscópico, ya que permite adelantamientos entre los diferentes vehículo y todo los que se permite en el simulador SUMO ya que se basa en él, este se explicará a continuación. Veins es una buena opción como simulador ya que tiene grandes posibilidades de simulación y 2.3 Herramientas de simulación 17 el comportamiento de los vehículos simulados es muy realista, sin embargo Veins se descarta ya que se basa en dos simuladores OMNet++ y en SUMO por lo que aprender a usar este simulador es mucho más complejo que aprender a usar directamente SUMO que es otra de las opciones de simulación que se plantea [21]. SUMO El simulador SUMO (Simulation of Urban Mobility) es un software libre y desarrollado en C++ en 2001 por el Instituto de investigación del transporte con el objetivo de dar apoyo a la comunidad de investigadores en el área de tráfico. Para hacer de SUMO una aplicación útil se ha puesto mucho cuidado en que sea lo más rápida y portable posible. SUMO es un simulador microscópico que permite usar de forma rápida una GUI (interfaz gráfica) o bien la línea de comando. Además permite modelar escenarios con muchos detalles como vías con varios carriles, intersecciones con semáforos y vías con límites de velocidad dependiendo de sus características, también permite generar rutas de los vehículos de forma aleatoria. Permite importar y simular escenarios similares a los reales por medio de herramientas como OpenStreetMap o OSM Web Wizard, además permite que el usuario pueda crear sus propios escenarios por medio de la herramienta Netedit que está incluida en el paquete de SUMO [7]. Figura 2.9 Interfaz de SUMO. Para realizar mi trabajo de fin de grado se ha elegido utilizar el simulador de SUMO ya que permite realizar simulaciones de cualquier zona del mundo y son especialmente flexibles y precisas. Lo que hace a SUMO una buena opción es su gran velocidad de simulación y su gran interoperabilidad con otras aplicaciones en tiempo de ejecución, nos permite trabajar y controlar las simulaciones con Python gracias a la extensión de SUMO llamada Traci, esta extensión de Python nos permite trabajar con Matlab gracias a la extensión de Matlab llamada traci4matlab. 3 Simulador SUMO 3.1 Introducción Como ya se explicó anteriormente SUMO (Simulation of Urban MObility) es un simulador de tráfico, microscópico y de código abierto diseñado para generar y simular grandes redes. Permite la simulación de cualquier tipo de vehículo, de peatones e incluye al realizar su instalación un gran conjunto de herramientas que se encargan de la creación de los escenarios de simulación. Además, SUMO es capaz de proporcionar en las simulaciones parámetros específicos de cada vehículo. Los diferentes ficheros que se necesitan para realizar una simulación se encuentran en formato XML, estos se pueden modificar con herramientas externas a SUMO como Sublime Text. SUMO no es solo un simulador de tráfico ya que también tiene incluido un paquete de herramientas que son necesarias para realizar una simulación de tráfico microscópico [ 11 ]. A continuación, se muestran las principales aplicaciones de este paquete con una pequeña descripción de cada una de ellas: • Sumo: Es el simulador que se encarga de realizar la simulación una vez definidos todos los parámetros del resto de las herramientas. • OSM Web Wizard: Es una aplicación que se incluye al descargar el paquete de SUMO y que permite obtener escenarios reales de cualquier zona del mundo. • Netconvert: Es una aplicación de línea de comando que es capaz de convertir el formato de escenarios generados por otras herramientas en el formato que usa SUMO para sus simulaciones. Como se van a coger los escenarios de la aplicación OSM Web Wizard cuyo formato es .osm.xml, Netconvert se va a encargar de convertir ese formato en el formato de SUMO .net.xml. • Netedit: Esta aplicación se incluye dentro del paquete de SUMO y permite crear escenarios desde cero y modificar aquellos escenarios que se han importado de OSM Web Wizard. • Sumo-gui: Se trata de la interfaz gráfica de SUMO que permite visualizar el escenario creado y la simulación en cada tiempo de simulación. • Netgenerate: Se encargan de generar redes de carreteras de forma automática que pueden ser usadas por herramientas de SUMO. Se pueden generar 3 tipos de redes: redes con forma de tela de araña, redes con forma de rejilla y redes aleatorias. • Duarouter: Es una aplicación que permite generar rutas de vehículos definiendo las características del vehículos y la posición de origen y destino. • Od2trips: Esta aplicación permite importar matrices O-D para dividirla posteriormente en viajes individuales. 19 20 Capítulo 3. Simulador SUMO • Jtrrouter: Es otro generador de rutas de SUMO. En este caso de calculan las rutas utilizando porcentajes de giro en los cruces. • Dfrouter: Permite definir y realizar cálculos de las rutas que van a seguir el conjunto de vehículos de un flujo. Esto consiste en definir un grupo de vehículos con una misma posición de origen y destino que seguirán la misma ruta de forma similar, con igual velocidad y aceleración. • Marouter: Permite asignar rutas macroscópicas a partir de una red generada anteriormente y una matriz o/d de posiciones de origen y destino. • Polyconvert: Permite asignar rutas. Se utiliza para importar puntos de interés y polígonos de diferentes formatos y los traduce para que se pueda visualizar en la interfaz de SUMO. • Activitygen: Lee la definición de un población en una red dada y genera los posibles movimientos de esta. • EmissionsMap: Esta herramienta genera matrices con los diferentes valores de emisiones dependiendo del rango de velocidad, aceleración y pendiente, teniendo en cuenta la clase de emisión del vehículo. • EmissionsDrivingCycle: Esta herramienta permite calcular las emisiones para un solo vehículo dada su línea de tiempo de velocidades y aceleraciones (ciclo de conducción). Junto a todas estas herramientas existen más herramientas adicionales que se pueden ver en la web de SUMO [ 18 ].De las herramientas descritas anteriormente se van a utilizar para este proyecto las 6 primeras herramientas que se han descrito. En los siguientes apartados se explicará cómo se puede realizar la instalación completa de SUMO y sus paquetes y la estructura de los ficheros que necesita SUMO para realizar una simulación completa. 3.2 Instalación de SUMO La instalación completa del paquete de SUMO se puede realizar desde la web de SUMO [ 18 ] concretamente en el apartado llamado "Instalando SUMO" de esta página. Una vez en esta página se puede ver la explicación de como instalar el paquete de SUMO para diferentes sistemas operativos, como se ha utilizado para hacer el trabajo de fin de grado el sistema operativo Window se va a explicar cómo se podría realizar la instalación completa para este sistema. En la web existen 4 opciones diferentes de instalación dependiendo de la plataforma donde se quiera instalar (32 bits o 64 bits), también dependerá de si se quiere instalar de forma local o de forma portátil. Si se desea descargar de forma local porque se tienen los derechos de administrador de la máquina donde se ejecutará, se va a descargar el instalador preferiblemente el de 64 bits. Una vez que se descarga el instalador solo se tendrán que seguir los pasos que se indican en él. Una vez instalado el paquete completo de SUMO se podrán encontrar dentro de la carpeta de SUMO todas las herramientas que se indicaron anteriormente y varios ejemplos de simulaciones realizadas con SUMO. Además dentro de la carpeta de SUMO se pueden encontrar todas las funciones necesarias para comunicar Matlab con SUMO, lo que hacen verdaderamente estas funciones es comunicar traci con Matlab ya que traci es la interfaz de control que proporciona sumo y que permite al usuario acceder y recuperar valores de los objetos simulados y manipular su comportamiento en línea. 3.3 Estructura de los ficheros de SUMO 21 Para terminar con la instalación de SUMO hay que añadir en las variables de entorno de mi equipo dentro del patch las dos rutas del fichero de SUMO que se muestran en la siguiente imagen. Figura 3.1 Visualización de las rutas a añadir. Para poder trabajar correctamente con SUMO y sus herramientas se necesita tener instalado el entorno de programación de Python, este se puede descargar en cualquier web. Una vez instalado Python ya se podrá utilizar OSM Web Wizard con todas sus opciones de simulación. 3.3 Estructura de los ficheros de SUMO Para realizar una simulación completa con SUMO se necesitan al menos 4 ficheros diferentes: • Fichero .net.xml: Este se trata de un archivo de red que se encarga de definir el escenario de simulación con todas sus carreteras e intersecciones por las que circulan los vehículos. • Fichero .add.xml: Este archivo se usa para definir elementos adicionales a la red como aros inductivos, semáforos y paradas de bus o de carga de vehículos eléctricos. • Fichero .rou.xml: En este archivo se definen los tipos de vehículos y sus propiedades y las rutas que van a seguir los vehículos. • Fichero .sumocfg: Fichero de configuración de SUMO donde se definen los ficheros de entrada y los ficheros de salida. 22 Capítulo 3. Simulador SUMO Dentro del fichero de red (.net.xml) se definen los nodos (intersecciones) de la red y las carreteras o calles (edge), por medio de estos se puede hacer por completo un escenario de simulación. Además en este fichero se puede definir las características de las diferentes carreteras como la longitud, el número de carriles, la prioridad de paso y las limitaciones de velocidad para las diferentes vías. Este se crea de varias formas, las cuales se explicarán más adelante. En el fichero adicional(.add.xml) se suelen definir las diferentes zonas de parada de vehículos y permiten utilizar otras funciones de SUMO como el rerouter. Este fichero se ha usado en mis simulaciones principalmente para definir las estaciones de carga de los vehículos eléctricos y para ayudar a definir las rutas cíclicas de mis vehículos por medio de rerouter. En el fichero de rutas (.rou.xml) se definen los diferentes vehículos y sus propiedades en función del tipo de vehículo que se quiera simular. También se definen en él las rutas que va a seguir cada vehículo y el instante en el que el vehículo va a aparecer o desaparecer del escenario de simulación. Existen muchas formas de definir las rutas de un vehículo y se explicarán más adelante. Finalmente el fichero de configuración (.sumocfg) se utiliza para poder ejecutar correctamente la simulación, para ello se deben introducir los ficheros de entrada con su nombre completo. Estos ficheros son los que se han explicado anteriormente y cualquier fichero que sea necesario para la descripción del escenario o de los viajes de los vehículos. En este fichero también se puede indicar el tiempo de las simulación y si se quieren obtener datos durante la simulación sobre los vehículos se deben definir dentro del fichero de configuración los archivos de salida, que se encargará de mostrar datos durante la simulación. 3.3.1 Formas de generar rutas Antes de crear las rutas que van a seguir los automoviles hay que definir los diferentes vehículos y sus propiedades por medio de los atributos vclass yvtype. Con estos se pueden definir vehículos privados, autobuses, turismos, etc. Una vez que se han definido los diferentes tipos de vehículos se puede utilizar el mismo tipo tantas veces como se quiera sin necesidad de definir otra vez por completo el vehículo y sus propiedades. A la hora de definir las rutas a seguir por los vehículos se pueden utilizar varias opciones: • Manualmente: Las rutas se definen para cada vehículo de forma manual indicando para cada uno de ellos el tiempo en el que aparece en la simulación y la ruta a seguir, que se introduce indicando por cada uno de los nodos o edge que debe pasar el vehículo. • Automáticamente: Es la forma más rápida de generar las rutas de los vehículos ya que se hace de forma automática gracias al script de python randomtrips.py, este script permite generar rutas aleatorias y especificar varios parámetros como el instante concreto en el que generar el tráfico que se puede especificar mediante el periodo o mediante una variable aleatoria. Este programa también tiene en cuenta la longitud del carril y el número de carriles a la hora de generar el tráfico ya que se pueden controlar estos aspectos por medio de valores de probabilidad. El programa a la hora de generar las rutas utiliza 3 nodos diferentes que se toman de manera aleatoria, se trata del nodo de inicio el nodo de fin y el nodo intermedio por el que tiene que pasar el vehículo. La ruta se va a crear en función de estos 3 nodos y mediante un algoritmo se va a obtener la ruta más corta que une los 3 nodos. El script randomtrips.py genera un fichero del tipo .trips que se convierte a un fichero de ruta .rou por medio del comando duarouter, que se encargará de convertir los viajes aleatorios en 3.3 Estructura de los ficheros de SUMO 23 rutas y de descartar automáticamente aquellos viajes que no están completos porque no se haya conseguido conectar los 3 nodos generados aleatoriamente. Existe otra forma alternativa de general rutas aleatorias pero sin necesidad de configurar los parámetros del srcipt radomtrips.py, esta forma consiste en utilizar la aplicación OSM Web Wizard y crear directamente con esta el escenario de simulación junto con las rutas, para ello solo se tendrían que ajustar unos parámetros dentro de la aplicación que indicarían los vehículos que se quieren simular y el flujo de vehículo que se quiere por paso de simulación. Esta aplicación utiliza de forma automática el script randomtrips.py cuando se le da a generar escenario una vez elegida la zona del mapa que se quiere simular. En el siguiente apartado donde se explican las diferentes formas que existen de generar una red se explicará cómo se puede realizar la creación de una simulación completa por medio de esta aplicación. 3.3.2 Generación de redes Antes de comenzar a definir las rutas de los vehículos es necesario tener un escenario sobre el que definir las rutas para ello se necesita crear un fichero .net.xml donde se van a encontrar la definición de toda la red de carreteras y sus características. Existen varias formas de generar la red de carreteras: • NetEdit: Esta es una aplicación que se incluye en el paquete instalado de SUMO, que nos permite modificar y crear redes de forma manual. NetEdit consiste en una interfaz de usuario que permite crear redes sin necesidad de utilizar código ya que se hace todo de forma gráfica esto hace que el crear redes desde cero con esta aplicación sea muy intuitivo pero a la vez muy trabajoso ya que se tienen que definir todos los parámetros de la red manualmente. Debido a esto esta aplicación es útil para modificar redes que ya han sido creadas y para crear redes muy simples. A continuación se puede ver una imagen de la interfaz de esta aplicación: Figura 3.2 Interfaz de NetEdit. 24 Capítulo 3. Simulador SUMO • Automáticamente con OSM Web Wizard: Con esta aplicación se puede generar cualquier red de carreteras del mundo ya que SUMO gracias al script "netconvert" permite importar mapas de código abierto en formato OSM que se obtienen de OSM Web Wizard o de la aplicación similar Open Street Map. En la siguiente imagen se puede ver el mapa obtenido en formato .net por medio de esta aplicación. Figura 3.4 Mapa convertido de OSM Web Wizard al formato de SUMO. Para las simulaciones se utilizará OSM Web Wizard ya que permite seleccionar cualquier zona del mundo a simular y establecer varios parámetros que se encargan de definir cómo será la visualización de la simulación, el flujo de vehículos y el tipo de vehículo que se van a incluir en el escenario. Una vez que se ha elegido la zona a simular y se han establecido las diferentes opciones y el tiempo de simulación, se obtendrán cada uno de los ficheros necesarios para la simulación y el fichero .sumocfg, que si se ejecuta se podrá observar el funcionamiento de la simulación completa. Figura 3.5 Interfaz de OSM Web Wizard. 3.3 Estructura de los ficheros de SUMO 25 Automáticamente con Netgenerate: Este script de SUMO permite generar redes de carreteras con formas típicas como redes en forma de malla, tela de araña o redes con forma aleatoria. Al definir el tipo de red que se quiere generar se pueden cambiar varios parámetros que depende exclusivamente de la topología de red elegida. En la siguiente imagen se pueden ver las diferentes topologías que se pueden generar: Figura 3.8 Redes generadas con "netgenerate" con forma de malla, tela de araña y aleatoria. 3.3.3 Fichero adicional (.add) Este fichero se usa para complementar la simulación, en mi simulaciones como se indicó anteriormente se ha utilizado para definir las diferentes estaciones de carga, detectores de área y para crear "rerouter" que será esenciales para conseguir una ruta cíclica para cada vehículo. • Estaciones de carga: Se trata de una serie de superficies que se definen en un carril específico del escenario donde los vehículos con baterías pueden cargarse durante el tiempo que se mantengan en la superficie de carga. 32 Capítulo 4. Resultados de simulación Figura 4.2 Visualización del escenario en NetEdit. 4.1.3 Propiedades de los vehículos y rutas (circles.rou.xml) En este fichero se deben definir las propiedades del vehículo que se quiere simular, en este caso será un vehículo eléctrico por lo que se debe incluir en los vehículos la batería y todas las propiedades necesarias. La definición del vehículo se debe realizar entre las siguientes sentencias <vType>- </vType>. En las siguientes líneas de código se puede ver como se puede definir un vehículo eléctrico por completo: <vType id="car" vClass="passenger" length="5" accel="3.5" decel="2.2" sigma="1.0" color="0,0,1"> <param key="has.battery.device" value="true"/> <param key="maximumBatteryCapacity" value="60000"/> <param key="maximumPower" value="272000"/> <param key="vehicleMass" value="1500"/> <param key="frontSurfaceArea" value="2.5"/> <param key="airDragCoefficient" value="0.6"/> <param key="internalMomentOfInertia" value="0.01"/> <param key="radialDragCoefficient" value="0.5"/> <param key="rollDragCoefficient" value="0.01"/> <param key="constantPowerIntake" value="100"/> <param key="propulsionEfficiency" value="0.9"/> <param key="recuperationEfficiency" value="0.9"/> <param key="stoppingTreshold" value="0.1"/> </vType> Se van a explicar el significado de cada uno de los parámetros que se han incluido en la definición del vehículo. 4.1 Simulación 1: Haciendo pruebas 33 Tabla 4.2 Parámetros de la definición de un vehículo eléctrico. Key Descripción Tipo Valor por defecto has.battery.device Añadirle batería al vehículo string false maximumBatteryCapacity Capacidad máxima de la batería (Wh) float 35000 maximumPower Potencia máxima del vehículo (W) float 150000 vehicleMass Masa del vehículo (kg) float 1830 frontSurfaceArea Área frontal del vehículo Aveh(m2)float 2.6 airDragCoefficient Coeficiente radial de arrastre Crad float 0.1 rollDragCoefficient Coeficiente de resistencia a la rodadura Croll float 0.01 constantPowerIntake Promedio de potencia consumida Pconst (W)float 100 propulsionEfficiency Eficiencia de propulsión ηprop float 0.98 recuperationEfficiency Eficiencia de recuperación ηrecu float 0.96 stoppingTreshold Velocidad mínima para empezar a cargar (km/h) float 0.1 Los parámetros que se han descrito en la tabla anterior son los necesarios para configurar el vehículo como uno real y que por medio de un modelo y esas constantes se puedan obtener los gastos del vehículo. El primer parámetro de la tabla es el encargado de definir al vehículo como eléctrico ya que al añadir el dispositivo batería al vehículo este adquiere las propiedades de uno eléctrico. Cualquiera de estos parámetros se pueden definir cuando se realice la definición del viaje que va a seguir el vehículo, normalmente el parámetro que se encarga de indicar la batería actual del vehículo se suele definir fuera de la definición del tipo de vehículo, como se puede ver en la siguiente página. Tabla 4.3 Parámetros de la definición de el tipo de vehículo. Nombre Descripción Tipo Valor por defecto id Identificador del tipo de vehículo creado id (string) - vClass Clase de vehículo class (enum) "passenger" length Longitud del vehículo float 5.0 accel Aceleración máxima (m/s2)float 2.6 decel Desaceleración máxima (m/s2)float 4.5 sigma Forma de conducción (0, conducción perfecta) float 0.5 color Color del vehículo en RGB "float,float,float" "1,1,0" (amarillo) En esta tabla se muestran los parámetros que se encargan de definir el tipo de vehículo y sus características principales, existen más parámetros para definir el tipo de vehículo, se pueden ver en la web de SUMO. En este fichero además de definir el vehículo y sus propiedades, se debe definir las rutas que deben seguir cada vehículo. Existen varias formas de definir rutas, en este caso utilizamos para definir rutas repetitivas el siguiente código: <route id="routecar1" edges="edge1 E85 edge2 E79 E80 E81 E82 E83" color="yellow" repeat="10" cycleTime="140"> </route> En la siguiente tabla se describe el significado de los parámetros definidos en el anterior código: 34 Capítulo 4. Resultados de simulación Tabla 4.4 Parámetros utilizados para la definición de una ruta. Nombre Descripción Tipo id Identificador de la ruta id (string) edges Bordes por el que circulará el vehículo id list color Color de la ruta float or string accel Aceleración máxima (m/s2)float repeat Número de veces que se repetirá esta ruta (m/s2)int cycleTime Tiempo de duración del ciclo (s) int (tiempo) Esta forma de definir rutas repetitivas de vehículos no es muy útil, ya que para definir completamente la ruta se necesita indicar cada una de las vías por donde tiene que pasar el vehículo, lo que hace muy costoso el definir una ruta larga de esta forma. Se utiliza esta definición de rutas como ejemplo pero para crear rutas cíclicas se utilizará la función rerouter de SUMO. A la hora de asignarle a un vehículo su ruta correspondiente se puede hacer de dos formas. Se puede asignar la ruta a un solo vehículo, entre las siguientes sentencias vehicle <vehicle->-</vehicle>: <vehicle id="car1v" type="car1" depart="0.00" route="routecar1"> <param key="actualBatteryCapacity" value="3250"/> </vehicle> Este código se utiliza para asignarle a un solo vehículo una ruta definida anteriormente, con este código en concreto se define un vehículo llamado "car1v" del tipo creado anteriormente "car1" y que comienza en el tiempo 0 con la ruta "routercar1". Con estas líneas de código también se indica la batería actual que debe tener el vehículo al comenzar su viaje. Tabla 4.5 Parámetros utilizados para la asignación de una ruta (vehicle). Nombre Descripción Tipo id Identificador del vehículo id (string) type Identificado del tipo de vehículo que se va a usar id depart Paso de tiempo en el que el vehículo entra en la red float route Identificado de la ruta por la que circulará el vehículo id Estos parámetros son específicos de la asignación de una ruta a un vehículo. Mientras que el parámetro que se presenta en la siguiente tabla se trata de un parámetro propio de los vehículos eléctricos y que sirve para terminar con la definición de los vehículos eléctricos, indicando la energía actual de la batería cuando comienza a realizar su ruta asignada. Tabla 4.6 Parámetro para definir la batería inicial del vehículo. Key Descripción Tipo Valor por defecto actualBatteryCapacity Batería actual del vehículo (Wh) float maximumBatteryCapacity/2 Tambien se pueden utilizar las sentencias <flow->-</flow> a la hora de asignar rutas a un vehículo, esta forma de asignación de rutas se suele usar cuando se quiere que varios vehículos sigan la misma ruta. Las sentencias "flow" describen flujos de vehículos. 4.1 Simulación 1: Haciendo pruebas 35 <flow id="carflow" type="car" begin="0" end="0" number="2" from="edge 1" to="edge2" > <param key="actualBatteryCapacity" value="2500"/> </flow> Con estas líneas de código se define un flujo de 2 vehículos llamado "carflow" del tipo "car" que inicia su viaje en el instante 0 desde el borde de carretera edge1 hasta edge2. Tabla 4.7 Parámetros utilizados para la asignación de una ruta (flow). Nombre Descripción Tipo id Identificador del flujo de vehículos, cada vehículo se genera con este nombre id (string) type Identificado del tipo de vehículo que se va a usar id begin Tiempo de inicio del flujo descrito int end El tiempo de finalización del flujo descrito int number Número de vehículos que se insertarán en este flujo int from Nombre del borde donde comienza la ruta edge id to Nombre del borde donde termina la ruta edge id Cada uno de los vehículos de este flujo tendrán una batería de 2500 Wh al comenzar su viaje. Tabla 4.8 Parámetro para definir la batería inicial del vehículo. Key Descripción Tipo Valor por defecto actualBatteryCapacity Batería actual del vehículo (Wh) float maximumBatteryCapacity/2 4.1.4 Configuración de SUMO (circles.sumcfg) Como ya se explicó al presentar la estructura de una simulación en SUMO en el fichero de configuración se deben incluir los ficheros que se han creado para esta simulación. En este caso los ficheros que se van a introducir como entradas entre las sentencias <input>-</input> son los ficheros "circle.net.xml", "circle.rou.xml" y "circle2.add.xml". Además de estos ficheros se va a incluir una línea de código que permite eliminar el teletransporte de los vehículos que se produce cuando el vehículo se queda parado en medio de la carretera. •Teletransporte de los vehículo Este teletransporte se produce cuando el vehículo se para, obstaculizando el paso del resto de vehículos. En esta simulación el vehículo se va a parar cuando este se quede sin batería o cuando esté parado en la estación de carga. Cuando este se para, el programa lo detecta y automáticamente hace que el vehículo se teletransporte a otra posición ya que ha detectado que el vehículo se encontraba parado en una intersección. Cuando esto se produce la propia aplicación de SUMO te advierte de que se ha producido este teletransporte, ya que te muestra lo siguiente en la interfaz de SUMO: 36 Capítulo 4. Resultados de simulación Figura 4.3 Advertencia de teletransporte en la interfaz de SUMO . El teletransporte se efectúa cuando un contador llega al máximo impuesto por defecto en este caso será 300 segundos, el contador cuenta cada vez que el vehículo esté parado consecutivamente con una velocidad menor de 0,1 m/s. Este teletransporte lo realiza el programa ya que intenta quitar el vehículo de la ruta derivando a este a cualquier salida libre, si no existe una salida libre este seguirá en bucle teletransportandose cada 300 s (valor máximo del contador por defecto) o hasta que se acabe la simulación donde se produce la desaparición de todos los vehículos. El valor del umbral del contador se puede modificar con el comando "–time-to-teleport <INT>" , que establece el tiempo máximo en segundos del umbral, si ponemos un valor negativo se deshabilita el teletransporte debido al bloqueo de cuadrícula. Como se quiere evitar el teletransporte se introduce entre las sentencias <input>-</input> del fichero de configuración la siguiente línea de código: <time-to-teleport value="-1"/> De esta forma ya se habrá arreglado el problema del teletransporte, por lo que los vehículos se quedarán permanentemente parados en la posición donde se quedaron sin batería inicialmente o en la posición de carga. Además de incluir los ficheros para realizar la simulación se deben incluir ficheros de resultados que se van a generar una vez que haya terminado la simulación. Estos ficheros se suelen incluir entre las sentencias <output>-</output>. Con el siguiente código se obtiene información sobre la energía que hay en cada momento en cada una de las baterías de los coches. <battery-output value="Battery.out.xml"/> Para obtener información sobre los vehículos que se han parado en las diferentes estaciones de carga y ver la batería que se ha transferido al vehículo en cada momento se introduce el siguiente código: <chargingstations-output value="chargingstations.xml"/> Finalmente el último fichero que se obtiene se trata de un resumen sobre la simulación que carece de interés en el contexto actual. <summary-output value="summary_100.xml"/> Entre las sentencias <output>-</output> se han incluido dos líneas de código para terminar con la definición de los vehículos eléctricos. La que se presenta a continuación sirve para equipar a todos los vehículos con batería para que adquieran las propiedades de vehículo eléctrico. <device.battery.probability value="1"/> 4.1 Simulación 1: Haciendo pruebas 37 Y la siguiente y última línea de código del fichero de configuración se utiliza para definir la precisión con la que se escribe los valores de la batería dentro del fichero de seguimiento de la energía de consumo de la batería. <device.battery.probability value="1"/> Al completar el fichero de configuración la simulación ya estará en condiciones de ser ejecutada y lista para ser controlada por medio de programas externos como Python o Matlab. 4.1.5 Control con Matlab Una vez creada la simulación se va a realizar el control por medio de Matlab utilizando las funciones de traci4matlab que permite conectar Matlab con las funciones de traci que permiten el control de la simulación de SUMO. Antes de comenzar a explicar el programa completo de control que se ha realizado, se va a explicar los principales aspectos y directrices que hay que seguir para comenzar a programar el control de SUMO con Matlab. Para comenzar a programar en Matlab y controlar una simulación es necesario importar las constantes de traci al principio del fichero, esto se hace con la siguiente línea de código: import traci.constants % esto se incluye siempre para poder importar las constantes de traci Traci es la abreviatura "Traffic Control Interface" (interfaz de control de tráfico), que permite recuperar valores de objetos simulados y manipular su comportamiento en línea. Una vez que se han importado las constantes de traci se utiliza la función "traci.start" para iniciar sumo-gui con el archivo de configuración (.sumocfg). %se utiliza para poner en marcha sumo por medio del fichero %sumocfg que he generado previamente traci.start(’sumo-gui -c ./nombredelfichero.sumocfg --start’); Esta llamada de inicio se usa para conectar nuestro script con sumo-gui ejecutándose como servidor. Cuando se haya importado las constantes de traci y añadido el nombre del fichero de configuración el script estará listo para programarse, para programar hay que tener en cuenta que para ejecutar la simulación de SUMO hay que hacerlo por pasos de tiempo gracias a la función "traci.simulationStep". La simulación en Matlab se realiza desde un ciclo principal que se puede realizar utilizando “for” ya que se simulará por medio de un bucle hasta un tiempo determinado. Otra forma sería simular hasta que todos los vehículos hayan llegado a su destino para la cual se utilizaría la función "traci.simulation.getMinExpectedNumber". En todas mis simulaciones se utilizará un bucle for hasta un tiempo determinado que será el fin de la simulación. for i = 1: duration-1 traci.simulation.step();%se realiza un paso de simulación . . . end 38 Capítulo 4. Resultados de simulación Además de utilizar este ciclo principal que se encarga de los pasos de simulación, se va a utilizar otro ciclo anidado al principal, que se comportará como ciclo secundario y que se encargará de recorrer en cada paso de simulación todo el vector donde se encuentran los identificadores de cada vehículo. Con este nuevo bucle "for" se consigue que en cada paso de simulación del primer bucle "for" se puedan controlar los diferentes vehículos. El ciclo secundario terminará cuando se hayan recorrido todos los vehículos que se encuentran en simulación. for i = 1: duration-1 traci.simulation.step();%se realiza un paso de simulación n=length(ID); %bucle para trabajar con los diferentes vehículos for j=1:n vehID=ID{j}; . . . end end Si se hacen estos dos ciclos puede que el programa no funcione correctamente, porque en el primer paso de simulación no se encuentren los diferentes identificadores de todos los vehículos. Para solucionar esto se recomienda hacer un primer bucle al comienzo de la simulación que permita simular los primeros pasos de simulación y guardar todos los identificadores de los vehículos, de esta forma cuando se cree el ciclo secundario ya se tendrá el vector completo de los identificadores de cada vehículo y el tamaño de este vector que será el que marcará el final del ciclo secundario. A continuación, se muestra el pequeño código del bucle que se ha utilizado para solucionar el error. %hago esto para darle valor a la variable ID y poder saber el %número de coches que se van a simular for i=1:10 traci.simulation.step(); ID=traci.vehicle.getIDList(); end Como se puede observar en el código anterior se utiliza la llamada "traci.vehicle.getIDList" para obtener los identificadores de cada vehículo, los identificadores se guardan en un vector de celdas en el que cada coponente es una cadena de carácteres que se correponde con el nombre que se le ha dado a cada vehículo que se encuentra en ruta. Al final del código cuando haya acabado el bucle principal se cierra la conexión con el servidor de SUMO y se detiene por completo la simulación con el siguiente código de traci. traci.close() A continuación se van a explicar los diferentes script de control que se han realizado con Matlab. 4.1 Simulación 1: Haciendo pruebas 39 Cambio de color en función del nivel de batería Se va a realizar un script de Matlab con el fin de probar cómo se leen ciertos parámetros desde Matlab y como se pueden cambiar las diferentes propiedades de un vehículo. Para esta simulación se van a utilizar los siguientes ficheros: • Escenario (cricles.net.xml): Este fichero define el escenario de la simulación, en este caso será un escenario circular para que sea sencilla la simulación y la visualización de ella. • Fichero adicional (cricles.add.xml): En este fichero se definen los rerouter que se van a utilizar en esta simulación. • Vehículos y rutas (circles.rou.xml): Se definen para esta simulación dos vehículos con idénticas propiedades y 4 rutas. Por lo que en esta simulación al existir 4 rutas habrá 4 vehículos en movimiento. Los vehículos de la simulación: Tabla 4.9 Vehículos definidos en esta simulación . IDveh Tipo Ruta Batería inicial (W) car1v carv Circular alrededor de todo el escenario 3250 car1v2 carv Circular alrededor de todo el escenario 3250 carflow.1 car Circular alrededor de todo el escenario 2500 carflow.2 car Circular alrededor de todo el escenario 2500 El tipo de vehículo hace referencia a las propiedades que se le han dado al vehículo, estas se pueden observar en el código que se adjunta en el anexo. • Configuración (circles.sumocfg): En este fichero de configuración hay que introducir los nombres de los ficheros creados y de los que se quieren generar. Ya que tenemos preparado el entorno de simulación se va a explicar el programa que se ha realizado en Matlab. En este script se busca leer la capacidad de la batería de cada vehículo en cada instante de tiempo y en función de los valores de esta se va a cambiar el color del vehículo. De este modo el vehículo pasará por 3 fases distintas que se verán reflejadas en la simulación por el color rojo, naranja y azul, cada color representa un nivel distinto de batería, los niveles se dividen en 3 intervalos: • Nivel de batería alto: Se representa con el color rojo, un vehículo tendrá un nivel alto de carga si el vehículo tiene una energía disponible mayor que 2/3 de batería inicial. • Nivel de batería medio: Se representa con el color naranja, un vehículo tendrá un nivel medio de carga si el nivel de energía del vehículo se encuentra entre 2/3 y 1/3 de la batería inicial. • Nivel de batería bajo: Se representa con el color azul, un vehículo tendrá un nivel bajo de carga si el nivel de energía del vehículo es menor que 1/3 de la batería inicial. Si el vehículo pasa por los 3 niveles y antes de que se termine la simulación se queda sin energía este se quedará parado permanentemente. Para obtener la carga de la que dispone el vehículo en cada instante se va a utilizar la siguiente línea de código: eng_act(j,i)=str2double(traci.vehicle.getParameter(vehID,’device.battery .actualBatteryCapacity’)); 40 Capítulo 4. Resultados de simulación Con la función "traci.vehicle.getParameter" se puede obtener cualquier parámetro que se necesite de un vehículo, en este caso se utiliza la función para obtener la energía actual del vehículo. Al llamar a la función devuelve el valor de energía actual de un vehículo eléctrico en formato de cadena de caracteres por lo que para poder operar con ese dato se decide pasarlo al formato "double". Se ha creado una matriz con tamaño j*i donde j se corresponde con el número de vehículos que hay en ruta e i con el tiempo que se ha simulado, con esta se consigue guardar cada una de las energías que se han obtenido para cada vehículo e instante. Una vez que se sabe la energía que tiene cada vehículo en cada instante solo se tiene que ver entre que intervalos se encuentra dicha energía y en relación al intervalo en el que se encuentre se mostrará el vehículo con un color u otro. Para cambiar el color del vehículo se utiliza la función "traci.vehicle.setColor" que permite indicar al vehículo que se le quiere cambiar el color y el color que se le quiere poner, el color se introduce entre corchetes y hay que introducirlo respetando el formato RGBA. traci.vehicle.setColor(vehID,[0,0,255,255]); Como se comentó anteriormente cuando el vehículo se quede sin batería hay que hacer que el vehículo se quede parado permanentemente ya que al no tener batería no se podrá seguir moviendo, para ello se cambia la velocidad del vehículo a 0 con la función "traci.vehicle.setSpeed" que permite cambiar la velocidad de cualquier vehículo que se encuentre en la simulación. Resultados: En este apartado se van a mostrar diferentes imágenes y gráficas donde se vea claramente el funcionamiento correcto del script de matlab que se ha realizado. En este caso se van a mostrar imágenes donde se vea el cambio de color de los vehículos y gráficas donde se vea la energía que tenía el vehículo en el instante que cambia de color. Se van a incluir varias imágenes de la interfaz de SUMO donde se observa el color del vehículo y el instante de tiempo de la simulación: • En la primera imagen 4.4 se puede ver como al comienzo de la simulación todos lo vehículos son de color rojo porque no han gastado mucha batería. • En la segunda imagen 4.5 hay dos vehículos de color rojo porque siguen en el nivel alto de batería y dos vehículos de color naranja porque ya han pasado al nivel medio. • En la tercera imagen 4.6 se pueden ver como todos los vehículos son de color naranja, por lo que hay dos vehículos que en la imagen anterior eran de color rojo (nivel alto) que han pasado a ser de color naranja (nivel medio). • En la cuarta imagen 4.7 se pueden ver dos vehículos de color azul (nivel bajo) y otros dos de color naranja (nivel medio). • En la quinta imagen 4.8 todos los vehículos son de color azul (nivel bajo) aunque dos de ellos si se observan las gráficas 4.11 se puede ver como su energía es 0, por lo que permanecerán parados en esa misma posición al quedarse sin batería. • En la sexta imagen 4.9 los vehículos siguen con el color azul pero esta vez todos están parados porque se puede ver como su energía es 0 al observar las gráficas 4.11. • La última imagen 4.10 se ha añadido para comprobar que los vehículos siguen en la misma posición que en la imagen anterior ya que se han quedado sin batería. También se puede ver que el valor del tiempo de simulación es de3000 segundos por lo que la simulación ha finalizado. 4.1 Simulación 1: Haciendo pruebas 41 Figura 4.4 Visualización de la simulación en SUMO: 1º-Vehículos rojo. Figura 4.5 Visualización de la simulación en SUMO: 2º-Vehículos rojo y naranja. 48 Capítulo 4. Resultados de simulación Figura 4.12 Visualización de la simulación en SUMO: Vehículo en movimiento. En la figura 4.12 se puede ver como el vehículo sigue moviéndose por el escenario, ya que la imagen se ha hecho cuando el paso de simulación es menor que 452 por lo que todavía no se ha activado la variable de parada. Figura 4.13 Visualización de la simulación en SUMO: Vehículo sigue moviendose. 4.1 Simulación 1: Haciendo pruebas 49 En la imagen 4.13 ya se ha puesto la variable parada a 1 ya que el paso de simulación es 452, pero el vehículo no se ha parado porque no se encuentra en la vía donde se ha situado la estación de carga. Para que le vehículo realice la parada para cargarse debe pasar nuevamente por la vía que da acceso a la estación de carga. Figura 4.14 Visualización de la simulación en SUMO: Vehículo cargando en la estación de carga. En la imagen 4.14 el vehículo se puede ver como se encuentra parado en la estación de carga, esto sucede porque el vehículo ha vuelto a pasar por la estación de carga mientras estaba activada la variable parada. Cuando se para el vehículo este debe cargarse durante 400 segundos que es el tiempo que se ha indicado en la función "traci.vehicle.setStop", como se puede ver en el código 4.1.5. Figura 4.15 Visualización de la simulación en SUMO: Se ve la ruta del vehículo y la cuenta de la duración de la parada.. Al mirar en la interfaz de SUMO se ve como el vehículo tiene descrita una ruta, en la que se indica un valor de 373 que será el tiempo que le queda al vehículo para que salga de la estación de carga. Esta cuenta comienza a decrementar en uno por cada segundo y cuando llega a 0 el vehículo debería retomar la circulación, porque ya habrá terminado el tiempo de parada que se indicó. Pero existe un error que hace que el vehículo siga parado una vez que ha terminado la cuenta de parada. Como se puede observar en la siguiente imagen el vehículo sigue parado y la cuenta sigue decrementando su valor y toma valores negativos. 50 Capítulo 4. Resultados de simulación Figura 4.16 Visualización de la simulación en SUMO: Se ve la ruta del vehículo y la cuenta de la duración de la parada con valor negativo. Figura 4.17 Visualización de la simulación en SUMO: 1ºVehículo en movimiento. En esta última imagen 4.18 se puede ver como el vehículo sigue parado en la estación de carga aunque el tiempo de parada de 400 segundo haya pasado. Se ha investigado dicho error y no se ha encontrado solución ya que el error debe ser interno y propio de la comunicación entre Matlab y Python por lo que se ha decidido probar esta misma simulación en el entorno de Python que es el lenguaje que han utilizado los programadores de SUMO para desarrollar la interfaz de control de SUMO. También se puede ver gráficamente el comportamiento del vehículo, para ello se han creado dos gráficas con Matlab en la que se pueden observar la velocidad del vehículo en todo momento y la energía que tiene el vehículo. 4.1 Simulación 1: Haciendo pruebas 51 Figura 4.18 Gráfica donde se observa la velocidad y la energía del vehículo en cada instante. En la gráfica se puede observar como la velocidad del vehículo oscila entre dos valores generándose una señal muy ruidosa, esto se debe a que los vehículos no se mueven a velocidad constante ya que su velocidad depende de los obstáculos que haya en la vía, de las intersecciones y de la propia vía. Por ello los vehículos van a circular a diferentes velocidades ya que al realizar una curva o al encontrar un obstáculo bajan considerablemente su velocidad. Si se observa el zoom que se ha realizado a la señal ruidosa de la gráfica se puede ver ese cambio de velocidad que experimenta el vehículo, la pendiente que se ve en la gráfica se asemejaría a la aceleración que sufre el vehículo para cambiar de una velocidad a otra. En estas gráficas 4.18 se puede ver como el vehículo pasa a tener una velocidad de 0 m/s, esto se debe que le vehículo ha llegado a la estación de carga y se ha parado. Cuando este se para se puede observar un aumento de forma lineal en la gráfica donde se representa la energía actual del vehículo, esto se debe a que le vehículo a comenzado a cargarse. También se puede observar en esta misma gráfica como a partir del tiempo de simulación 1600 la gráfica se empieza a mantener constante, se debe a que la batería del vehículo se ha cargado por completo y ya no acepta más carga. Además en estas gráficas se puede observar con más claridad el error que se indicó anteriormente, ya que el vehículo supera los 400 segundos de parada y no vuelve a moverse. Para mostrar el funcionamiento correcto de este ejemplo se ha decidido comenzar a programar este mismo ejemplo en Python. 52 Capítulo 4. Resultados de simulación 4.1.6 Control con Python Se va a realizar el control de la simulación anterior por medio de Python utilizando las funciones de traci que es una interfaz de control de tráfico creada por SUMO, el módulo traci se obtiene automáticamente al instalar SUMO. Para programar con Python se ha utilizado el entorno de programación Spyder 1.3 junto con la versión 3.9 de Python. Antes de comenzar a explicar el programa completo de control que se ha realizado, se van a explicar al igual que se hizo con Matlab las directrices que hay que seguir para empezar a programar el control de SUMO con Python. Antes de comenzar a controlar una simulación de SUMO con Pyhton, se deben importar una serie de librerías: import os import sys import traci import sumolib Estas librerías son necesarias para realizar la conexión con el servidor de SUMO y poder lanzar las simulaciones con la interfaz de SUMO. Para poder iniciar la simulación con el fichero de configuración (.sumocfg) deseado, se utiliza al igual que en Matlab la función traci.start. traci.start([sumolib.checkBinary(’sumo-gui’), "-c", "nombredelfichero. sumocfg"] + sys.argv[1:]) Una vez ejecutada esta sentencia ya se puede comenzar a realizar el control de la simulación, al haber realizado la conexión del script de python con sumo-gui (interfaz de SUMO). A la hora de controlar la simulación como se hizo con Matlab, hay que tener en cuenta que la ejecución de SUMO se hace por medio de pasos de tiempo que se realizan gracias a la sentencia " traci.simulationStep()". Por ello la simulación se va a iniciar con un bucle principal donde se ejecuta en cada ciclo del bucle la sentencia de paso de simulación. A este bucle se le anida un bucle secundario, encargado de recorrer el vector formado por identificadores de los diferentes vehículos que hay en simulación. for i in range(N-1): #N:duración de la simulación traci.simulationStep() #se realiza un paso de simulación for j in range(n): #n:número de vehículos en la simulación vehID = vehicleIDs[j] . . . A estos dos bucles hay que añadirle un bucle inicial encargado de inicializar todas la variables, ya que para ejecutar el bucle secundario es necesario conocer todos los vehículos que hay en la simulación. Por ello se ejecuta un bucle hasta un tiempo de simulación suficiente en el que ya se pueden conocer todos los vehículos que se van a introducir en la simulación, esto es necesario porque hasta que el vehículo no entre en circulación no se puede conocer su identificador. for i in range(x): #se ejecutan x pasos de simulación traci.simulationStep() 4.1 Simulación 1: Haciendo pruebas 53 #tras ejecutar esos pasos de simulación ya se conocen el conjuto de vehí culos totales #que habrá en circulación dentro de la simulación vehicleIDs = traci.vehicle.getIDList() #se leen los vehículos Al final del código para poder cerrar la conexión con el servidor de SUMO se debe introducir la siguiente sentencia: traci.close() Prueba de la parada de un vehículo en una estación de carga Se va a realizar un script de Python para probar que se puede realizar la parada de un vehículo dentro de una estación de carga. Esta simulación se va a realizar como consecuencia del error que se daba al realizar una para de un vehículo en una estación por medio de Matlab. Por lo que todos los fichero que se van a usar para realizar la simulación son idénticos a los descritos al realizar la simulación con Matlab. A continuación, se van a mostrar los ficheros que se han utilizado en la simulación: • Escenario (cricles.net.xml): El escenario de simulación se corresponde con el escenario octogonal utilizado anteriormente. • Fichero adicional (cricles2.add.xml): Este fichero permite añadir una estación de carga y crear los rerouter como se hizo para controlar la parada de un vehículo con Matlab. • Vehículos y rutas (circles2.rou.xml): Se utiliza un fichero con una sola ruta de vehículo como se hizo anteriormente, esto se hace para facilitar el control y probar si funciona correctamente la parada del vehículo en la estación de carga. • Configuración (circles2.sumocfg): El fichero de configuración también será idéntico al utilizado en el sigiente apartado 4.1.5. Como ya se ha explicado anteriormente el objetivo principal de esta simulación es solucionar el error al usar la función de parada de vehículos con Matlab. Por ello se va a crear un código muy similar al creado en el apartado 4.1.5, en el que se va a utilizar la función “traci.vehicle.setStop” encargada de realizar la parada del vehículo dentro de la estación de carga. El script de python tiene la estructura descrita en la sección 4.1.6 pero con una diferencia, al no utilizar el bucle secundario ya que solo se va a trabajar con un vehículo. 54 Capítulo 4. Resultados de simulación La idea principal del código es la misma que se explicó en el control con Matlab, por lo que se va hacer un pequeño resumen del funcionamiento. En un instante de simulación determinado por la variable “i” se activa “charge” que se encarga de indicar que el vehículo debe pararse en la estación. if 451<i<500: charge=True Por lo que una vez activa la variable cuando el vehículo vuelva a pasar por la estación se parará. Para realizar la parada se llama a la función “traci.vehicle.setStop” indicando el tiempo que va a durar la parada. if 20 >= vehPosLead[0] < 65 and 200 < vehPosLead[1] < 300: if charge: traci.vehicle.setStop(vehicleIDs[0],’station1’,20,0,400,32,60,0) charge = False Tras llamar a la función parada se desactiva “charge” para evitar que el vehículo se vuelva a parar, con esto se consigue ver si la parada se realiza correctamente respetando el tiempo de parada que se ha asignado. Resultados: Se van a mostrar una serie de imágenes y gráficas donde se vea que el funcionamiento de la simulación es correcto. A continuación se muestran imágenes de momentos importantes de la simulación: Figura 4.19 Visualización de la simulación en SUMO: Vehículo en movimiento. En la imagen 4.19 se puede ver como el vehículo ha pasado por la estación y no se ha parado, esto se debe a que todavía no se ha llegado al tiempo de simulación 451 donde se activa la variable “charge”. 4.1 Simulación 1: Haciendo pruebas 55 Figura 4.20 Visualización de la simulación en SUMO: Vehículo sigue en movimiento. En la figura 4.20 se muestra como el tiempo de simulación es mayor que 451, por lo que ya se puede asegurar que el vehículo se va parar en la estación cuando vuelva a pasar por ella. Figura 4.21 Visualización de la simulación en SUMO: Vehículo parado en la estación de carga. En la figura 4.21 se puede observar como el vehículo se ha parado en la estación de cargar. La parada en la estación de carga se va a realizar durante 400 segundos al ser el tiempo que se le ha indicado al llamar a la función “traci.vehicle.setStop”. 56 Capítulo 4. Resultados de simulación Figura 4.22 Visualización de la simulación en SUMO: Vehículo saliendo de la estación de carga. En imagen 4.22 el vehículo está saliendo de la estación de carga ya que la simulación se encuentra en el tiempo de simulación 955 por lo que los 400 segundos de carga ya se han agotado. Figura 4.23 Gráfica donde se observa la velocidad y la energía del vehículo en cada instante. 4.1 Simulación 1: Haciendo pruebas 57 Para ver que realmente funciona la simulación se han generado 2 gráficas 4.23, estas muestran la energía del vehículo en cada instante y la velocidad de este. Al pararse el vehículo en la estación de carga se puede ver como crece la gráfica de la energía de la batería, mientras que la gráfica que representa la velocidad va a pasar a valer 0 ya que el vehículo se encuentra parado mientras se realiza la carga. Con esta simulación se ha podido comprobar que utilizando python los errores de la función “traci.vehicle.setStop” dejan de aparecer y ya se puede utilizar correctamente esta sentencia, que es de gran importancia al permitir controlar las paradas de los vehículos dentro de las estaciones de carga. Por ello a partir de ahora todas las simulaciones se van a hacer con Python. Prueba del estacionamiento de un vehículo cerca de una estación de carga Se va a realizar un script de Python para probar como se puede actuar cuando la estación de carga esté llena y lleguen más vehículos con necesidad de entrar. Para solucionar este problema se ha planteado colocar unas pequeñas zonas virtuales de estacionamientos de vehículos en la cercanía de las estaciones, con el fin de que el vehículo que se encuentre en espera no entorpezca la circulación del resto de vehículos. Para mostrar el funcionamiento de la idea inicial se va a crear una simulación donde se muestran 2 vehículos en circulación por el escenario octogonal. Al quedarse ambos vehículos sin batería, uno de ellos puede entrar en la estación de carga mientras que el segundo se va a quedar estacionado antes de llegar a la estación esperando a que la estación de carga se quede libre. Antes de comenzar con la explicación del control realizado con python se van a crear los fichero necesarios para crear el entorno de simulación. A continuación, se van a mostrar los ficheros que se han utilizado en la simulación: • Escenario (cricles.net.xml): El escenario de simulación se corresponde con el escenario octogonal utilizado en ejemplos anteriores. • Fichero adicional (cricles2.add.xml): Este fichero permite añadir una estación de carga y crear los rerouter, como se va a hacer la prueba para una sola estación el fichero utilizado será el mismo que se ha usado en la simulación 4.1.6. • Vehículos y rutas (circlesveh2.rou.xml): En este ejemplo se van a usar un flujo de vehículo con 2 vehículos, por lo que el fichero va a presentar ligeras diferencias en relación a los utilizados anteriormente. La idea de utilizar dos vehículos se debe a que se quiere mostrar el comportamiento de los vehículos cuando la estación de carga esté llena, en este caso se va a suponer que la estación solo tiene capacidad para un vehículo. • Configuración (circlesveh2.sumocfg): El fichero de configuración tendrá la estructura de siempre incluyendo los fichero de configuración de las rutas y de la red, en este caso se tiene que incluir el nuevo nombre del fichero .rou que se ha creado. Como ya se ha comentado, el objetivo principal de esta simulación es crear una zona de estacionamiento cercano a la estación de carga, donde los vehículo se puedan parar a la espera de que la estación de carga se quede libre. Para realizar esta parada previa a la parada de carga se va a utilizar la función “traci.vehicle.serStop” explicada en el apartado 4.1.5. Al usar esta sentencia hay que indicar para qué se realiza la parada, cómo se usa para estacionar hay que cambiar el valor de la variable “flags” por 1 que es el valor que indica que la parada es un estacionamiento, además se tiene que poner en la variable “edgeID” el identificador del borde de la carretera donde se quiere estacionar el vehículo. A continuación, se muestra cómo se realiza la llamada a dicha sentencia para los dos tipos de paradas utilizados: 64 Capítulo 4. Resultados de simulación Estos detectores se van a añadir para detectar los vehículos que se encuentran en las diferentes áreas de detección con el fin de identificar vehículos que se han parado de forma errónea en las diferentes estaciones de carga. El como definir una estación de carga y un redireccionamiento ya se ha explicado en el apartado 4.1.2, por ello solo se va a explicar como se define un detector de área. <laneAreaDetector id="station1" lane="22776976#0_0" pos="100" endPos ="160" file="detectores.xml" freq="1"/> Tabla 4.12 Parámetros para la definición de un detector de área. Nombre Descripción Tipo Valor por defecto id Identificador detector de área sting - lane Carril donde ucbicar la estación string Id carril valido pos Posición inicial de la estación en el carril especificado float 0 endPos Posición final de la estación en el carril especificado float - file Fichero de salida para guardar resultados sting - freq Frecuencia de muestreo(segundos) int 1 Una vez definidos los detectores de áreas se pueden visualizar en la interfaz quedando de la siguiente forma: Figura 4.31 Visualización del detector de área. En esta imagen se pueden observar dos rectángulos de color azul que se corresponden con los dos detectores de áreas que se han añadido por estación de carga. La estación de carga se encuentra tapada por el detector de área de menor longitud. 4.2.3 Propiedades de los vehículos y rutas (granadasim.rou) En este fichero se van a definir las propiedades de los vehículos que van a aparecer en la simulación. Dicha definición del vehículo se debe hacer de la misma forma que se ha explicado anteriormente. Además de definir los vehículos se definen las 4 rutas diferentes por las que van a circular los vehículos. 4.2 Simulación final 65 No se va a incluir ningún código sobre la definición de las rutas y vehículos que se ha realizado en este fichero ya que se haría de la misma forma que se ha hecho en simulaciones anteriores 4.1.3. A continuación se va a mostrar una imagen, donde se puede observar sobre el escenario de la simulación los diferentes recorridos que van a realizar los vehículos en función de a que ruta pertenezcan y la posición de las 8 estaciones de carga. Figura 4.32 Visualización de las rutas y estaciones sobre el escenario. 4.2.4 Fichero de configuración de SUMO (granadasim.sumocfg) En este fichero de configuración se deben introducir los ficheros necesarios “granadasim.net.xml”, “granadasim.rou.xml” y “granadasim.add.xml”. La explicación y la introducción de otros parámetros necesarios referente a este tipo de fichero se encuentran en el punto 4.1.4. 4.2.5 Control La idea principal de esta simulación es estudiar el comportamiento de los vehículos eléctricos y ver la eficiencia de las diferentes estaciones de carga. Por ello, se debe realizar un control que permita monitorizar los diferentes vehículos de la simulación y en función de su estado actuar sobre ellos. •Control de las rutas y de la estación de parada. La simulación va a constar de 4 rutas de vehículos y 8 estaciones de cargas a las cuales pueden acceder los vehículos en función de la ruta a la que pertenezca. En la figura 4.32 se puede ver a que estaciones de carga pueden acceder cada vehículo en función de su ruta : –Vehículos de la ruta de color azul −→ estación 1 y estación 8. –Vehículos de la ruta roja −→ estación 2, estación 6 y estación 7. –Vehículos de la ruta verde −→ estación 3 y estación 7. 66 Capítulo 4. Resultados de simulación –Vehículos de la ruta morada −→ estación 4, estación 5 y estación 8. Además de distinguir las estaciones de carga a las que puede acceder cada vehículo, también se va a tener en cuenta en la simulación que estación de carga es la más cercana al vehículo cuando este se esté quedando sin batería. Para ello se lee en cada instante la posición en la que está el vehículo y cuando la posición de este coincide con una estación, se le indica al vehículo cual es la próxima estación a esa, esto se hace hasta que se active la variable "charge=1" que indica que el vehículo se está quedando sin batería y debe dirigirse a la estación marcada como la más próxima. También se va teniendo en cuenta el número de vehículos que hay en cada estación y si el número es igual a la capacidad máxima de la estación, esta estación estará cerrada hasta que salga un vehículo de ella. Antes de ver la estación más próxima se debe ver a que ruta pertenece el vehículo para saber la secuencia de estaciones de carga en las que puede parar, esto se hace detectando el identificador del vehículo y en función de este se conoce a que ruta pertenece. Se va a mostrar un ejemplo del código que consigue realizar lo explicado, el código representado es el que se utiliza para los vehículos de la ruta azul, para el resto de rutas la idea es la misma. if vehicleIDs[j].count(’carflow3’)==1: #ruta azul if 1229 <= vehPos[j,0] < 1279 and 4043 < vehPos[j,1] < 4078 and charge[j,i]==0: #si ya ha pasado de la estación 1 la siguiente será la estació n 8 num_station[j] = 8 if veh_st[8] == limvehst: num_station[j] = 1 if 1265 <= vehPos[j,0] < 1298 and 3503 < vehPos[j,1] < 3557 and charge[j,i]==0: num_station[j] = 1 if veh_st[1] == limvehst: num_station[j] = 8 •Control de la energía de cada vehículo. El código encargado de indicar que un vehículo se está quedando sin batería es idéntico al explicado anteriormente en el apartado 4.1.6. Se ha utilizado este código para poder ver durante la simulación cuando un vehículo debe ir a la estación de carga gracias al cambio de color que sufre el vehículo. •Definir la energía inicial de cada vehículo al comienzo. Para poder hacer varias simulaciones y que estas sean diferentes se va a crear un código que permita definir la energía inicial del vehículo, esta energía se va a definir para cada uno de forma aleatoria para que se comporten de forma diferente, la energía inicial del vehículo se introduce en el primer paso de simulación. if i==0: for j in range(n): 4.2 Simulación final 67 vehIDale = vehicleIDs[j] #asigar valores aleatorios como energía inicial energia_ini=random.uniform(1400,5000) energia_iniT[j]=energia_ini traci.vehicle.setParameter(vehIDale, ’device.battery. actualBatteryCapacity’,str(energia_ini)) eng_act[j,i]=float(traci.vehicle.getParameter(vehIDale,’device .battery.actualBatteryCapacity’)) Al igual que se pretende hacer simulaciones diferentes también se quiere poder repetir una misma simulación, por ello se deben guardar los datos iniciales de la simulación como el número de vehículos y la energía inicial de cada uno de ellos, estos datos se recogen en un excel al terminar la ejecución del código. Este excel también recoge los resultados de la simulación como los vehículos que se han parado, en que estación se han parado y el tiempo de carga total de cada estación, estos valores van a servir para ver la eficiencia de cada estación y poder sacar conclusiones. Para poder repetir simulaciones se va a crear un código que permita leer en el primer instante las carga iniciales de cada vehículo almacenadas en un excel. La idea de poder repetir simulaciones es para solucionar posibles errores en el código. if i==0: for j in range(n): vehIDale = vehicleIDs[j] # cargar la energía inicial de los vehículos de un excel ruta_archivo = ’C:/Users/Juan Carlos/Desktop/Juan_Carlos/4o ¯/TFG/ sumo-1_13_0/tools/contributed/traci4matlab/examples/ granadasimmasCar/simulaciones/nombrefichero.xlsx’ datos = pd.read_excel(ruta_archivo, sheet_name=’Valores simulación’) energia_iniT1=datos.iloc[:,0] traci.vehicle.setParameter(vehIDale, ’device.battery. actualBatteryCapacity’,str(datos.iloc[j,0])) eng_act[j,i]=float(traci.vehicle.getParameter(vehIDale,’device. battery.actualBatteryCapacity’)) •Control de la parada en un estación de carga. Para controlar la carga de los vehículos se va a realizar un código encargado de indicar el tiempo de carga necesario para cada vehículo y el número de espacios libres en la estación. Este código está particularizado para cada estación ya que este control se realiza de forma independiente para cada estación de carga, por ello a continuación solo se va a mostrar el código utilizado para el control de la estación de carga 1. Para el resto de estaciones de carga el código va a tener la misma estructura y el principio de funcionamiento es el mismo. if veh_st[1] <= limvehst-1: if 1220 <= vehPos[j,0] < 1282 and 4040 < vehPos[j,1] < 4075 and parado[j]==0 and num_station[j]==1: vehpar1 = j if charge[vehpar1,i]==1 and num_station[vehpar1]==1: 68 Capítulo 4. Resultados de simulación carril_actual = traci.vehicle.getLaneID(vehicleIDs[vehpar1]) if carril_actual ==’22776976#0_0’ or carril_actual ==’22776976#0_1’: print("Coche",vehpar1,"parado estación 1") #se calcula el tiempo que se tarda en cargar completamente la batería veh_st[1]=veh_st[1]+1 eng_actB = eng_act[vehpar1,i] dur_s[vehpar1]=round(((eng_max [vehpar1]-eng_actB)/(pot_estac[0]*0.95))*3600) traci. vehicle.setStop(vehicleIDs[vehpar1],’station1’,20,0,dur_ s[vehpar1],32,80,0) #ya[vehpar1]==1 acumnum_station[vehpar1,int(cuentasta[vehpar1])]=1 acumnum_timestation[vehpar1,int(cuentasta[vehpar1])]=i acumnum_durstation[vehpar1,int(cuentasta[vehpar1])]=dur_s[ vehpar1] cuentasta[vehpar1]=cuentasta[vehpar1]+1#no ¯estaciones en las que se ha parado colaesta1[t1] = vehpar1#cola de vehículos según el orden de entrada dentro de la estación t1=t1+1 if t1==limvehst: t1=0 timeStaVeh[vehpar1]=i+dur_s[vehpar1] charge[vehpar1,i] = False parado[vehpar1] = True print(i,":El vehículo",j,"con",eng_act[j,i],"Wh de batería .","Se va a cargar en la estación 1 durante",dur_s[ vehpar1],"segundos") En este código se puede ver como para realizar una parada en la estación de carga el vehículo debe estar cerca de la estación de carga, por ello se utiliza un condicional que se activa si la posición del vehículo coincide con la posición de la estación de carga. El funcionamiento de la orden de parada de los vehículos ya se ha explicado con mayor claridad en el apartado 4.1.5. Con este código se obtiene una cuenta de los vehículos que se cargan en dicha estación y el tiempo de la carga, datos útiles a la hora de analizar resultados. Junto a este se encuentra el código encargado de controlar la parada de espera de los vehículos antes de pararse en la estación de carga. •Control de la parada de espera o estacionamiento. En este punto se va a presentar la estructura principal del código encargado de controlar el estacionamiento de aquellos vehículos que no pueden acceder a la estación de carga al estar completa su capacidad. else: #estacionar el vehículo, espera if 1050 <= vehPos[j,0] < 1150 and 3990 < vehPos[j,1] < 4040 and parado[j]==0 and estacionado[j]==0 and num_station[j]==1: vehpar1est = j if charge[vehpar1est,i] and num_station[vehpar1est]==1: 4.2 Simulación final 69 print("Coche",vehpar1est,"va a estacionar") #se ha introducido lo siguiente para solucionar los siguientes tipos de errores: #TraCIException: stop for vehicle ’carflow1.19’ on lane ’179023414#0_0’ is not downstream the current route. carril_actual = traci.vehicle.getLaneID(vehicleIDs[vehpar1est ]) if carril_actual ==’22776976#0_1’: traci.vehicle.changeLane(vehicleIDs[vehpar1est], 0,5) if carril_actual ==’22776976#0_0’: estacionado[vehpar1est] = True #float(timeStaVeh[round( colaesta1[p1])])-i(le quito el tiempo de simulación actual)+10(tiempode margen) consigo saber cuando se quedará libre un hueco en la estación dur_sesta[vehpar1est] = float(timeStaVeh[round(colaesta1[p 1])])-i+10 traci.vehicle.setStop(vehicleIDs[vehpar1est ],’22776976#0’,30+p1*6,0,dur_sesta[vehpar1est],1,20,0) acumnum_parado[vehpar1est,int(cuentapara[vehpar1est])]=1 acumnum_timeparado[vehpar1est,int(cuentapara[vehpar1est])]=i acumnum_durparado[vehpar1est,int(cuentapara[vehpar1est])]= dur_sesta[vehpar1est] cuentapara[vehpar1est]=cuentapara[vehpar1est]+1#no ¯ estaciones en las que se ha parado ha esperar p1=p1+1 if p1==len(colaesta1): p1=0 timeStaVehesta[vehpar1est]=i+dur_sesta[vehpar1est] La función encargada de mandarle la orden de estacionamiento al vehículo es la misma que se utiliza para parar el vehículo en la estación de carga, para ejecutar dicha función el vehículo debe estar cerca de la zona habilitada para realizar el estacionamiento. El funcionamiento de la orden de estacionamiento se ha explicado en el punto 4.1.5. Al igual que el código de parada en la estación de carga, este código también recoge datos útiles a la hora de analizar los resultados como el número de vehículos que se han parado a esperar y el tiempo que estos están parados. Durante la programación se han encontrado varios avisos de errores que nos mostraba la interfaz de SUMO, estos errores provocaban que la simulación se parase por completo. Tras varias pruebas se han conseguido solucionar los errores, a continuación se muestran las diferentes soluciones que se le ha dado a cada uno de ellos. • Errores advertidos por la interfaz de SUMO: Durante la programación se han dado dos avisos de error distinto, se va a explicar como se ha conseguido solucionar el error y a que se deben. – Downstream. Este error ya se ha explicado en simulaciones anteriores 4.1.5 pero en este caso el error se debe a algo diferente, este aviso se daba en algunas ocasiones cuando se ordenaba la función de estacionamiento del vehículo (traci.vehicle.setStop). 70 Capítulo 4. Resultados de simulación El error se daba cuando el vehículo que se quería estacionar pasaba por la zona de estacionamiento pero por el carril contrario, lo que provocaba que saltase el aviso ya que el carril de parada era el derecho y el vehículo pasaba por el izquierdo. Para solucionarlo se introdujo dentro del código encargado del estacionamiento del vehículo las siguientes líneas: #se ha introducido lo siguiente el siguiente error: #TraCIException: stop for vehicle ’carflow1.19’ on lane ’179023414#0_0’ is not downstream the current route. carril_actual = traci.vehicle.getLaneID(vehicleIDs[vehpar1est]) if carril_actual ==’22776976#0_1’: traci.vehicle.changeLane(vehicleIDs[vehpar1est], 0,5) Con este código se lee el carril por el que circula el vehículo (traci.vehicle.getLaneID) antes de ordenar el estacionamiento y si el carril por el que circula es el contrario de donde se sitúa la estación de carga, se le ordena al vehículo que se cambie de carril (traci.vehicle.changeLane). Normalmente las estaciones de carga se sitúan en el lado derecho en el sentido de la marcha, el identificador de este carril siempre va a terminar en 0, por ello se comprueba si el vehículo está circulando por el carril cuyo identificador termina en 1 y si es así se cambia de carril al vehículo para que pase a circular por el carril cuyo identificador termina en 0. – Too close to brake. Este error se daba cuando el vehículo iba demasiado rápido para realizar la parada en la estación de carga, se pensó para solucionarlo en cambiar la velocidad del vehículo en la cercanía de las estaciones. Esto no se puede hacer ya que al cambiar la velocidad del vehículo en un instante, este pasará a tener velocidad constante en toda la simulación y el modelo de velocidad de estos no puede ser constante ya que depende del tráfico y de la carretera por la que esté circulando. Tras varias pruebas se pensó en cambiar la velocidad máxima permitida en las carreteras donde ocurría dicho error, de esta forma no se cambiaba directamente la velocidad del vehículo y se consigue disminuir la velocidad de este en la cercanía de las estaciones de carga. Para cambiar la velocidad máxima del carril se han introducido las siguientes instrucciones al inicio del programa. # #estación5 traci.lane.setMaxSpeed(’826110528#0_0’, 13.89) traci.lane.setMaxSpeed(’826110528#0_1’, 13.89) Con esto se consigue cambiar la velocidad máxima (traci.lane.setMaxSpeed) de los dos carriles que hay antes de llegar a la estación de carga número 5, solo se cambia porque el error se daba con algunos vehículos que intentaban pararse en la estación 5. La velocidad máxima que se le ha dado es de 13.89 m/s. Tras explicar los errores que se han encontrado al ejecutar el código con diferentes datos iniciales, también se han encontrado problemas de tráfico en los que la vía se quedaba obstruida al haber un vehículo parado en la estación de carga y otro parado de forma paralela. •Saturación de la red debido al tráfico. La obstrucción se debe a que dos vehículos llegan a la vez para cargarse, uno de ellos consigue entrar en la estación y comienza a cargarse mientras que el otro se queda parado de manera 4.2 Simulación final 71 incorrecta al lado del vehículo que se ha parado correctamente. En la siguiente imagen se puede ver lo que se ha comentado: Figura 4.33 Visualización de la obstrucción de la vía. Para solucionarlo se han utilizado detectores de áreas, que permiten identificar que vehículos han pasado por el área definida y con ello ver si se ha producido una obstrucción. Para ello se usa la función (traci.lanearea.getLastStepVehicleIDs) cuyo argumento de entrada es el identificador del detector de área. La idea es identificar la obstrucción y hacer que el vehículo mal aparcado se vuelva a poner en movimiento, pero al enviarle la orden este la ignora. Al ver lo que ocurre se decide poner en movimiento el vehículo que está bien aparcado para que el vehículo mal aparcado pueda acceder a la estación de carga y de esta forma se consigue eliminar la obstrucción. Existen obstrucciones más grandes en las que hay que poner en movimiento más de un vehículo que se encuentre bien aparcado para poder resolver el atasco. En la siguiente imagen se puede ver un ejemplo de ese tipo de atasco. Figura 4.34 Visualización de la obstrucción de la vía. En estos atascos primero se busca el vehículo más cercano al vehículo que se encuentra mal aparcado, tras encontrarlo se busca cada uno de los vehículos que se encuentran a una distancia determinada del vehículo cercano. Al tener todos los vehículos encontrados se les mandan la orden de ponerse en movimiento para que estos dejen la estación de carga libre y pueda entrar el vehículo que provoca la obstrucción. 5 Resultados En este capítulo se van a explicar los diferentes resultados obtenidos al ejecutar el programa de la simulación final. En dicha simulación se van a plantear diferentes situaciones iniciales con el fin de poder sacar conclusiones. Para obtener los resultados y poder analizarlos de forma visual se va a crear un excel con Python donde se muestran los datos más importantes de la simulación y con mayor interés. El objetivo que se busca al realizar diferentes simulaciones, es el de obtener datos suficientes para conocer el comportamiento de los vehículos con el control realizado y de analizar la eficiencia de las estaciones de carga. Las diferentes casuísticas que se van a analizar se van a obtener del control explicado en el apartado 4.2. Se van a conseguir diferentes situaciones gracias al control que se tiene sobre el número de vehículo, la energía inicial de la batería de estos, la potencia de carga de las diferentes estaciones de carga y el tiempo de simulación. Cambiando estos parámetros de forma independiente se pueden obtener situaciones totalmente diferentes para poder analizar. A continuación, se van a explicar como se van a analizar los datos de la simulación y las diferentes situaciones que se han creado y su análisis. 5.1 Ficheros de análisis Para poder obtener datos de las simulaciones se ha creado una función de Python que permite crear un excel con datos útiles para realizar el análisis. Este excel se va a generar al final de cada simulación y va a recoger los datos iniciales de cada simulación y los datos obtenidos al simular. •Primera página. En el excel se recoge en la primera página los vehículos que se han parado en cada estación por ciclo, se considera ciclo a cada una de las paradas que han hecho los vehículos para cargarse, si un vehículo se ha parado en una misma simulación dos veces para cargarse de manera completa se representará en el excel dos ciclos. Tras representar un ciclo en cada columna se representa en la ultima columna el total, que es el número total de vehículos que se han cargado por estación. En las últimas columnas aparece el tiempo de carga total de la estación y el tiempo medio de carga por vehículo de cada estación. 73 80 Capítulo 5. Resultados determinadas simulaciones no llega a llenarse por completo y los vehículos que llegan pueden ir a cargarse directamente sin parar en la zona de espera. Figura 5.5 Gráfica que representa el tiempo total de cada estación de carga para cada simulación. Como ya se ha explicado el tiempo total se define como la suma del tiempo medio de carga más el tiempo medio de espera de cada estación. En la gráfica 5.5 representada se puede observar que el tiempo total en la mayoría de las estaciones tiene un valor entorno a 1100 segundos, cuando el tiempo total tiene estos valores se entiende que no existen ninguna parada de espera en la cercanía de la estación por lo que todo el tiempo total representa el tiempo medio de carga de la estación en esos casos. El tiempo de carga medio de cada estación será muy similar para cada estación y simulación ya que todas las estaciones tienen la misma potencia de carga. La pequeña diferencia que hay entre esos tiempos se debe a que cada vehículo llega con una carga distinta a la estación, esta carga debe ser menor al mínimo de batería establecido que es 1300 Wh para todos los vehículos. El tiempo mínimo que puede estar un vehículo cargando en la estación hasta conseguir la carga completa se puede calcular analíticamente de la siguiente forma. Los datos necesarios se pueden ver en esta tabla 5.3. La energía mínima que se va a cargar a un vehículo se da cuando la variable que indica que está el vehículo en mínimos de batería se activa justo al llegar a la estación, por lo que la batería que queda por cargar es la diferencia entre la capacidad máxima de la batería y la energía mínima para cargar. Energiamin =Capbateria −Bateriamin =60000 −1300 =58700 Wh (5.4) Para poder calcular el tiempo que tarda la estación en cargar esa energía mínima se debe conocer la potencia de la estación y la eficiencia de cargar que es 0,95. tcarga =Energiamin Pestacin ∗E ficienciacarga =58700 200000 ∗0.95 =0.309 =1112 segundos (5.5) El tiempo mínimo que va a estar un vehículo parado en la estación de carga es de 1112 segundos, por ello se decía anteriormente que en la mayoría de las simulaciones le 5.4 Tercer análisis: Estación más usada y más lenta (2) 81 tiempo total para cada estación estaba entorno a 1100 segundos. Si se observa la gráfica 5.5 se ve que el tiempo total aumenta considerablemente en aquellas estaciones donde hay vehículos parados esperando a que se quede algún hueco libre, la única estación cuyo tiempo total no aumenta debido al tiempo de espera de los vehículos es la estación número 1. Por lo que esta estación será la más eficiente en términos de tiempo ya que los vehículos que paran en esta estación están menos tiempo parados en dicha estación o en su cercanía. 5.4 Tercer análisis: Estación más usada y más lenta (2) Con este análisis se busca encontrar cuál es la estación más usada y a su vez la más lenta, la idea es la misma que ya se ha presentado en el análisis anterior 5.3. En este caso en lugar de cambiar el número de vehículos que están en circulación para que cada simulación sea diferente, la variable que cambia es la carga inicial de cada vehículo que se va a tomar de manera aleatoria por lo que cada simulación va a ser totalmente diferente. En este análisis a diferencia del anterior se busca que los vehículos tengan más de un ciclo de carga y descarga, para conseguir esto se ha decidido reducir mucho la capacidad de la batería del vehículo para que la descarga total del vehículo no sea tan lenta. También se ha cambiado el límite de batería mínima que se ha puesto en un 20% de la capacidad total de la batería. – Características de la simulación Como ya se ha dicho se va a disminuir de manera considerable la capacidad máxima de los vehículos con el fin de que se den más ciclos de carga y descarga en una sola simulación. Para obtener más valores con los que comparar resultados se ha decidido hacer 8 simulaciones distintas, 4 de ellas con una capacidad máxima de batería de 5000 Wh y las otras con una capacidad máxima de 10000 Wh. En estas simulaciones se va a definir la carga inicial de cada vehículo como ya se ha dicho por medio de un número aleatorio definido directamente por Python, dependiendo de la máxima capacidad de la batería del vehículo de la simulación se va a definir entre diferentes valores. Tabla 5.5 Resumen: Parámetro constantes simulación capacidad 10000 Wh. Tiempo simulación (s) Capacidad batería veh (Wh) 10000 10000 Potencia estación (W) Capacidad estación (nºveh) 200000 7 Batería inicial (Wh) Energía mínima para cargar (Wh) 1400−10000 2000 Vehículos en circulación 100 82 Capítulo 5. Resultados Tabla 5.6 Resumen: Parámetro constantes simulación capacidad 5000 Wh. Tiempo simulación (s) Capacidad batería veh (Wh) 10000 5000 Potencia estación (W) Capacidad estación (nºveh) 200000 7 Batería inicial (Wh) Energía mínima para cargar (Wh) 1000−5000 1000 Vehículos en circulación 100 El rango de la carga inicial se ha tomado mayor con la idea de que los vehículos se queden sin batería en instantes distintos lo que hace que la simulación sea más realista y por ello las estaciones de carga tienen menos probabilidad de que se llenen al completo. – Resultados de la simulación A continuación, se van a representar los datos obtenidos en las diferentes simulaciones. El objetivo principal de la simulación es ver cual suele ser la estación de carga más usada y el tiempo de de carga y espera para simulaciones donde haya más de un ciclo de carga y descarga. Para obtener los valores de cada simulación se han hecho muchas simulaciones y se han tomado aquellas donde no se han producido grandes atascos, ya que existen algunas simulaciones en las que aparecen atascos y el recorrido de los vehículos de alguna de las rutas se ve alterado por lo que los resultados obtenidos dejan de ser reales. Se va a comenzar representando la eficiencia de cada estación de carga para cada una de las simulaciones, diferenciando entre las simulaciones donde la capacidad de la batería del vehículo es de 10000 Wh y de 5000 Wh. Figura 5.6 Gráfica que representa la eficiencia de cada estación de carga para las simulaciones de 10000 Wh de capacidad. 5.4 Tercer análisis: Estación más usada y más lenta (2) 83 Figura 5.7 Gráfica que representa la eficiencia de cada estación de carga para las simulaciones de 5000 Wh de capacidad. En la gráfica 5.6 se puede ver como la mayor eficiencia en cada una de las simulaciones se da para la estación 3 al igual que sucede en la gráfica 5.7. Por tanto, con estas simulaciones confirmamos que la estación 3 es la más eficiente del escenario, hecho que ya se ha dado en los análisis de las simulaciones anteriores 5.3. La segunda estación más usada en la gráfica 5.6 también se puede ver con claridad, ya que el valor de eficiencia es el segundo mayor con una gran diferencia sobre el resto. Por lo que se puede decir con toda seguridad que en condiciones normales de funcionamiento la segunda estación de carga más usada es la número 5. Esto también ocurre para la gráfica 5.7, aunque se puede ver con menos claridad en unas de las cuatros simulaciones, ya que para la simulación 4 la eficiencia tiene el mismo valor tanto para la estación 2 como para la 5. A pesar de esto se puede decir que la segunda estación más usada es la número 5 porque en las otras 3 simulaciones si se puede observar con claridad. Tabla 5.7 Eficiencia total de cada estación y simulación. Simulaciones de 10000 Wh de capacidad Eficiencia Total 654 670 712 624 Simulaciones de 5000 Wh de capacidad Eficiencia Total 1248 1222 1336 1218 La tabla 5.7 representa la suma total de eficiencia por simulación, valor denominado como eficiencia total, este valor no es de gran importancia para este análisis. Se puede ver como la variación de este en las diferentes simulaciones se traduce en que en cada una de ellas el número de vehículos cargados varía. A continuación se van a representar los tiempos de espera y totales por estación y simulación por separado, dependiendo de si la simulación es para vehículos con capacidad de 10000 Wh o de 5000 Wh. Primero se va a mostrar los resultados de tiempo para la simulación cuya capacidad es 10000 Wh. 84 Capítulo 5. Resultados Figura 5.8 Gráfica que representan el tiempo de espera y total de cada estación de carga para las simulaciones de 10000 Wh de capacidad. El tiempo de carga medio de cada estación va a ser muy similar ya que depende de dos factores como se comentó anteriormente, depende de la carga con la que lleguen los vehículos a la estación de carga y de la potencia de carga de cada estación, en este caso todas las estaciones tienen la misma potencia de carga 200 kW. Para estas simulaciones donde la capacidad máxima del vehículo es de 10000 Wh y el límite de la batería para cargar es de 2000 Wh se puede calcular el tiempo mínimo de carga que está relacionado con la mínima carga que se le va a realizar a un vehículo, para ello se presenta los cálculos realizados para obtener dicho tiempo. Energiamin =Capbateria −Bateriamin =10000 −2000 =8000 Wh (5.6) Para realizar este cálculo la eficiencia de cargar es 0.95. tcarga =Energiamin Pestacion ∗E ficienciacarga =8000 200000 ∗0.95 =0.0421 =151.57 segundos (5.7) El tiempo mínimo de carga de cada estación es 151.57 segundos, por lo que si se observa la tabla se puede ver que todos los tiempo de carga son mayores a este ya que los vehículos suelen llegar a la estación de carga con una energía inferior a la mínima de 2000 Wh. También se puede observar en la gráfica 5.8 que todos los tiempos totales son parecidos en todas las simulaciones y estaciones, esto se debe a que en estas simulaciones no hay vehículos parados en la cercanía de la estaciones esperando a que alguna de estas se queden libre, por lo que el tiempo de espera en todas las estaciones es 0. Esto se da porque la potencia de carga de la estación es muy alta en relación a la carga que hay que cargar por vehículo, lo que provoca que la parada del vehículo en la estación de carga sea muy pequeña, por lo que no van a coincidir un gran número de vehículos en una misma estación para que esta se quede completamente llena. A continuación se van a mostrar los tiempos totales y de espera de cada estación para las simulaciones realizadas donde la capacidad máxima del vehículos es de 5000 Wh. 5.4 Tercer análisis: Estación más usada y más lenta (2) 85 Figura 5.9 Gráfica que representan el tiempo de espera y total de cada estación de carga para las simulaciones de 5000 Wh de capacidad. Sabiendo que en estas simulaciones los vehículos tienen una capacidad máxima de 5000 Wh y el límite para que estos se dirijan a las estaciones de carga es de 1000 Wh, se puede calcular al igual que se ha hecho anteriormente el tiempo mínimo de carga que necesita cada vehículo. Para hacer este cálculo se debe conocer también la potencia que es 200 kW y la eficiencia de la estación que es de 0.95. A continuación se muestran los cálculos realizados para obtener el tiempo mínimo de carga. Energiamin =Capbateria −Bateriamin =5000 −1000 =4000 Wh (5.8) tcarga =Energiamin Pestacion ∗E ficienciacarga =4000 200000 ∗0.95 =0.02105 =75.8segundos (5.9) El tiempo de carga mínimo por estación es 75.8 segundos. Se puede ver en la gráfica 5.9 como los tiempos totales son mayores que este tiempo calculado de forma analítica, ya que normalmente los vehículos van a necesitar más tiempo de carga al llegar con una carga menor de 1000 Wh. El tiempo total representado en las simulaciones de capacidad de 5000 Wh tienen en cuenta también el tiempo de espera de cada vehículo por estación y este es 0 al igual que ocurre en las simulaciones de capacidad de 10000 Wh. El tiempo de espera es nulo debido a que ninguna estación de carga llega a llenarse con 7 vehículos a la vez, esto se debe como se explicó en la anterior simulación a que al ser tan pequeño el tiempo de carga que necesita el vehículo en relación con el tiempo total de simulación no le da tiempo a la estación de carga a llenarse. 86 Capítulo 5. Resultados 5.5 Tercer análisis: Estación más usada y más lenta (3) Se pretende realizar varias simulaciones en las que se cambie la potencia de carga de la estación con el fin de ver los cambios que se producen con respecto a una simulación de referencia. La idea es ver los cambios que se producen en los resultados obtenidos y ver si sigue siendo la estación de carga más usada la misma que en las simulaciones anteriores. Para esto se va a tomar como referencia la carga inicial de cada vehículo de una simulación anterior para que el resto de simulaciones sean idénticas, solo se va a cambiar de las simulaciones la potencia de carga de cada estación, el resto de valores serán idénticos a los valores de la simulación de referencia. – Características de la simulación Las diferentes simulaciones como ya se ha comentado, va a ser idéntica a una simulación de referencia. Como referencia se ha tomado la primera simulación realizada para el análisis anterior, cuyo valores característicos son los siguientes: Tabla 5.8 Resumen: Parámetro constantes simulación capacidad 10000 Wh. Tiempo simulación (s) Capacidad batería veh (Wh) 10000 10000 Capacidad estación (nºveh) Energía mínima para cargar (Wh) 7 2000 Vehículos en circulación 100 En esta tabla no se ha representado la batería inicial ya que en este caso no se va a definir para cada simulación de forma aleatoria, si no que va a ser dato ya que se toma la misma carga inicial de la simulación de referencia para el resto de simulaciones. Además de no aparecer la carga inicial, tampoco aparece el valor de la potencia de la estación de carga ya que este valor va a ser diferente para cada simulación, al ser esta la variable que se va a ir cambiando para cada simulación. El valor de potencia de cada estación se va a representar junto a los resultados para saber que valor se le ha dado para cada estación y simulación. – Resultados Se van a representar los resultados obtenidos al realizar varias simulaciones en las que se ha ido variando la potencia de la estación. El objetivo de estas simulaciones es ver el cambio que se produce en las eficiencias de cada estación y en el tiempo total por estación, cuando se va variando la potencia de carga de cada estación. Para ello se van a realizar 6 simulaciones diferentes entre las que se va cambiar la potencia de carga, se va a hacer una primera simulación donde todas las estaciones tengan la nueva potencia de carga , 4 simulaciones donde se ha decidido cambiar la potencia de cagar por ruta, es decir todas las estaciones que estén contenidas en una ruta van a tener la nueva potencia de carga y una simulación donde la estación 3 que es la de mayor eficiencia se la única que tenga una potencia de carga nueva. ∗La nueva potencia de carga es 100 kW En esta primera tabla representada se muestran los valores de potencia de carga que va a tomar cada estación para cada simulación. Esto se hace para que en la 5.5 Tercer análisis: Estación más usada y más lenta (3) 87 gráfica que se va a representar más adelante se pueda relacionar la leyenda con la característica de la simulación. Tabla 5.9 Características de cada simulación. Sim 1 Sim 2 Sim 3 Sim 4 Estación Potencia (W) Potencia (W) Potencia (W) Potencia (W) 1 200000 100000 200000 200000 2 200000 100000 200000 200000 3 200000 100000 100000 100000 4 200000 100000 200000 200000 5 200000 100000 200000 200000 6 200000 100000 200000 200000 7 200000 100000 100000 200000 8 200000 100000 200000 200000 Sim 5 Sim 6 Sim 7 Estación Potencia (W) Potencia (W) Potencia (W) 1 200000 100000 200000 2 200000 200000 100000 3 200000 200000 200000 4 100000 200000 200000 5 100000 200000 200000 6 200000 200000 100000 7 200000 200000 100000 8 100000 100000 200000 A continuación, se va a mostrar una gráfica que representa la eficiencia de cada estación para cada una de las 7 simulaciones que se han realizado. Para entender que diferencias existen entre una simulación y otra hay que ver la tabla 5.11 con la que se relaciona el nombre de la leyenda de la gráfica y las características de la simulación. Figura 5.10 Gráfica que representan la eficiencia de cada estación de carga para las simulaciones. 88 Capítulo 5. Resultados A pesar de haber modificado la potencia de carga de las estaciones, el comportamiento de la red es similar y la estación de carga más usada sigue siendo la estación de carga número 3. La segunda estación de carga más usada varía de un análisis a otro. En el análisis anterior 5.4 la segunda estación de carga más usada era la número 5, mientras que en este análisis la segunda estación de carga más usada en algunas simulaciones es la estación de carga número 2 y en otras la número 5. Tabla 5.10 Eficiencia total para cada simulación. Sim 1 Sim 2 Sim 3 Sim 4 Sim 5 Sim 6 Sim 7 Eficiencia Total 654 628 660 644 638 640 644 En la tabla 5.10 se puede ver la eficiencia total de cada simulación que al ser las simulaciones parecidas no va a variar mucho la eficiencia total de una simulación a otra ya que las cargas iniciales de los vehículos son idénticas de una simulación a otra. En la siguiente gráfica se muestran los tiempos totales de cada estación y simulación. Se ha divido la representación en dos gráficas distintas para facilitar la visualización. Figura 5.11 Gráficas que representan el tiempo total de cada estación de carga para las simulaciones. Se puede ver como los tiempos varían entre dos valores distintos, esto se debe a que en algunas simulaciones hay dos potencias de carga diferentes, se van a mostrar los cálculos del tiempo mínimo de carga para cargar la mínima carga necesaria. Para las estaciones de carga con una potencia de 200 kW y una energía mínima a cargar de 8000 Wh el tiempo de carga mínimo necesario es de 151.57 segundos, valor que se ha calculado analíticamente anteriormente en el punto 5.7. Si se observan las estaciones con dicha potencia se puede ver que el valor del tiempo total está entorno a 155 segundos, por lo que no se aleja mucho del valor de tiempo mínimo que se ha calculado. Esto se debe a que las estaciones en estas simulaciones no se llenan al completo y el tiempo de espera es nulo. Para las estaciones de carga con una potencia de 100 kW se sabe que al igual que en las de 200 kW la energía mínima que se debe cargar al vehículo es de 8000 Wh, 5.5 Tercer análisis: Estación más usada y más lenta (3) 89 sabiendo esto y la eficiencia de la estación que siempre es de 0.95 se puede calcular el tiempo mínimo de carga de forma analítica: tcarga =Energiamin Pestacion ∗E ficienciacarga =8000 100000 ∗0.95 =0.08421 =303.16 segundos (5.10) Como se puede ver en la tabla el tiempo total de las estaciones con potencia de 100 kW está entorno 315 segundos, valores ligeramente superiores al tiempo mínimo de carga calculado que es 303.16 segundos. El tiempo total no es mucho mayor que el tiempo mínimo debido a que el tiempo de espera es nulo en las estaciones con potencia de 100 kW como ya ocurría para las estaciones de 200 kW. ∗La nueva potencia de carga es 50 kW Antes de comenzar representando las gráficas de los resultados se va a representar una tabla con la potencia que va a tomar cada estación en cada simulación, para poder identificar fácilmente las características de cada simulación. Tabla 5.11 Características de cada simulación. Sim 1 Sim 2 Sim 3 Sim 4 Estación Potencia (W) Potencia (W) Potencia (W) Potencia (W) 1 200000 50000 200000 200000 2 200000 50000 200000 200000 3 200000 50000 50000 50000 4 200000 50000 200000 200000 5 200000 50000 200000 200000 6 200000 50000 200000 200000 7 200000 50000 50000 200000 8 200000 50000 200000 200000 Sim 5 Sim 6 Sim 7 Estación Potencia (W) Potencia (W) Potencia (W) 1 200000 50000 200000 2 200000 200000 50000 3 200000 200000 200000 4 50000 200000 200000 5 50000 200000 200000 6 200000 200000 50000 7 200000 200000 50000 8 50000 50000 200000 Se van a representar los resultados obtenidos para cada simulación al variar la potencia de carga entre 200 kW y 50 kW. En la gráfica ?? se va a representar la eficiencia de cada estación para cada simulación diferente. 96 Índice de Figuras 4.14 Visualización de la simulación en SUMO: Vehículo cargando en la estación de carga 49 4.15 Visualización de la simulación en SUMO: Se ve la ruta del vehículo y la cuenta de la duración de la parada. 49 4.16 Visualización de la simulación en SUMO: Se ve la ruta del vehículo y la cuenta de la duración de la parada con valor negativo 50 4.17 Visualización de la simulación en SUMO: 1º Vehículo en movimiento 50 4.18 Gráfica donde se observa la velocidad y la energía del vehículo en cada instante 51 4.19 Visualización de la simulación en SUMO: Vehículo en movimiento 54 4.20 Visualización de la simulación en SUMO: Vehículo sigue en movimiento 55 4.21 Visualización de la simulación en SUMO: Vehículo parado en la estación de carga 55 4.22 Visualización de la simulación en SUMO: Vehículo saliendo de la estación de carga 56 4.23 Gráfica donde se observa la velocidad y la energía del vehículo en cada instante 56 4.24 Visualización de la simulación en SUMO: Vehículos en movimiento 59 4.25 Visualización de la simulación en SUMO: Un vehículo cargando y otro en movimiento 60 4.26 Visualización de la simulación en SUMO: Un vehículo cargando y el otro en espera 60 4.27 Visualización de la simulación en SUMO: Un vehículo en movimiento y otro cargando 61 4.28 Gráfica donde se observa la velocidad y la energía del vehículo carflow.0 en cada instante 61 4.29 Gráfica donde se observa la velocidad y la energía del vehículo carflow.1 en cada instante 62 4.30 Visualización del escenario de la simulación final en NetEdit 63 4.31 Visualización del detector de área 64 4.32 Visualización de las rutas y estaciones sobre el escenario 65 4.33 Visualización de la obstrucción de la vía 71 4.34 Visualización de la obstrucción de la vía 71 5.1 Representación de ejemplo de los datos en el excel 74 5.2 Representación de ejemplo de los datos en el excel 74 5.3 Gráfica que representa la eficiencia de cada estación de carga para cada simulación 78 5.4 Gráfica que representa el tiempo de espera medio de cada estación de carga para cada simulación 79 5.5 Gráfica que representa el tiempo total de cada estación de carga para cada simulación 80 5.6 Gráfica que representa la eficiencia de cada estación de carga para las simulaciones de 10000 Wh de capacidad 82 5.7 Gráfica que representa la eficiencia de cada estación de carga para las simulaciones de 5000 Wh de capacidad 83 5.8 Gráfica que representan el tiempo de espera y total de cada estación de carga para las simulaciones de 10000 Wh de capacidad 84 5.9 Gráfica que representan el tiempo de espera y total de cada estación de carga para las simulaciones de 5000 Wh de capacidad 85 5.10 Gráfica que representan la eficiencia de cada estación de carga para las simulaciones 87 5.11 Gráficas que representan el tiempo total de cada estación de carga para las simulaciones 88 5.12 Gráficas que representan la eficiencia de cada estación de carga para las simulaciones 90 5.13 Gráficas que representan el tiempo total de cada estación de carga para las simulaciones 91 Índice de Tablas 1.1 Características de un vehículo eléctrico puro 2 1.2 Características de un vehículo de combustión interna 2 1.3 Comparativa entre un vehículo eléctrico y uno de combustión 3 2.1 Características de los tipos de cargas que hay en la actualidad 11 2.2 Comparación de diferentes simuladores 14 4.1 Parámetros para la definición de una estación de carga 31 4.2 Parámetros de la definición de un vehículo eléctrico 33 4.3 Parámetros de la definición de el tipo de vehículo 33 4.4 Parámetros utilizados para la definición de una ruta 34 4.5 Parámetros utilizados para la asignación de una ruta (vehicle) 34 4.6 Parámetro para definir la batería inicial del vehículo 34 4.7 Parámetros utilizados para la asignación de una ruta (flow) 35 4.8 Parámetro para definir la batería inicial del vehículo 35 4.9 Vehículos definidos en esta simulación 39 4.10 Parámetro de la función "traci.vehicle.setStop" 46 4.11 Diferentes tipos de paradas (flags)" 46 4.12 Parámetros para la definición de un detector de área 64 5.1 Resumen: Parámetro constantes 76 5.2 Resumen: Parámetro constantes 76 5.3 Resumen: Parámetro constantes 77 5.4 Eficiencia total 79 5.5 Resumen: Parámetro constantes simulación capacidad 10000 Wh 81 5.6 Resumen: Parámetro constantes simulación capacidad 5000 Wh 82 5.7 Eficiencia total de cada estación y simulación 83 5.8 Resumen: Parámetro constantes simulación capacidad 10000 Wh 86 5.9 Características de cada simulación 87 5.10 Eficiencia total para cada simulación 88 5.11 Características de cada simulación 89 5.12 Eficiencia total para cada simulación 90 97 Bibliografía [1] Javier Gómara (1), Cinco millones de vehículos eléctricos: la cifra que españa necesita para 2030, Abr 2022. [2] Volvo Car Corporation (1), Especificaciones del ex30, 2023. [3] Javier Gómara (2), El gobierno publicará un detallado mapa de puntos de recarga para coches eléctricos, Feb 2022. [4] Volvo Car Corporation (2), Especificaciones del xc60, 2023. [5] Andres Acosta, Traci4matlab, Mar 2015. [6] BBVA, Diferencias entre un híbrido y un híbrido enchufable, Ene 2020. [7] Alberto Pardo Calvo, C4r: Generación de modelos de movilidad para redes de vehículos a partir de mapas reales, 2011. [8] Qingqi Pei y Ning Zhang Chen Chen, Yanan Jin, A connectivity-aware intersection-based routing in vanets, EURASIP Journal on Wireless Communications and Networking (2014). [9] Clicars, Fcev, ¿qué es y qué significan estas siglas?, Dic 2021. [10] Gobierno de España, Perte para el desarrollo del vehículo eléctrico y conectado, 2021. [11] D. Tomás de francisco Aparicio, Simulación de tráfico en ciudades inteligentes con sumo, 2018. [12] Carlos Bustillo de Rio, Iniciativas necesarias para fomentar el uso de vehículos eléctricos, EL PAÍS (2022). [13] German Aerospace Center (DLR), Traci, 2023. [14] Manu Granda, Esta es la distribución de los puntos de carga para coches eléctricos en españa, EL PAÍS (2022). [15] IDAE, Programa moves iii, Abr 2021. [16] Viviana Estefany Ríos Ocampo, Estado del arte de los vehículos eléctricos y su posible implementación en colombia, 2017. [17] Abigail Orús, Número anual de vehículos eléctricos matriculados en españa 2013-2022, Ene 2023. [18] Laura Bieker-Walz Jakob Erdmann Yun-Pang Flötteröd Robert Hilbrich Leonhard Lücken Johannes Rummel Peter Wagner Pablo Alvarez Lopez, Michael Behrisch and Evamarie Wießner, Microscopic traffic simulation using sumo, Mar 2018. 99 100 Bibliografía [19] Ministerio para la Transición Ecológica y el Reto Demográfico, Real decreto 266/2021, Abr 2021. [20] SmartWallboxes, Guía de la infraestructura de recarga de vehículos eléctricos (irve), Feb 2022. [21] Christoph Sommer, The open source vehicular network simulation framework, Mar 2020. [22] S.Santillán, Diferencias entre un híbrido y un híbrido enchufable, Ene 2020. [23] Juan Antonio Zamora y Edgar Peralta, Estado del arte en carga estacionaria y dinámica de vehículos eléctricos, Revista de Tecnología e Innovación (2016). Glosario 101