Managing Industrial Simulator Visual Databases Using Geographic Information Systems

Geographic Information Systems are developed to handle enormous volumes of data and are equipped with numerous functionalities intended to capture, store, edit, organise, process and analyse or represent the geographically referenced information. On the other hand, industrial simulators for driver training are real-time applications that require a virtual environment, either geospecific, geogeneric or a combination of the two, over which the simulation programs will be run. In the final instance, this environment constitutes a geographic location with its specific characteristics of geometry, appearance, functionality, topography, etc. The set of elements that enables the virtual simulation environment to be created and in which the simulator user can move, is usually called the Visual Database (VDB). The main idea behind the work being developed approaches a topic that is of major interest in the field of industrial training simulators, which is the problem of analysing, structuring and describing the virtual environments to be used in large driving simulators. This paper sets out a methodology that uses the capabilities and benefits of Geographic Information Systems for organising, optimising and managing the visual Database of the simulator and for generally enhancing the quality and performance of the simulator.

Assessment of CTF boiling transition and critical heat flux modeling capabilities using the OECD/NRC BFBT and PSBT benchmark databases

The need to refine models for best-estimate calculations, based on good-quality experimental data, has been expressed in many recent meetings in the field of nuclear applications. The modeling needs arising in this respect should not be limited to the currently available macroscopic methods but should be extended to next-generation analysis techniques that focus on more microscopic processes. One of the most valuable databases identified for the thermalhydraulics modeling was developed by the Nuclear Power Engineering Corporation (NUPEC), Japan. From 1987 to 1995, NUPEC performed steady-state and transient critical power and departure from nucleate boiling (DNB) test series based on the equivalent full-size mock-ups. Considering the reliability not only of the measured data, but also other relevant parameters such as the system pressure, inlet sub-cooling and rod surface temperature, these test series supplied the first substantial database for the development of truly mechanistic and consistent models for boiling transition and critical heat flux. Over the last few years the Pennsylvania State University (PSU) under the sponsorship of the U.S. Nuclear Regulatory Commission (NRC) has prepared, organized, conducted and summarized the OECD/NRC Full-size Fine-mesh Bundle Tests (BFBT) Benchmark. The international benchmark activities have been conducted in cooperation with the Nuclear Energy Agency/Organization for Economic Co-operation and Development (NEA/OECD) and Japan Nuclear Energy Safety (JNES) organization, Japan. Consequently, the JNES has made available the Boiling Water Reactor (BWR) NUPEC database for the purposes of the benchmark. Based on the success of the OECD/NRC BFBT benchmark the JNES has decided to release also the data based on the NUPEC Pressurized Water Reactor (PWR) subchannel and bundle tests for another follow-up international benchmark entitled OECD/NRC PWR Subchannel and Bundle Tests (PSBT) benchmark. This paper presents an application of the joint Penn State University/Technical University of Madrid (UPM) version of the well-known subchannel code COBRA-TF, namely CTF, to the critical power and departure from nucleate boiling (DNB) exercises of the OECD/NRC BFBT and PSBT benchmarks

System supporting public transport based on geolocation

El propósito de este proyecto de fin de Grado es el estudio y desarrollo de una aplicación basada en Android que proporcionará soporte y atención a los servicios de transporte público existentes en Cracovia, Polonia. La principal funcionalidad del sistema será consultar la posición de un determinado autobús o tranvía y mostrar su ubicación con exactitud. Para lograr esto, necesitaremos tres fases de desarrollo. En primer lugar, deberemos implementar un sistema que obtenga las coordenadas geográficas de los vehículos de transporte público en cada instante. A continuación, tendremos que registrar todos estos datos y almacenarlos en una base de datos en un servidor web. Por último, desarrollaremos un sistema cliente que realice consultas a tiempo real sobre estos datos almacenados, obteniendo la posición para una línea determinada y mostrando su ubicación con un marcador en el mapa. Para hacer el seguimiento de los vehículos, sería necesario tener acceso a una API pública que nos proporcionase la posición registrada por los GPS que integran cada uno de ellos. Como esta API no existe actualmente para los servicios de autobús, y para los tranvías es de uso meramente privado, desarrollaremos una segunda aplicación en Android que hará las funciones del lado servidor. En ella podremos elegir mediante una simple interfaz el número de línea y un código específico que identificará a cada vehículo en particular (e.g. podemos tener 6 tranvías recorriendo la red al mismo tiempo para la línea 24). Esta aplicación obtendrá las coordenadas geográficas del teléfono móvil, lo cual incluye latitud, longitud y orientación a través del proveedor GPS. De este modo, podremos realizar una simulación de como el sistema funcionará a tiempo real utilizando la aplicación servidora desde dentro de un tranvía o autobús y, al mismo tiempo, utilizando la aplicación cliente haciendo peticiones para mostrar la información de dicho tranvía. El cliente, además, podrá consultar la ruta de cualquier línea sin necesidad de tener acceso a Internet. Almacenaremos las rutas y paradas de cada línea en la memoria del teléfono móvil utilizando ficheros XML debido al poco espacio que ocupan y a lo útil que resulta poder consultar un trayecto en cualquier momento, independientemente del acceso a la red. El usuario también podrá consultar las tablas de horarios oficiales para cada línea. Aunque en este caso si será necesaria una conexión a Internet debido a que se realizará a través de la web oficial de MPK. Para almacenar todas las coordenadas de cada vehículo en cada instante necesitaremos crear una base de datos en un servidor. Esto se resolverá mediante el uso de MYSQL y PHP. Se enviarán peticiones de tipo GET y POST a los servicios PHP que se encargarán de traducir y realizar la consulta correspondiente a la base de datos MYSQL. Por último, gracias a todos los datos recogidos relativos a la posición de los vehículos de transporte público, podremos realizar algunas tareas de análisis. Comparando la hora exacta a la que los vehículos pasaron por cada parada y la hora a la que deberían haber pasado según los horarios oficiales, podremos descubrir fallos en estos. Seremos capaces de determinar si es un error puntual debido a factores externos (atascos, averías,…) o si por el contrario, es algo que ocurre muy a menudo y se debería corregir el horario oficial. ABSTRACT The aim of this final Project (for University) is to develop an Android application thatwill provide support and feedback to the public transport services in Krakow. The main functionality of the system will be to track the position of a desired bus or tram line, and display its position on the map. To achieve this, we will need 3 stages: the first one will be to implement a system that sends the geographical position of the public transport vehicles, the second one will be to collect this data in a web server, and the last one will be to get the last location registered for the desired line and display it on the map. For tracking the vehicles, we would need to have access to a public API that should be connected with each bus/tram GPS. As this doesn’t exist in Krakow or at least is not available for public use, we will develop a second android application that will do the server side job. We will be able to choose in a simple interface the line number and a code letter to identify each vehicle (e.g. we can have 6 trams that belong to the line number 24 working at the same time). It will take the current mobile geolocation; this includes getting latitude, longitude and bearing from the GPS provider. Thus, we will be able to make a simulation of how the system works in real time by using the server app inside a tram and at the same time, using the client app and making requests to display the information of that tram. The client will also be able to check the path of the desired line without internet access. We will store the path and stops for each line locally in the phone memory using xml files due to the few requirements of available space it needs and the usefulness of checking a path when needed. This app will also offer the functionality of checking the timetable for the line, but in this case, it will link to the official Mpk website, so Internet access will be required. For storing all the coordinates for each vehicle at every moment we will need to create a database on a server. We have decided that the easiest way is to use Mysql and PHP for the deployment of the service. We will send GET and POST requests to the php files and those files will make the according queries to our database. Finally, based on all the collected data, we will be able to get some information about errors in the system of public transport timetables. We will check at what time a line was in each specific stop and compare it with the official timetable to find mistakes of time. We will determine if it is something that happens occasionally and related to external factors (e.g. traffic jams, breakdowns…) or if on the other hand, it is something that happens very often and the public transport timetables should be looked over and corrected.

Assessment of CTF boiling transition and critical heat flux modeling capabilities using the OECD/NRC BFBT and PSBT benchmark databases

Over the last few years, the Pennsylvania State University (PSU) under the sponsorship of the US Nuclear Regulatory Commission (NRC) has prepared, organized, conducted, and summarized two international benchmarks based on the NUPEC data—the OECD/NRC Full-Size Fine-Mesh Bundle Test (BFBT) Benchmark and the OECD/NRC PWR Sub-Channel and Bundle Test (PSBT) Benchmark. The benchmarks’ activities have been conducted in cooperation with the Nuclear Energy Agency/Organization for Economic Co-operation and Development (NEA/OECD) and the Japan Nuclear Energy Safety (JNES) Organization. This paper presents an application of the joint Penn State University/Technical University of Madrid (UPM) version of the well-known sub-channel code COBRA-TF (Coolant Boiling in Rod Array-Two Fluid), namely, CTF, to the steady state critical power and departure from nucleate boiling (DNB) exercises of the OECD/NRC BFBT and PSBT benchmarks. The goal is two-fold: firstly, to assess these models and to examine their strengths and weaknesses; and secondly, to identify the areas for improvement.

Improving flexible databases searches using machine learning

El objetivo principal de este proyecto ha sido introducir aprendizaje automático en la aplicación FleSe. FleSe es una aplicación web que permite realizar consultas borrosas sobre bases de datos nítidos. Para llevar a cabo esta función la aplicación utiliza unos criterios para definir los conceptos borrosos usados para llevar a cabo las consultas. FleSe además permite que el usuario cambie estas personalizaciones. Es aquí donde introduciremos el aprendizaje automático, de tal manera que los criterios por defecto cambien y aprendan en función de las personalizaciones que van realizando los usuarios. Los objetivos secundarios han sido familiarizarse con el desarrollo y diseño web, al igual que recordar y ampliar el conocimiento sobre lógica borrosa y el lenguaje de programación lógica Ciao-Prolog. A lo largo de la realización del proyecto y sobre todo después del estudio de los resultados se demuestra que la agrupación de los usuarios marca la diferencia con la última versión de la aplicación. Esto se basa en la siguiente idea, podemos usar un algoritmo de aprendizaje automático sobre las personalizaciones de los criterios de todos los usuarios, pero la gran diversidad de opiniones de los usuarios puede llevar al algoritmo a concluir criterios erróneos o no representativos. Para solucionar este problema agrupamos a los usuarios intentando que cada grupo tengan la misma opinión o mismo criterio sobre el concepto. Y después de haber realizado las agrupaciones usar el algoritmo de aprendizaje automático para precisar el criterio por defecto de cada grupo de usuarios. Como posibles mejoras para futuras versiones de la aplicación FleSe sería un mejor control y manejo del ejecutable plserver. Este archivo se encarga de permitir a la aplicación web usar el lenguaje de programación lógica Ciao-Prolog para llevar a cabo la lógica borrosa relacionada con las consultas. Uno de los problemas más importantes que ofrece plserver es que bloquea el hilo de ejecución al intentar cargar un archivo con errores y en caso de ocurrir repetidas veces bloquea todas las peticiones siguientes bloqueando la aplicación. Pensando en los usuarios y posibles clientes, sería también importante permitir que FleSe trabajase con bases de datos de SQL en vez de almacenar la base de datos en los archivos de Prolog. Otra posible mejora basarse en distintas características a la hora de agrupar los usuarios dependiendo de los conceptos borrosos que se van ha utilizar en las consultas. Con esto se conseguiría que para cada concepto borroso, se generasen distintos grupos de usuarios, los cuales tendrían opiniones distintas sobre el concepto en cuestión. Así se generarían criterios por defecto más precisos para cada usuario y cada concepto borroso.---ABSTRACT---The main objective of this project has been to introduce machine learning in the application FleSe. FleSe is a web application that makes fuzzy queries over databases with precise information, using defined criteria to define the fuzzy concepts used by the queries. The application allows the users to change and custom these criteria. On this point is where the machine learning would be introduced, so FleSe learn from every new user customization of the criteria in order to generate a new default value of it. The secondary objectives of this project were get familiar with web development and web design in order to understand the how the application works, as well as refresh and improve the knowledge about fuzzy logic and logic programing. During the realization of the project and after the study of the results, I realized that clustering the users in different groups makes the difference between this new version of the application and the previous. This conclusion follows the next idea, we can use an algorithm to introduce machine learning over the criteria that people have, but the problem is the diversity of opinions and judgements that exists, making impossible to generate a unique correct criteria for all the users. In order to solve this problem, before using the machine learning methods, we cluster the users in order to make groups that have the same opinion, and afterwards, use the machine learning methods to precise the default criteria of each users group. The future improvements that could be important for the next versions of FleSe will be to control better the behaviour of the plserver file, that cost many troubles at the beginning of this project and it also generate important errors in the previous version. The file plserver allows the web application to use Ciao-Prolog, a logic programming language that control and manage all the fuzzy logic. One of the main problems with plserver is that when the user uploads a file with errors, it will block the thread and when this happens multiple times it will start blocking all the requests. Oriented to the customer, would be important as well to allow FleSe to manage and work with SQL databases instead of store the data in the Prolog files. Another possible improvement would that the cluster algorithm would be based on different criteria depending on the fuzzy concepts that the selected Prolog file have. This will generate more meaningful clusters, and therefore, the default criteria offered to the users will be more precise.