DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ

Tamaño: px
Comenzar la demostración a partir de la página:

Download "DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ"

Transcripción

1 DISEÑO Y REALIZACIÓN DE UN SISTEMA ON BOARD DIAGNOSTICS (OBD-II) ALUMNO: OSCAR RAYO MANSILLA DIRECTOR: JORDI SELLARÈS GONZÁLEZ 4 DE JUNIO DE 2009

2 2

3 ÍNDICE 1. Introducción Justificación del proyecto Antecedentes Objetivos Alcance del proyecto Descripción general del proyecto Descripción básica del hardware Descripción básica del software Diseños realizados Metodología utilizada Recursos utilizados Descripción del diseño del modem interface Descripción del diseño del programador JDM Modificaciones del diseño del modem Diseño de la aplicación de prueba en C Diseño de la aplicación de prueba en JAVA Diseño de la aplicación gráfica diseñada en JAVA

4 3. Resultados Ámbito de utilización Validación de los diseños Descripción del funcionamiento Aplicaciones del proyecto Comentarios finales Plan de trabajo Lista de materiales Presupuesto Objetivos logrados Conclusiones Mejoras futuras Bibliografía Anexo 74 4

5 1. Introducción 1.1. Justificación del proyecto La motivación principal de este proyecto es llegar a poder diseñar un sistema con el que poder diagnosticar las posibles averías de cualquier vehículo sin tener que recurrir a los costosos servicios oficiales. Normalmente cuando se nos avería el coche siempre tenemos que acabar recurriendo a los talleres de reparación de los cuales dispone el fabricante de nuestro vehículo, y aunque desconocemos cuales son los medios de los que disponen para diagnosticar la avería, si sabemos que existe un herramienta que conectándola al vehículo averigua el problema al instante. Esto se debe a que estas marcas tan famosas equipan nuestros coches con sistemas electrónicos capaces de gestionar toda la mecánica y electricidad de que dispone, sin más ayuda que la de un modulo electrónico. En realidad estos módulos no son más que una pequeña computadora a la cual si se conoce su funcionamiento se puede acceder aunque su fabricante intente taparlo, cosa que no les es posible ya que desde hace ya bastantes años están obligados a implementar un estándar de autodiagnóstico llamado OBD-II, que se hizo público a consecuencia de las grandes emisiones contaminantes a las que estamos expuestos, implantando así un mecanismo de control de estas. Estos módulos son el objetivo de este proyecto, ya que en el momento que podamos comunicarnos con ellos podremos saber que le ocurre a nuestro coche y por tanto cuando tengamos que acudir al taller nosotros sabremos, en parte, si nos están estafando, cosa que lamentablemente a veces pasa. 5

6 1.2. Antecedentes OBD (On Board Diagnostics) es un sistema de diagnóstico a bordo en vehículos (coches y camiones). Actualmente se emplea OBD-II (Estados Unidos), EOBD (Europa), y JOBD (Japón) estándar que aportan un control casi completo del motor y otros dispositivos del vehículo. OBD II es la abreviatura de On Board Diagnostics (Diagnóstico de Abordo) II, la segunda generación de los requerimientos del equipamiento autodiagnosticable de abordo de los Estados Unidos de América. Las características de autodiagnóstico de a bordo están incorporadas en el hardware y el software de la computadora de abordo de un vehículo para monitorear prácticamente todos los componentes que pueden afectar las emisiones. Cada componente es monitoreado por una rutina de diagnóstico para verificar si está funcionando perfectamente. Si se detecta un problema o una falla, el sistema de OBD II ilumina una lámpara de advertencia en el cuadro de instrumentos para avisarle al conductor. La lámpara de advertencia normalmente lleva la inscripción "Check Engine" o "Service Engine Soon". El sistema también guarda informaciones importantes sobre la falla detectada para que un mecánico pueda encontrar y resolver el problema. En los Estados Unidos de América, todos los vehículos de pasajeros y los camiones de gasolina y combustibles alternos a partir de 1996 deben contar con sistemas de OBD II, al igual que todos los vehículos de pasajeros y camiones de diesel a partir de 1997, en Europa a partir del año 2001 se obliga implantar el estándar EOBD. Además, un pequeño número de vehículos de gas fueron equipados con sistemas de OBD II. Por tanto la pregunta ahora es, qué fue OBD I? OBD I fue la primera regulación de OBD que obligaba a los productores a instalar un sistema de monitoreo de algunos de los componentes controladores de emisiones en automóviles. Obligatorios en todos los vehículos a partir de 1991, los sistemas de OBD I no eran tan efectivos porque solamente monitoreaban algunos de los componentes relacionados con las emisiones, y no eran calibrados para un nivel específico de emisiones. Y además, qué es EOBD? EOBD es la abreviatura de European On Board Diagnostics (Diagnóstico de a Bordo Europeo), la variación europea de OBD II. Una de las diferencias es que no se monitorean las evaporaciones del depósito. Sin embargo, EOBD es un sistema mucho más sofisticado que OBD II ya que usa "mapas" de las entradas a 6

7 los sensores expectadas basados en las condiciones de operación del motor, y los componentes se adaptan al sistema calibrándose empíricamente. Esto significa que los repuestos necesitan ser de alta calidad y específicos para el vehículo y modelo. Todos los estándares antes mencionados implementan varios modos de trabajo, es decir, según la parte de información a la que queramos acceder necesitamos utilizar un modo diferente, dentro de cada uno de ellos podemos usar un abanico de parámetros muy amplio. Los modos de trabajo más extendidos son los siguientes: Modo 01: Se utiliza para determinar qué información del modulo electrónico (ECU) está a disposición de la herramienta de exploración. Modo 02: Muestra los llamados en este contexto Freeze Frame Data, es decir, capturas puntuales de información que ha ido almacenado la ECU. Modo 03: Lista los posibles fallos producidos en la mecánica mediante códigos de error identificativos (DTC). Modo 04: Se utiliza para borrar los códigos de error almacenados (DTC) y los datos Freeze Frame Data. Modo 05: Muestra los valores tomados a los sensores de oxigeno y los resultados de los test que les ha realizado de forma autónoma la ECU. Modo 06: Se usa para obtener los resultados de los test realizados por la ECU al sistema de monitoreo no continuo. Existe normalmente un valor mínimo, máximo y actual de cada uno de los test. Modo 07: Se usa para solicitar resultados al sistema de control permanente. Este modo lo suelen utilizar los técnicos después de una reparación del vehículo, y después de borrar la información de diagnóstico para ver los resultados de las pruebas después de un solo ciclo de conducción, determinando si la reparación ha solucionado el problema. Sólo hay tres monitores continuos identificados: combustible, fallo de encendido, e integridad de los componentes. En este proyecto solo se va ha hacer uso del modo 01, 03 y 04, aunque teniendo en cuenta que el modo 01 dispone de más de 60 PID s diferentes, no es poco el trabajo a desarrollar. 7

8 Actualmente ya existen muchas herramientas y software disponible para poder llevar a cabo la inspección de un vehículo dotado de OBD-II. Existen muchos tipos de herramientas distintas, pero principalmente la gran diferencia entre ellas es si pueden o no trabajar de forma autónoma, es decir, si necesitan o no ser ejecutadas en un ordenador personal bajo un sistema operativo. Como ejemplo podemos encontrarnos el software llamado ScanMaster, el cual se puede utilizar de forma completa previo pago de una pequeña cantidad de dinero: 8

9 También podemos encontrar el software ScanTool.net, el cual ha sido de mucha utilidad para este proyecto ya que en una de sus versiones ofrece el código fuente con el que fue diseñado: Estos programas están diseñados para trabajar junto con el microcontrolador ELM327, es decir, necesitan de este elemento intermedio entre el PC y el vehículo. Existen en el mercado muchos modelos de interface disponibles en el mercado, pero todas se basan en este micro. A continuación podemos ver algunos ejemplos: Interface ELM327 9

10 Interface ELM327 Interface ELM327 con Bluetooth En las imágenes vemos que los modelos tienen diferentes formas y diferentes métodos de conexión, ya que en uno de los casos se realiza por bluetooth, pero su funcionamiento respecto al estándar OBD-II es idéntico Objetivos Este proyecto abarca una pequeña parte del complejo campo de la autodiagnosis en la automoción, y por tanto no pretende crear un sistema que pueda substituir a las avanzadas herramientas de las que dispone cualquier servicio de manteniendo, ya que el estándar OBD-II, aun siendo de libre acceso, comprende modos de trabajo de los cuales no se tiene información en este proyecto. Mucha de la documentación que engloba al OBD-II está disponible previo pago a las respectivas empresas que lo han diseñado y estandarizado, como es el caso de la Sociedad Americana de Ingenieros (SAE) o la Organización Internacional para la Estandarización (ISO). Aun no disponiendo de toda la información deseada los objetivos de este proyecto son bastante ambiciosos y se pueden listar como sigue: Conseguir una comunicación estable con cualquier centralita electrónica (ECU) de cualquier vehículo equipado con OBD-II. Conseguir desarrollar una aplicación portable a cualquier sistema operativo y plataforma utilizando lenguaje JAVA y la estructura de programación por capas. 10

11 Realizar mejoras en el hardware ya existente en el mercado a partir del cual se construirá nuestra interface. Demostrar que con la información disponible en la red, es posible acceder a los sistemas de control que implementan los fabricantes de automóviles en sus vehículos Alcance del proyecto El alcance de este proyecto incluye la creación de un sistema que implementa una parte de las grandes posibilidades que ofrece el OBD-II, pudiéndose usar como una herramienta orientativa a la hora de diagnosticar una posible avería. Este sistema utiliza por un lado un modem interface que adecua las señales procedentes de la centralita electrónica que se encuentra en el vehículo (ECU), a las señales que necesita un puerto USB de cualquier ordenador. A partir de aquí, un software de control gestionara toda la información recibida. Muchos de los métodos de diagnostico existentes utilizan este planteamiento pero ninguno de ellos, por lo menos oficialmente, utiliza una aplicación desarrollada en JAVA que, por lo tanto, permita ejecutarse en la mayoría de los sistemas operativos existentes, incluyendo el famoso Linux y además en diferentes tipos de plataformas. Para desarrollar el hardware se utilizaran diseños de interfaces ya existentes a partir de los cuales se creará la que se utilizara en este proyecto, es decir, se recapitularan los esquemas eléctricos de los que se dispongan y sobre el PCB elegido se añadirán las posibles mejoras que pudieran aportar otros diseños. Esta parte del trabajo también conlleva la construcción y puesta en marcha de un programador de microcontroladores, necesario para implementar el firmware a partir del cual el micro utilizado en la interface funcionará. Po otro lado el software ha desarrollar tiene un papel igual o más importante, ya que para conseguir diseñar la aplicación de control sobre el modem interface, se necesitan realizar los primeros programas de prueba que servirán para constatar las bases del funcionamiento de la última y definitiva aplicación que interactuará con el modem. Este último programa constará de diferentes apartados y opciones en un entorno visual que mostrará los resultados de una forma fácilmente comprensible dejando así todo el proceso de cálculo en segundo plano. 11

12 1.5. Descripción general del proyecto En este proyecto como se ha ido comentado a lo largo de este documento se pretende elaborar un sistema capaz de comunicarse con la electrónica que gestiona cualquiera de los vehículos dotados con el estándar OBD-II, y para llevarlo acabo ha sido necesario trabajar sobre diferentes aspectos que están involucrados en el proceso de comunicación. Por tanto principalmente existen dos partes importantes a diferenciar en el desarrollo de este proyecto: La parte que engloba el hardware necesario, que nos es más que un modem interface que hace de intérprete entre la centralita electrónica del automóvil (ECU), y el puerto USB de un ordenador personal. La parte que engloba el software, que se refiere a la aplicación que funcionará en el PC y que gestionará el modem interface a partir de los datos que se vallan recibiendo y enviando atreves del puerto USB Descripción básica del hardware (Modem interface) Para diseñar el modem interface se recurrió a diseños ya existentes y de libre disposición en la red, con el fin de conseguir construir una interface que aportase las mejoras que de forma individual cada diseño implementa. Esta interface contiene como elemento principal un microcontrolador (PIC18F2550) que es el encargado de gestionar la comunicación entre los dos periféricos en cuestión, es decir, recoge la información que obtiene del puerto USB y la interpreta según el protocolo en que se esté comunicando con la ECU. Esto se debe a que el estándar OBD-II implementa 4 posibles protocolos en su capa física, SAEJ1850PWM, ISO 9141/14230, J1850 VPW, ISO (CAN). Para que el micro pueda realizar estas funciones se dispone además de un firmware que implementa las capacidades antes descritas, lo que lleva por tanto a realizar su grabación en el micro, y además a la construcción de un programador con el cual realizar este proceso. Otro aspecto importante a resaltar es la necesidad de construir un cable específico para realizar la conexión entre la ECU y la interface durante las primeras pruebas, ya que las centralitas electrónicas disponen de un conector exclusivo para este uso, y por tanto es muy difícil de encontrar en el mercado material compatible. 12

13 1.5.2 Descripción básica del software (Interface Visual) Para realizar la aplicación que gestionará el modem y todos los datos que serán enviados y recibidos a través de él, se deben realizar primero unos pasos previos para poder familiarizarse con las rutinas que deberemos utilizar. Como inicio de este proceso se debe comenzar por averiguar cuál es el mecanismo que siguen otras aplicaciones que ya implementan este mecanismo, y para poder hacerlo existe una aplicación, mencionada anteriormente (ScanTool), que ofrece el código fuente mediante lenguaje C++. A través de este código es posible extraer las rutinas básicas con las que se realiza la comunicación con el micro y la ECU, esto permite que nosotros mismos realicemos un programa de prueba con el que observar cual es la estructura básica que debemos seguir. Debido a que el objetivo es realizar el software utilizando JAVA, ya que nos permitirá hacer portable nuestro trabajo a diferentes plataformas, el programa anterior no es aun suficiente para poder afrontar la implementación de la aplicación definitiva, y por tanto es necesario realizar otro programa de prueba que contenga la misma estructura que el anterior pero con código JAVA. Para poder llevar a cabo este objetivo es necesario utilizar la librería RXTXcomm como librería nativa para realizar las comunicaciones por los puertos serie, ya que los medios que ofrece la API de Java respecto a este tipo de comunicaciones están obsoletos. Una vez sabemos utilizar los recursos existentes de Java, se puede empezar a desarrollar el software que nos ofrecerá las opciones y características que queremos implementar en la aplicación definitiva. El objetivo es que el programa pueda permitirnos, a través de una interface visual, realizar las siguientes tareas: Opciones para poder configurar los parámetros del puerto serie según convenga. Opciones para poder seleccionar los protocolos de comunicación que sean necesarios según el vehículo. Realizar lectura de códigos de error que pueda tener almacenados la centralita electrónica del automóvil. Realizar lecturas a tiempo real de los datos que aportan los diferentes sensores del motor del vehículo, rpm, velocidad, carga del motor, etc. Disponer de una consola de texto que monitoree el puerto serie refrescando su contenido según el estado del tráfico de datos entre el PC y el modem interface. 13

14 2. Diseños 2.1. Metodología utilizada Durante el desarrollo de este proyecto se ha seguido en parte la filosofía de la ingeniería inversa para alcanzar algunos de los objetivos, aunque también se han seguido las pautas de diseños anteriores de disponibilidad libre que realizan las mismas funciones, ya que encontrar cual es el camino que se sigue para realizar los procesos adecuadamente en un sector tan cerrado tecnológicamente como el del automóvil puede llegar a ser muy desesperante. Este proyecto consta principalmente de un parte de software y otra de hardware. En lo que hace referencia a la parte física, es decir, el hardware, se ha utilizado un diseño de libre uso disponible en la red, a partir del cual se construye básicamente la interface. Este aparato también se comercializa actualmente con el nombre de ALLProAdapter por la empresa OBDDiag.net y es una versión compatible de otra interface llamada ELM327, que originalmente es utilizada por muchos software disponibles de pago, y del cual también se disponen de los diseños electrónicos, los cuales también se han aprovechado para realizar el diseño final de la circuitería del modem interface basado en el PIC18F2550. El primer paso ha sido comprobar que los programas que existen como antecedentes funcionen correctamente sobre el hardware montado. De esta manera se tiene la garantía de que el hardware (interface con PIC18F2550 con conexión USB), funciona correctamente y de que los programas en los que nos basaremos para la realización del proyecto son funcionales. De no ser así, podríamos basarnos en herramientas que no serian útiles. Una vez verificados estos puntos, el primer objetivo siempre ha sido conseguir efectuar algún tipo de comunicación con el dispositivo (PIC18F2550) desde el PC, ya que uno de los problemas comunes a todos los dispositivos de este tipo es conocer la forma de comunicarse desde el nivel más básico, es decir, constatar que el micro controlador reacciona o contesta de alguna manera delante de un estimulo producido mediante una línea de comunicaciones digital. Existe un software para el diagnostico de vehículos llamado ScanTool.net, que en una de sus versiones ofrece el código fuente, muy útil para el propósito de este proyecto. Este programa ha sido, para este proyecto, la base para poder iniciar la búsqueda de los pasos que se siguen a la hora de realizar una comunicación desde el PC hasta la centralita electrónica del vehículo, atreves del puerto de comunicaciones serie. 14

15 Además del software de control y el hardware a controlar hay que tener en cuenta que los microcontroladores necesitan un driver para que el sistema operativo que lo gestiona pueda controlarlo. Dado que el PIC18F2550 lo fabrica la compañía Microchip, se pensó en que posiblemente esta proporcionara su driver, y aunque así es, lo proporciona mediante la instalación de un paquete de herramientas llamado USB Framework package, el cual obliga a instalar además del driver muchas otras utilidades que en principio no son necesarias para este caso. La empresa que ofrece libremente la información para montar la interface, OBDDiag.net, también proporciona el driver que se necesita, en forma de fichero INF, y es suficiente para que Windows XP o Vista la detecte sin problemas. También se pudo averiguar que en otros sistemas operativos, como por ejemplo Linux, este microcontrolador está contemplado y en las mismas distribuciones de Linux ya se incorpora el driver necesario. Por tanto, después de montar la interface y verificar su funcionamiento mediante el software ya existente, se procedió a intentar una comunicación utilizando recursos propios, es decir, sin recurrir a la funcionalidad de los programas anteriores. Utilizando el código fuente antes mencionado, el cual se basa en C++, se diseño un programa de prueba que conseguía comunicarse de forma básica con el microcontrolador, pero que aportó mucha información para realizar el proyecto. Una vez lograda la comunicación se procedió a intentar obtener el mismo resultado pero utilizando la plataforma Java. Básicamente el programa de prueba en este caso tiene la misma estructura que en C++, pero utilizando los recursos de los que dispone Java. El paso más importante aquí fue encontrar que métodos utiliza Java para comunicarse con el puerto Serie, y aunque los que proporciona Sun Microsystems, empresa diseñadora de esta plataforma de programación, están obsoletos, no fue difícil encontrar otros actualizados y perfectamente compatibles con su máquina virtual. Esta funcionalidad la proporciona el paquete RXTXcomm junto con la instalación de la maquina virtual de Java. Como último objetivo se planteó realizar un software que ofreciese muchas más funcionalidades de configuración sobre la interface, utilizando un entorno grafico y mucho mas intuitivo. Este software engloba toda la capacidad de comunicación de los programas anteriores pero añadiendo todo el potencial que ofrece un entorno visual diseñado con java, lo cual dota al programa de muchas opciones de configuración y operatibilidad sobre la interface y por tanto sobre la centralita electrónica de cualquier vehículo, que, al fin y al cabo, es lo que se pretende controlar. 15

16 2.1 Recursos utilizados Para realizar este proyecto se han utilizado recursos de diferente tipo según si nos referimos a la parte de software o a la de hardware, pero siempre recurriendo como fuente principal de información a la que se dispone en la red. Para montar la interface se recurrió a la web OBDDiag.net, donde se describen todos los materiales, software, firmware del micro y diseño del PCB necesarios para construirla. Paralelamente también se sacó información de la web ELM Electronics, donde mediante los datasheet que ofrecen (ELM327DS.pdf y ELM320DS.pdf), describen como fabricar un interface para conectarse a la centralita electrónica (ECU) de cualquier vehículo utilizando los microcontroladores que ellos suministran. El datasheet ELM327DS, es el documento que expone todas las posibles ordenes y respuestas que se reciben y envían al modem interface ELM327 y por tanto también al microcontrolador que se utiliza en este proyecto, ya que este incorpora un firmware compatible que contiene la misma estructura básica que el original, el ELM327. En el siguiente listado se pueden ver todos los posibles comandos que el ELM327 implementa, y por tanto, aunque no todos los comandos que utiliza la interface utilizada en este proyecto: 16

17 17

18 A continuación podemos ver uno de los esquemas eléctricos que aporta ELM Electronics, utilizando su microcontrolador más famoso, el antes mencionado ELM327, el cual utilizan muchas interfaces del mercado, ya que es capaz de manejar y gestionar los protocolos de comunicación más utilizados en el estándar OBD-II: Detalle del esquema eléctrico de un intérprete de OBD a RS232 18

19 Para realizar el software de control se utilizo como base de inicio el software que proporciona la empresa ScanTool.net, la cual ofrece en una de sus versiones su código fuente. Este código fuente se trató con el tan extendido programa de desarrollo DEV-C++, y posteriormente también se desarrollaron con él los primeros diseños de prueba con los se empezó la comunicación con la interface. Una vez se empezó a programar utilizando la plataforma JAVA y su máquina virtual, la cual está disponible en la web de Sun Microsystems y se puede descargar mediante el paquete JDK 6 Update 13, se pasó a utilizar otra herramienta para programar con este lenguaje llamada Eclipse en su versión 3.2.2, y fue muy útil para desarrollar el entorno gráfico del que dispone el software de control que se ha creado en este proyecto. Un recurso muy importante también fue toda la información que se aporta en RXTX.org, donde se explica el funcionamiento de la librería RXTXcomm.jar, que es la que se utiliza en JAVA para manejar los puertos serie. En esta web se ofrecen claros ejemplos de cómo utilizar y configurar los métodos de los que se dispone, en especial haciendo hincapié en uno de ellos que será adjuntado en el anexo del proyecto. 19

20 Por otro lado para poder entender cómo funcionan los protocolos de comunicación que utiliza el estándar OBDII (On Borad Diagnostics II), se extrajo mucha información de la enciclopedia libre Wikipedia, donde en uno de sus documentos (OBD-II PIDs), explica cuales y como son los formatos de trama de datos que utiliza este estándar, además de documentos como (ASCII), que detalla las equivalencias del código ascii entre valores decimales y hexadecimal. Detalle de equivalencias código ASCII Detalle de la información aportada en el documento OBD PID s 20

21 2.3. Descripción del diseño del modem interface La primera parte del proyecto que se empezó a diseñar y construir es el modem interface que se utiliza como aparato para interconectar el PC con la centralita electrónica del vehículo. Este aparato consta de tres partes a diferenciar, el cable USB que comunica el PC con el modem, el cable OBD-II que comunica la centralita electrónica del vehículo con el modem y el modem propiamente dicho. En los cables no hubo ningún proceso de montaje, se podían comprar ya hechos, pero si se intento fabricar el del conector OBD-II, ya que es difícil encontrarlos en los comercios especializados, pero se acabó desechando por su poca durabilidad ya que después de unas pocas pruebas empezó a deteriorarse. Cable OBD-II a DB9 hembra Cable USB tipo A-B En la siguiente tabla se puede apreciar la correspondencia entre los pines del conector OBD-II y el DB9: OBD-II 16 PIN(Macho) DB9 PIN(Hembra) (J2850 BUS+) 2 7 (Chassis Ground) (Signal Ground) (CAN High J-2284) 6 3 (ISO K Line) 7 4 (J2850 BUS- ) 10 6 (CAN Low J-2284) 14 5 (ISO L Line) 15 8 (Battery Power)

22 Por tanto el trabajo importante aquí estaba en la fabricación del modem. Para poder construirlo se acudió a una tienda especializada donde disponían de todos los componentes electrónicos necesarios, los cuales se procedieron a instalar en el PCB creado a partir del siguiente layout de doble cara: 22

23 Este aparato contempla la posibilidad de utilizar 4 protocolos de comunicación distintos a nivel de capa física, ya que a lo largo de los años las diferentes centralitas electrónicas que montan los fabricantes de vehículos así lo han dispuesto, aunque a partir del año 2004, en Europa, la mayoría de fabricantes empezaron a implementar solo el protocolo CAN Bus. Cualquiera de los vehículos fabricados en EE.UU. a partir del 1996, fueron obligados a disponer de un puerto OBD2, y en Europa a partir del año 2001, también se obligo a implantar este tipo de conexión. La norma OBD2 comprende cuatro protocolos de comunicación distintos: ISO 9141/14230 J1850 PWM J1850 VPW ISO (CAN) VPW (Variable Pulse Width) fue originalmente introducido por General Motors, mientras que PWM (Pulse Width Modulation) pertenece al grupo Ford. ISO 9141 y la posterior encarnación ISO (AKA Keyword 2000) es el que la mayoría de vehículos europeos y asiáticos utilizaban. Todos los nuevos modelos a partir 2007/2008 sólo pueden implementar el protocolo CAN Bus. La siguiente imagen es la de un conector típico OBD2 de 16 pines instalado en cualquier vehículo: Según el protocolo de comunicación que utilice el vehículo los pines habilitados en el conector serán diferentes. El protocolo ISO 9141/14230 utiliza los pines 6 y 15, el protocolo J1850 PWM utiliza el 2 y el 10, el protocolo J1850 VPW utiliza solo el pin 2, y el protocolo ISO (CAN), el pin 6 y 14. Todos los protocolos utilizan como fuente de alimentación los pines 4 y 5 (masa chasis y masa señal respectivamente), y el pin 16 (+12V). 23

24 Para entender el funcionamiento interno del modem habría que empezar por describir las partes de las que se compone su circuitería. En la siguiente imagen se puede observar el esquema eléctrico de la interface: En el esquema se observa que el microcontrolador utilizado es el PIC18F2455, pero por dificultades a la hora de adquirirlo se optó por el PIC18F2550, que es perfectamente compatible además de aportar un poco mas de memoria. Este micro es el encargado de gestionar todo los componentes periféricos del circuito y de mantener la comunicación entre ellos, es decir, recibe la información procedente del puerto USB al que está conectado, la transfiere a los elementos del circuito que proceda y viceversa, ya que la comunicación es bidireccional. La parte del circuito que se ocupa de manejar el protocolo CAN BUS, son los integrados MCP2515 y MCP2551, el integrado MC33290 maneja el protocolo ISO9141/14230 junto con Q3, J1850 VPW está controlado por MC33390 y el par de Mosfets (Q2 P-channel y Q1 N-channel) controlan el bus J1850PWM junto un comparador interno del PIC18F2550 y las resistencias R4 y R5 que crean la señal diferencial de la entrada del PWM. 24

25 2.4 Descripción del diseño del programador JDM2 Después de la explicación anterior es obvio deducir que el elemento más importante aquí es el microcontrolador PIC18F2550, pero por si solo no tiene ninguna funcionalidad a no ser que se le introduzca el firmware adecuado, por esta razón se tuvo que construir exclusivamente para este fin un programador compatible con el protocolo ICSP (In-Circuit Serial Programming). Este tipo de programador, llamado JDM2, es muy famoso en la red ya que se construye con pocos componentes e implementa el estándar ICSP que es el que ofrece la empresa Microchip para poder introducir los firmwares en los microcontroladores que ellos fabrican. El esquema eléctrico del programador es de fácil adquisición en cualquier web de electrónica y se representa con el siguiente esquema: 25

26 El circuito se montó en una placa de baquelita específica para realizar prototipos, y se siguió el siguiente layout : Detalle del programador JDM2 en su parte superior Detalle del programador JDM2 en su parte inferior (lado soldadura) 26

27 Además del programador necesitamos poder conectarlo a una PC que disponga de puerto serie, ya que a través de este puerto se comunicará con el software que enviará el firmware al micro. La aplicación que se utilizó para programar el microcontrolador fue PICPgm Develop. Programer que es un software gratuito y de fácil manejo; solo hay que seleccionar el archivo que contenga el firmware y una vez cargado cliquear en la opción de gravado. Siguiendo el datasheet del microcontrolador se conectó al programador según el siguiente detalle: Los pines detallados en la imagen son los que utiliza el programador JDM2 y por tanto el estándar ICSP, para comunicarse con el PIC. Vemos que además de los pines de comunicación (MCLR, PGC y PGD), también utiliza el puerto serie para alimentarse mediante los pines 8 y 19 para masa, y el 20 para los +5 V necesarios. El pin 26 (PGM), no está implementado en el programador ya que este solo se utiliza en el caso que se realice una programación en modo Low- Voltage ICSP, y en este caso se realiza en modo High-Voltage ICSP. 27

28 La conexión realizada para proceder a programar el micro fue la siguiente: En la imagen podemos ver como el cableado procedente del programador está etiquetado con el nombre de los pines a los cuales debe ser conectado. Alrededor del micro hay un cable que puentea dos pines, esto se debe a que el microcontrolador necesita dos puntos de masa. Por otro lado vemos como el cable procedente del puerto serie está conectado en su el respectivo conector DB9. También vemos que el programador está dotado de un diodo led de color rojo, el cual es de suma utilidad a la hora de detectar alguna anomalía en el proceso de gravado. 28

29 2.5 Modificaciones del diseño del modem Una vez se había montado la interface y se procedió a comprobar su correcto funcionamiento con software ya existente, se observó que funcionaba correctamente en todos los vehículos chequeados los cuales utilizaban diferentes protocolos de comunicación, exceptuando uno de los casos que no se obtenía respuesta de su centralita electrónica. Se sospechó que posiblemente la interface no funcionaba correctamente y se procedió a analizar con un osciloscopio las señales que producía respecto al protocolo J1850PWM. Para realizar las mediciones se tuvo recurrir a un osciloscopio digital con una capacidad de muestro de hasta 1GHz, herramienta que aseguraba el visionado más que correcto de la señal, ya que además esta era de tipo no periódica y por tanto con un osciloscopio analógico es prácticamente imposible capturarla. El resultado fue el siguiente: Resultado de la trama enviada a través del pin 2 (BUS+) del conector OBD-II Resultado del trama enviada a través del pin 10 (BUS-) del conector OBD-II 29

30 Para entender el resultado de estas graficas es preciso hacer una descripción del comportamiento de la capa física del protocolo j1850pwm. Este protocolo dispone de dos líneas de comunicación, el BUS+ y BUS-, y se caracteriza por utilizar la modulación del ancho de pulso (PWM) como mecanismo de codificación de bits. El periodo de cada bit tiene una duración de 24 µs y su estado se expresa de la siguiente forma: Un bit=1, se representa con un estado activo de 8us dentro de un periodo. Un bit=0, se representa con un estado activo de 16us dentro de un periodo. El BUS+ está activo cuando toma el valor de 5v. El BUS- está activo cuando toma el valor de 0v. Por tanto se deduce que en estado de reposo el BUS+ se encuentra a 0 V y el BUS- a 5 V, a medida que se van enviando los bits los buses van cambiando de estado quedando siempre entre ellos con tensiones invertidas, lo que se traduce en un mecanismo de protección contra interferencias exteriores. Hecha esta explicación podemos darnos cuenta de que la gráfica que representa el BUS+ desvela un pequeño problema eléctrico, ya que mientras que el BUSreacciona rápidamente colocándose a 0 V, el BUS+ nunca llega a lograr los 5 V, quedándose siempre en los 4,4 V aproximadamente. Aunque este no sería un problema para realizar la comunicación satisfactoriamente según las especificaciones del protocolo SAEJ1850PWM, ya que se encuentra dentro de los márgenes eléctricos permitidos, se procedió a modificar la electrónica que se ocupa de implementar esta codificación. 30

31 En el esquema eléctrico observamos que los encargados de ajustar estas tensiones son los Mosfets Q1 y Q2 (Q2 P-channel y Q1 N-channel) junto con las resistencias R7 y R6. Partiendo de otro diseño disponible en la red que implementa el mismo protocolo, se cambiaron los Mosfets por transistores PNP y NPN (PNP->2N3906 y NPN->2N3904) y las resistencias R6 y R7 de 22kΩ por resistencias de 2K7 Ω. Además se incorporaron resistencias de protección a las bases de los transistores de 1KΩ. Por tanto la modificación resultaría según el siguiente esquema: 31

32 Debido a que se constató que el problema no venia causado por el hardware se empezó a investigar si podía venir dado por errores en las tramas enviadas. Según el estándar J1850 PWM el formato de trama es el siguiente: A partir de los documentos que explican las características de este protocolo se averiguo que las diferentes partes de la trama tienen las siguientes funciones: SOF: Start of frame Header Field: Son los encargados de especificar mediante 3 bytes los siguientes parámetros: El primer byte especifica el modo en que se van a comunicar la centralita con la interface, y según el documento SAE J2178 este byte de cabecera se denomina de tipo mapeado, eso significa que cada bit tiene un significado. Los 8 bit se identifican así: BIT ID P P P H K Y Z Z Los tres más significativos (7, 6 y 5) indican la prioridad del mensaje y puede tomar los siguientes valores: Bit 7 Bit 6 Bit Prioridad máxima Prioridad mínima 32

33 El bit 4 (H) indica si la cabecera es de 3 bytes o uno: H=0 Tres bytes H=1 Un byte El bit 3 (K) indica si se utiliza "In-Frame response"? : K=0 Requerido K=1 No requerido El bit 2 (Y) indica si la dirección usada es física o funcional: Y=0 Funcional Y=1 Física Los bit 0 y 1 (Z, Z) se usan junto con K e Y para definir el tipo de mensaje: Msg. KKYZ Respuesta(K) Dirección(Y) Tipo de mensaje Requerido Funcional Function Requerido Funcional Broadcast Requerido Funcional Function Query Requerido Funcional Function Read Requerido Física Nodo a Nodo Requerido Física Reservado-MFG Requerido Física Reservado-SAE No requerido Física Reservado-MFG No requerido Funcional Function Command/Status No requerido Funcional Funcion Request/Query No requerido Funcional FunctionExt.Command/Status No requerido Funcional Function Ext. Request/Query No requerido Física Nodo a Nodo No requerido Física Reservado-MFG No requerido Física No disponible No requerido Física Reservado-MFG 33

34 El segundo byte representa a la dirección de memoria elegida que identifica a la centralita (ECU). El tercer byte representa a la dirección de memoria elegida que identifica a la interface o herramienta de chequeo. Data Field: Es la información que se quiere hacer llegar al micro de la ECU. CRC: Chequeo de redundancia cíclica de la trama. Conociendo ya la estructura de este protocolo se pensó que una solución al problema sería modificar los Header Field ya que posiblemente no serian los adecuados. A partir de aquí se procedió a averiguar cuáles eran los que utilizaba nuestra interface, y esto se consiguió mediante el comando ATH1, el cual le indica al modem que muestre las cabeceras (Headers) de todas las tramas, después observando una de las tramas se vio que la cabecera utilizada por defecto era 6A 61 F1. En el documento antes mencionado (J2178), se indicaba que esta cabecera es generalmente la más utilizada en muchas de las centralitas que implementan el protocolo J1850PWM, pero también hacía referencia a otra posible cabecera a utilizar, que era E4 10 F1. La cabecera 6A 61 F1 especifica el uso de 0x61 ( ) como primer byte que significa prioridad 3, tres bytes de cabecera, tipo de mensaje 2, usando dirección funcional que es el segundo byte de la cabecera, es decir, 0x6A. La cabecera E4 10 F1 especifica el uso de 0xE4 ( ) como primer byte que indica prioridad 7 (mínima), tres bytes de cabecera, tipo de mensaje 4, con dirección física y nodo a nodo. En principio para proceder a cambiar las cabeceras se dispone del comando ATSH, pero por causas aún desconocidas no era reconocido por nuestra interface, a pesar de que en el firmware del microcontrolador se vio que estaba implementado, mediante un software para editar ficheros de este tipo. Utilizando este mismo software (Hex Workshop Hex Editor), se intento averiguar donde se encontraban los bytes que definían las cabeceras en cuestión, y después de una búsqueda muy extensa se encontraron y modificaron con los nuevos valores. 34

35 En la siguiente captura podemos observar el fragmento de código donde se encontraban estos datos, fue un tarea laboriosa ya que este fichero solo contiene tramas hexadecimales, y es el resultado de la compilación de un código fuente al que no se tenía acceso. :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6E6A0E59 :103CB000EF6E020E0024E96E000E0120EA6E610E26 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Además de reemplazar estos bytes también se tuvo que recalcular el checksum de cada línea modificada ya que este cambiaba, y el resultado fue el siguiente: :103C E66EE66A BC6F000E0120CA :103C8000BD6FBCC0E6FFBDC0E6FF040E0024BE6FE2 :103C E0120BF6FBEC0E6FFBFC0E6FFDDEC37 :103CA0001EF046E90028E96E000E0120EA6EE40EBA :103CB000EF6E020E0024E96E000E0120EA6E100E77 :103CC000EF6E030E0024E96E000E0120EA6EF10E85 :103CD000EF6E EBC6F00EBE9FF01EBEAFFA2 :103CE000BC51EF2642E9E7CFD9FF1200D9CFE6FF5A Con el firmware ya modificado se procedió a volver reescribirlo en el microcontrolador utilizando el programador antes descrito. Una vez preparada la interface se volvió a intentar la comunicación con la centralita en cuestión que nos daba problemas. El resultado fue muy interesante ya que esta vez si nos contestó pero de la forma no esperada. La trama enviada fue la siguiente: E4 10 F A Y su respuesta: C4 F1 10 7F El dato a resaltar es el 7F 01, que indica respuesta negativa, es decir, según el documento J2178 una respuesta negativa significa que la centralita electrónica no dispone de información sobre el modo de trabajo requerido, que es el Modo

36 El estándar OBD-II contempla varios modos de trabajo, entre ellos el modo 01, modo 03, modo 07, modo 04, modo 09, modo 22 y bastantes más. Cada uno de ellos se ocupa de una parte de la información que puede aportar la ECU. El modo más extendido entre todas las centralitas es el modo 01. Cada modo además especifica sus parámetros PID (Parameter ID), en caso del modo 01 uno puede ser el parámetro 00, que es el que se utiliza en nuestro caso. Este parámetro sirve para decirle a la ECU que nos muestre cuales son los PID que pueden ser utilizados en este modo de entre los PID que se encuentran numerados del 1 al 20. Después de consultar nuevamente el documento J2178 se averiguó que cuando el modo 01 no está disponible en la centralita lo más probable es que se implementara en su lugar el modo 22. Este fue el final de la investigación ya que el modo 22 utiliza una longitud de trama más larga que el 01, cosa para la cual nuestro hardware (el microcontrolador de la interface), no está preparado, ya que no se implemento en su firmware esta funcionalidad. 36

37 2.6 Diseño de la aplicación de prueba en C++ Hasta ahora se ha explicado el diseño utilizado para crear la parte de hardware de la que se compone el proyecto, pero anteriormente se ha hecho referencia también a la parte de software que es la que tiene más peso y elaboración. El desarrollo del software se empezó a elaborar a partir del software libre ScanTool.net, que en una de sus versiones ofrece el código fuente. Utilizando la herramienta Dev-C++ y este código, el cual se basa en C++, se localizaron los métodos y funciones que se sospechaban eran los responsables de mantener la comunicación mediante el puerto serie. El primer paso fue averiguar cuál era la función que realizaba las operaciones necesarias para realizar las comunicaciones con el PIC. Tras encontrarla y incorporarla a un programa de prueba, se procedió a compilar la función, tras esto el mismo compilador mencionaba cuales eran las funciones y variables que llamaba este método para poder comunicarse, y por lo tanto poder buscarlas en el código anterior para reunirlas en el programa de prueba. Una vez que se tenían todas las funciones y variables en el mismo fichero se podía compilar el código sin obtener errores, averiguando así cómo se comportaba el hilo de ejecución. Después de saber cuál era la rutina de ejecución, se sacaron todas las órdenes o variables que no son imprescindibles por realizar una comunicación básica, dejando la clase reducida al máximo para tener una visión simple del proceso comunicación dejando a la vista claramente las funciones necesarias. Finalmente el programa de prueba podía realizar la comunicación enviando órdenes al PIC (atz, 0100, etc...) obteniendo los mensajes enviados y los recibos con una visualización por consola. A continuación aparece el código del programa de prueba: 37

38 38

39 Este programa utiliza la librería allegro como base, un librería muy utilizada para desarrollar videojuegos, y por tanto era necesario indicarle al compilador que la cargase con -lalleg, aunque también necesita cargar la librería iostream y la winalleg, necesaria si se trabaja en Windows. Las funciones implementadas son: main(): Arranca el hilo de ejecución. init(): Carga las librerías y abre el puerto. deinit(): Descarga las librerías y cierra el puerto. read_comport(): Lee el puerto serie. open_comport(): Abre el puerto serie. 39

40 close_commport(): Cierra el puerto serie. send_command(): Escribe en el puerto serie Diseño de la aplicación de prueba en JAVA El segundo diseño se centra en la elaboración de otro programa de prueba a partir de lenguaje JAVA, ya que era necesario averiguar las capacidades de este lenguaje a la hora de comunicarse con el puerto serie. Como primer apunte se ha de decir que se utilizó el IDE para programar en Java Eclipse. Para poder comunicarse con el puerto serie es necesario incluir las librerías adecuadas en el paquete de la API de java instalada en el PC, es decir, en el paquete autoinstalable JDK-JRE que ofrece gratuitamente Sun Microsystems, ya que este no incluye librerías con esta funcionalidad. Para este fin existe una librería llamada RXTXcomm, disponible en que mediante métodos nativos dota a Java de la capacidad para comunicarse con el puerto serie y paralelo, y además puede utilizarse en cualquier sistema operativo, haciendo hincapié en Windows, ya que aunque Sun ofrece una API para este fin (Javacomm), no da soporte para este sistema operativo, quedándose ya esta API obsoleta y aconsejando RXTXcomm. Descargando y descomprimiendo el zip donde se incluyen los ficheros necesarios de RXTX, debemos de copiar RXTXcomm.jar en la ruta c:\archivos de programa\java\jre\lib\ext, rxtxserial.dll y rxtxparallel.dll en c:\archivos de programa\java\jre\bin. Si en lugar de Windows nos encontramos en Linux las rutas donde situar los ficheros es diferente. En Linux debemos de copiar RXTXcomm.jar en /usr/lib/jvm/jre/lib/ext, los archivos librxtparallel.so y librxtxserial.so hay que copiarlos en /usr/lib/jvm/jre/lib/i386 si el sistema es de 32 bits. Con esto el compilador ya tendrá las librerías disponibles y podremos utilizarla en el código que programemos. RXTX.org dispone de una web donde se explica el funcionamiento de la librería y sus métodos, además ofrece ejemplos claros de cómo ponerla en marcha. 40

41 El programa de prueba que se elaboró en esta fase del proyecto fue el siguiente: import gnu.io.commportidentifier; import gnu.io.nosuchportexception; import gnu.io.portinuseexception; import gnu.io.serialport; import gnu.io.unsupportedcommoperationexception; import java.io.ioexception; import java.io.inputstream; import java.io.outputstream; import java.util.date; import java.util.enumeration; public class Principal { CommPortIdentifier idpuerto; String NombrePuerto; String ordre="atz"; String stringrebut; SerialPort port; OutputStream DadesEscriu; InputStream FluxDades; Date temps,temps2; StringBuffer respuesta; public Principal(){ public void conectar(){ int j=0; for(enumeration i=commportidentifier.getportidentifiers();i.hasmoreelements();){ idpuerto = (CommPortIdentifier) i.nextelement(); System.out.print(j++ +". " + idpuerto.getname()+"\n"); //Se examinan todos los puertos disponibles try { idpuerto.getportidentifier("com2"); port = ( SerialPort )idpuerto.open("visualobd",2000); port.setserialportparams(9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); //Se abre el puerto seleccionado catch (PortInUseException e) { e.printstacktrace(); System.out.println("Puerto en uso."); catch (NoSuchPortException e) { e.printstacktrace(); System.out.println(e); catch (UnsupportedCommOperationException e) { e.printstacktrace(); System.out.println(e); 41

42 public void enviar(){ temps=new Date(); int data; try { DadesEscriu = port.getoutputstream(); for(int i=0;i<ordre.length();i++){ data= ordre.codepointat(i); System.out.println(data); DadesEscriu.write(data);//Se escribe en el Puerto serie if((i+1) == ordre.length()){ DadesEscriu.write(13); //Solamente necessita el retorno de carro, //sin el salto de linea. System.out.println("Enviat atz:"); catch (IOException e) { e.printstacktrace(); System.out.println(e); public void recibir(){ respuesta=new StringBuffer(); while((timer()-temps.gettime())<3000){ char z; int reb=0; try { FluxDades = port.getinputstream(); while(reb>-1){ reb=fluxdades.read();//se lee el Puerto serie z=(char) reb; respuesta.append(z); System.out.println(respuesta);//Se imprime la respuesta por consola port.close(); catch (IOException e) { e.printstacktrace(); System.out.println(e); public static void main(string[] args) { Principal prin=new Principal(); prin.conectar(); prin.enviar(); prin.recibir(); public long timer(){ temps2 = new Date(); return temps2.gettime(); 42

43 Estructuralmente el programa se asemeja al diseño en C++, y por tanto implementa métodos funcionalmente muy parecidos: public static void main(): Método que inicia la ejecución del programa. public void Conectar(): Establece la conexión con el puerto serie indicado. public void Enviar(): Escribe la trama de datos a enviar en el puerto serie. public void recibir(): Lee la trama de datos recibida del puerto serie. Public long timer(): Método que realiza la espera necesaria a la respuesta del puerto. Tanto en JAVA como en C++, el tratamiento de las tramas digitales recibidas y enviadas en el puerto serie se traducen en valores decimales según el código ASCII, a partir de su equivalente en binario y posteriormente en hexadecimal. Unos ejemplos de trama de datos y su tratamiento sería el siguiente: Comando a enviar: atz -> equivalencia código ASCII: 97,116,122 Este comando sirve para hacer un reset del micro. Se le añade a la trama el retorno de carro para indicar fin de trama: atz\r ->código ASCII: 97,116,122,13 y el método write() de la clase SerialPort la envía al puerto serie. Trama recibida del puerto serie atreves del método read() de la clase SerialPort: 97,116,122,13,10,69,76,77,51,50,55,32,118,49,46,49,32,99,111,109,112, 97,116,105,98,108,101,13,10,62,-1 Equivalencia de la trama según el código ASCII: atz ELM327 v1.1 compatible El último número (-1), indica que no se está recibiendo ningún dato, y sirve como referencia para saber que la trama ha finalizado, además el micro marca el fin de la trama con el numero 62 ( equivalente a > ). 43

44 Comando a enviar: 01 0C -> equivalencia código ASCII: 48,49,48,67 Este comando sirve para pedirle a la centralita electrónica del vehículo (ECU), a cuantas revoluciones por minuto (rpm), está girando el motor. Se le añade a la trama el retorno de carro para indicar fin de trama: 01 0C\r ->código ASCII: 48,49,48,67,13 y el método write() de la clase SerialPort la envía al puerto serie. Posteriormente cuando la interface la ha recibido esta la envía a la ECU según el siguiente formato de trama si el protocolo a utilizar es J1850 PWM: SOF: Start Of Frame Header Field: 6A 61 F1 Data Field: 01 0C (Comando que se ha especificado antes) CRC: 0A EOF: End Of Frame La ECU contesta con la siguiente trama y la interface la recoge para enviarla al puerto serie: 6A F C 0B 88 0A -> Respuesta ECU 01 0C -> Respuesta 6A F C 0B 88 0A Interface Se puede observar que la interface le añade a la trama el comando solicitado Trama recibida del puerto serie atreves del método read() de la clase SerialPort: 48,49,48,67,13,10,54,65,70,49,54,49,52,49,48,67,48,66,56,56,48,65,13,1 0,62,-1 44

45 Por tanto en la respuesta obtenida podemos diferenciar que: 010C: Comando requerido 6A F1 61: Cabecera de la trama(especifica direcciones de memoria, prioridades, tipo de conexión, etc..) 410C: Confirmación de que se ha contestado al comando requerido sumando 40 a 01, quedando 410C. 0B 88: El dato que interesa para calcular las rpm. Según el documento OBD Pid s anteriormente mencionado, si pasamos a decimal estos valores quedando en 11 y 136, y aplicamos esta fórmula (( A 256) + B) ( ) = = 738, obtenemos las revoluciones por 4 4 minuto del motor a tiempo real. 0A: Chequeo de redundancia cíclica de la trama (CRC). 45

46 2.5. Diseño de la aplicación grafica diseñada en JAVA El diseño final y definitivo de este proyecto consistía en realizar un software multiplataforma diseñado mediante la conocida estructura de programación por capas, para poder unir de forma correcta toda la capacidad de comunicación que se había conseguido en los programas de prueba anteriores con la necesidad de ofrecer muchas más opciones, entorno grafico y el potencial que aporta un entorno visual diseñado con JAVA, lo cual dota al programa de muchas posibilidades de configuración y operatibilidad sobre la interface y por tanto sobre la centralita electrónica de cualquier vehículo. Este software intenta ser compatible con cualquier plataforma que disponga de una conexión USB o RS-232, de ahí su implementación mediante JAVA, pero debido a que para realizar las comunicaciones con dichos puertos se ha utilizado un librería nativa (RXTXcomm.jar), es posible que existan algunas incompatibilidades de un plataforma a otra, cosa que se debería consultar en la web de RXTXcomm. Básicamente el programa ofrece cinco apartados bien diferenciados: La pantalla principal de inicio: Es la ventana que vemos cuando inicia el programa, en ella realizamos y vemos las operaciones principales, como son realizar la conexión/desconexión con la interface y siempre viendo en una consola de texto los datos que se están enviando y recibiendo a tiempo real. La opción de configuración del puerto: En esta sección del programa podemos configurar todos los parámetros necesarios del puerto serie, para poder realizar una conexión. La opción de selección del protocolo de comunicación: Esta funcionalidad del programa permite que el usuario pueda elegir manualmente el protocolo con el que se quiere comunicar con la ECU de su vehículo. La opción de Lectura de códigos de error: Esta opción ofrece la posibilidad de poder averiguar si nuestro vehículo ha sufrido o sufre algún fallo técnico, a través de la obtención de un código identificativo que especifica la avería y que proporciona la ECU. La opción de mediciones a tiempo real: Esta parte del programa proporciona información de los diferentes sensores de los que dispone el motor de nuestro vehículo, mostrando datos como la temperatura, velocidad, revoluciones por minuto, cantidad de aire absorbido, etc. 46

47 Para realizar el software se utilizó la estructura de programación por capas: capa de datos, capa de dominio y capa de presentación. Cada capa tiene una función dentro del programa y una serie de clases que cumplen con la función que se les ha asignado. A continuación se explica la función y clases que contiene cada capa: 1. Capa de Datos: Es la encargada de gestionar todas las tramas de datos que se intercambian la computadora y la interface. Su objetivo es recoger ya sean datos recibidos o enviados, adecuarlos y tratarlos para poder o bien mandárselos a la interface a través del puerto serie o recibirlos y mandárselos a las capas superiores. En esta capa podemos encontrar las siguientes clases: Clase Conexión: Es la encargada de encapsular todos los atributos de los que se compone una conexión que se realiza atreves del puerto serie: velocidad, databits, stopbits, paridad, nombrepuerto, protocolo. Clase ControladorConexión: Contiene todos los métodos necesarios para realizar la conexión, contiene mucha de la estructura conseguida en los programas de prueba. Clase lecturatxterrores: Clase que permite acceder a archivos de tipo TXT, con el objetivo de que el programa disponga de una memoria permanente. Alguna de las funcionalidades de las que dispone el software necesita cotejar la información que recibe con la que dispone para poder reconocerla, como es el caso de la lectura de los códigos de error. Clase MuestraIDs: Captura los identificadores de trama del protocolo CAN Bus. 2. Capa de Dominio: Es la encargada de hacer de intermediario entre la capa de datos y la inmediatamente superior a la de dominio, que en este caso es la de presentación. Ofrece la capacidad de trabajo de la capa de datos, de una forma mucho más accesible para sus capas superiores. En esta capa encontramos la clase ControladorDominioConexión, la cual contiene todos los métodos necesarios para manejar todas las clases que se encuentran en la capa de datos. 47

48 Capa de Presentación: Esta capa se encarga de gestionar toda la parte visual del programa y contiene todas las clases y controladores necesarios para poder llevar a cabo esta tarea. Concretamente estas son las clases que contiene: ControladorPrincipal y VistaPrincipal: Gestionan la carga de todas las demás clases de la capa de presentación y proporcionan las operaciones básicas del programa, como son poder iniciar o detener un conexión con la interface y seleccionar las diferentes opciones del programa. ControladorErrores y VistaCodigosError: Estas clases se ocupan de gestionar la presentación en pantalla de los códigos de error proporcionados por la ECU. ControladorMediciones y VistaMediciones: Se ocupan de gestionar la presentación en pantalla de los datos referentes a valores que proporcionan los sensores del vehículo, tales como temperatura, velocidad, revoluciones por minuto, cantidad de aire absorbido, etc. ControladorProtocolo y VistaProtocolo: Gestionan la presentación en pantalla de las opciones disponibles a la hora de seleccionar un protocolo de comunicación. ControladorPSerie y VistaConfiguración: Presentan en pantalla todas las opciones que requiere el puerto serie para ser configurado. Además permiten realizar una búsqueda de estos. Por lo extenso del código de este último programa, se incorporará al final del proyecto como documento adjunto. En esta aplicación la clase más importante y difícil de desarrollar es la clase ControladorConexion, ya que es la que capacita al software de la capacidad de utilizar varios hilos de ejecución. Esta clase implementa la interface Runnable con su respectivo método Run(), el cual está en permanente escucha a los mensajes que se envían desde el puerto serie, y por tanto permite liberar al hilo principal para poder realizar otras funciones simultáneamente. Otra de las clases que implementa un nuevo hilo de ejecución es la clase ControladorMediciones, la cual se encarga de mostrar los datos de la lectura a tiempo real de los diferentes sensores de los que dispone la centralita en el vehículo. Por tanto en la aplicación trabajan 3 hilos de ejecución: Hilo principal: Se mantiene a la espera para realizar las funciones que reclame el usuario. Hilo de la clase ControladorConexion: Escucha permanentemente el puerto serie consiguiendo así no perder ningún posible dato y una velocidad de respuesta mucho más alta. Hilo de la clase ControladorMediciones: Refresca constantemente en pantalla los datos que va recibiendo el método run() de la clase ControladorConexión. 48

49 Cuando se procedió a probar el software sobre diferentes sistemas operativos con la intención de asegurar su funcionalidad, ventaja que tiene JAVA sobre otros lenguajes ya que utiliza una maquina virtual, se observó que en Windows funcionaba correctamente ya que sobre este se había realizado la programación, pero sobre Linux se obtuvo un resultado inesperado. Se observó que en Linux el programa arrancaba y funcionaba de forma correcta, pero en el momento que se procedía a desconectarlo del puerto serie el programa quedaba totalmente bloqueado. Después de muchas pruebas se averiguó que las librerías nativas RXTXcomm.jar que utiliza esta aplicación se comportaban de diferente forma según el sistema operativo en el que estuviéramos trabajando. El problema se encontraba en el método run() de la clase ControladorConexión(), ya que este utiliza la clase SerialPort constantemente para escuchar el puerto serie. Observando el siguiente fragmento de código podemos hacernos una idea de la situación: public void run(){ boolean datos=false; String tramarecibida; Thread thisthread = Thread.currentThread(); while(hilo == thisthread){ char z; int longitudtrama=0; int reb=0; try { datosrecibidos = port.getinputstream(); while((reb=datosrecibidos.read())>-1){ z=(char) reb; if(reb==62){ break; if(reb!=-1){ tramarecibidainicial.append(z); DestruirHilo=true; catch (IOException e1) { estado("no response."); Vemos que la línea subrayada, datosrecibidos.read(), es la orden que se encarga de acceder al puerto y cuando el hilo de ejecución llega a ella en Windows la lee una vez y sigue su transcurso dentro del método run() hasta el siguiente ciclo de bucle donde lo volvería a leer, pero en Linux no sucede los mismo, el hilo de ejecución se detiene en esta línea esperando un nuevo mensaje del puerto y por tanto bloqueando su posible cierre desde el hilo principal, es decir, como el hilo que se ejecuta en run() nunca libera al objeto port, cuando accedemos al mismo objeto desde el hilo principal de la clase este provoca un bloqueo de la aplicación ya que nunca tendrá permiso para cerrarlo. Esto se solucionó enviando un mensaje cualquiera al puerto y cambiando en el mismo instante la condición del bucle while (hilo=null), para que el hilo de run() saliese de su estado de escucha y acabara extinguiéndose ya que la condición del bucle ya no se cumplía. 49

50 Como aporte final a esta aplicación se procedió a empaquetarla en un archivo.jar, lo que facilita mucho su puesta en marcha y portabilidad a cualquier otra plataforma o sistema operativo. Pero uno de los inconvenientes que presentaba esta aplicación era que para poder comunicarse con los puertos de comunicación necesitaba la librería nativa RXTXcomm, y por tanto, esta no viene incluida en las librerías de la maquina virtual que se instala por defecto, lo que obliga a tener que instalarla manualmente. Para cualquier persona que esté familiarizada con la programación no resulta ser un problema, pero si para alguien que solo quiera hacer unas cuantas pruebas. La solución fue crear una carpeta donde se introduciría el archivo JAR, los archivos adjuntos necesarios como los JPG y TXT, y otra carpeta donde incluiríamos la librería nativa RXTXcomm. Además de lo anterior se crearon dos archivos ejecutables (RunLinux.sh y RunWindows.bat), que se utilizan según en el sistema operativo en el que estemos. La carpeta se llama VisualOBDJar y contiene los siguientes archivos: VisualOBD.jar: Archivo comprimido que contiene todo el código de la aplicación. RunLinux.sh: Archivo ejecutable para Linux. RunWindows.bat: Archivo ejecutable para Windows. VisualOBD4_1 y AboutVisualOBD: Archivos de tipo JPG. CodigodErrores.txt: Archivo de texto utilizado como base de datos. Leeme.txt: Archivo de texto que contiene una breve explicación de cómo arrancar el software. lib: Carpeta que contiene la librería nativa RXTXcomm con los respectivos archivos rxtxparallel.dll, rxtxserial.dll, librxtxserial.so, y librxtxparallel.so necesarios para realizar su carga en el sistema operativo través de la máquina virtual. 50

51 Para poder realizar la carga de la librería nativa correctamente se tuvo que modificar el archivo MANIFEST que contiene el paquete VisualOBD.jar quedando de la siguiente forma: Y a los archivos RunWindows.bat y RunLinux.sh se les introdujo los siguientes comandos: 51

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL SUBDIRECCIÓN GENERAL DE RECAUDACIÓN PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL INDICE 1 INTRODUCCIÓN...

Más detalles

Sensor de Temperatura utilizando el Starter Kit Javelin Stamp. Realizado por: Bertha Palomeque A. Rodrigo Barzola J.

Sensor de Temperatura utilizando el Starter Kit Javelin Stamp. Realizado por: Bertha Palomeque A. Rodrigo Barzola J. Sensor de Temperatura utilizando el Starter Kit Javelin Stamp Realizado por: Bertha Palomeque A. Rodrigo Barzola J. INTRODUCCION DIFERENCIAS EJEMPLOS JAVA Orientado a Objetos Multiplataforma Programar

Más detalles

5.2 Plataforma de Desarrollo Para la Interfaz de Usuario

5.2 Plataforma de Desarrollo Para la Interfaz de Usuario 5.1 Introducción Para la comunicación entre SATEDU y su estación terrena se necesita ajustar ciertos parámetros de comunicación de la Tarjeta de Comunicaciones como la tasa de transmisión, el número de

Más detalles

Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876.

Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876. Ic-Prog PARA PROGRAMAR MICROCONTROLADORES PIC 16F84 y 16F876. Prof: Bolaños D. En unión del hardware adecuado, el software IC-PROG permite programar gran cantidad de dispositivos electrónicos. Esta guía

Más detalles

Anexo B. Comunicaciones entre mc y PC

Anexo B. Comunicaciones entre mc y PC Anexo B Comunicaciones entre mc y PC En este apartado se hará hincapié en los comandos para el manejo del módulo de comunicaciones desde el PC. Conociendo estos comando se podrá realizar una aplicación

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE MONITOREO DE AUTOMÓVILES EMPLEANDO EL ESTANDAR OBD-II

DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE MONITOREO DE AUTOMÓVILES EMPLEANDO EL ESTANDAR OBD-II DISEÑO E IMPLEMENTACIÓN DE UN PROTOTIPO DE MONITOREO DE AUTOMÓVILES EMPLEANDO EL ESTANDAR OBD-II María Fernanda Caizatoa Chulca, Ximena del Rosario Méndez Flores Resumen La construcción del prototipo da

Más detalles

UNIVERSIDAD DEL PAIS VASCO - EUSKAL HERRIKO UNIBERTSITATEA

UNIVERSIDAD DEL PAIS VASCO - EUSKAL HERRIKO UNIBERTSITATEA DEPARTAMENTO DE ELECTRONICA Y TELECOMUNICACIONES ESCUELA UNIVERSITARIA DE INGENIERIA VITORIA GASTEIZ UNIVERSIDAD DEL PAIS VASCO EUSKAL HERRIKO UNIBERTSITATEA Ampliación de Sistemas Digitales Manual de

Más detalles

T3-Rondas V 1.1. Help-Pc, S.L. C/ Pintor Pau Roig, 39 L-5 08330 Premià de Mar Barcelona Tel. (93) 754 90 19 Fax 93 752 35 18 marketing@t2app.

T3-Rondas V 1.1. Help-Pc, S.L. C/ Pintor Pau Roig, 39 L-5 08330 Premià de Mar Barcelona Tel. (93) 754 90 19 Fax 93 752 35 18 marketing@t2app. T3-Rondas V 1.1 1 Indice 1 Requisitos mínimos 3 2 Instalación 3 2.1 Instalación del software 3 2.2 Instalación del terminal 4 3 Configuración Inicial 4 3.1 Crear terminales 5 3.2 Crear puntos de lectura

Más detalles

Arquitectura de Redes y Sistemas de Telecomunicación

Arquitectura de Redes y Sistemas de Telecomunicación Práctica 0 Arquitectura de Redes y Sistemas de Telecomunicación Introducción al Wireshark Fundamentos del analizador de protocolos Wireshark. Objetivos En esta introducción se pretenden adquirir las capacidades

Más detalles

Error! Nombre desconocido de propiedad de documento.

Error! Nombre desconocido de propiedad de documento. MANUAL USUARIO COLABORA WEB INDICE 1 IInttrroducccci ión... 3 1.1 Objetivos... 3 1.2 Qué es COLABORA?... 3 1.3 Acceso a la aplicación... 3 2 Prroccesso de Gesstti ión de Entti idadess COLLABORA... 5 2.1

Más detalles

CEADENSoft Visual DataLogger 1.0

CEADENSoft Visual DataLogger 1.0 CENTRO DE APLICACIONES TECNOLÓGICAS Y DESARROLLO NUCLEAR CEADENSoft Visual DataLogger 1.0 Software de aplicación para datalogger DL-1a Índice 1 - Introducción...1 2 - Requerimientos....1 3 - Instalación

Más detalles

Utilización de los puertos serial y paralelo de una PC usando LabView

Utilización de los puertos serial y paralelo de una PC usando LabView Universidad del Táchira Departamento de Ingeniería Electrónica Instrumentación Electrónica Utilización de los puertos serial y paralelo de una PC usando LabView Hecho Por: Ing. Rafael Chacón Ing. José

Más detalles

Traslado de Copias y Presentación de Escritos. Manual de Usuario V.3.1

Traslado de Copias y Presentación de Escritos. Manual de Usuario V.3.1 Traslado de Copias y Presentación de Escritos Manual de Usuario V.3.1 Página: 2 45 INDICE INTRODUCCIÓN... 3 1 ACCESO A LA APLICACIÓN... 3 2 PROCESO DE FIRMA... 4 3 TRASLADOS PENDIENTES DE ACEPTAR POR EL

Más detalles

Guía de Usuario Programador USB

Guía de Usuario Programador USB Guía de Usuario Programador USB Tecnología Digital del Bajío Av. Vicente Guerrero 1003, Int. A Irapuato, Gto. Mex. C.P. 36690 Teléfono: (462) 145 35 22 www.tecdigitaldelbajio.com i Guía de Usuario, Programador

Más detalles

INSTRUMENTACIÓN AVANZADA Departamento de Ingeniería Eléctrica y Electromecánica Facultad de Ingeniería Universidad Nacional de Mar del Plata

INSTRUMENTACIÓN AVANZADA Departamento de Ingeniería Eléctrica y Electromecánica Facultad de Ingeniería Universidad Nacional de Mar del Plata Problema a resolver Ejercicio 2.1 Tomando el ejercicio 1.4 realizar los ajustes necesarios para que además de encenderse un LED en pantalla se encienda un LED físicamente sobre la placa PIC suministrada

Más detalles

Módulo 1 El lenguaje Java

Módulo 1 El lenguaje Java Módulo 1 El lenguaje 1.1 Presentación de es un lenguaje de programación desarrollado por la empresa Sun Microsystems en 1991 como parte de un proyecto secreto de investigación llamado Green Proyect, con

Más detalles

TARJETA ETHERNET Y PROTOCOLO TCP/IP

TARJETA ETHERNET Y PROTOCOLO TCP/IP TARJETA ETHERNET Y PROTOCOLO TCP/IP ÍNDICE 1 Introducción 5 3 Instalación para Windows 98 y 98 SE 11 2 Preinstalación de la tarjeta ethernet 7 2.1 Descripción de la tarjeta ethernet para Bus PCI y con

Más detalles

Generalidades Computacionales

Generalidades Computacionales Capítulo 2 Generalidades Computacionales 2.1. Introducción a los Computadores Definición: Un computador es un dispositivo electrónico que puede transmitir, almacenar, recuperar y procesar información (datos).

Más detalles

Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales

Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales Proyecto PLUMA Plataforma Universal Microcontrolada Aplicaciones didácticas e industriales INS LA GARROTXA PEB12: TONI MORENO ÍNDEX: 1. INTRODUCCIÓN... 3 1.1 VISIÓN ARTIFICIAL... 3 1.2 INTERFACE PLUMABOT-PICAXE...

Más detalles

INSTRUCCIONES DE ACTUALIZACION LEOTEC ARGON A150B ( Sistemas W7 y W8)

INSTRUCCIONES DE ACTUALIZACION LEOTEC ARGON A150B ( Sistemas W7 y W8) INSTRUCCIONES DE ACTUALIZACION LEOTEC ARGON A150B ( Sistemas W7 y W8) Este proceso nos permitirá actualizar nuestro Smartphone LEOTEC ARGON A150B con la nueva revisión de sistema disponible en la web www.leotec.com.

Más detalles

Básico de Arquitectura del Computador. Ing. Irvin Cuervo

Básico de Arquitectura del Computador. Ing. Irvin Cuervo Básico de Arquitectura del Computador El Computador Hardware Software El Computador Qué es y qué hace un computador? Un computador es básicamente una máquina cuya función principal es procesar información.

Más detalles

Firmar Solicitud. Manual de usuario

Firmar Solicitud. Manual de usuario Firmar Solicitud Manual de usuario Madrid, Marzo de 2014 ÍNDICE 1. INTRODUCCIÓN... 3 2. PANTALLAS... 4 2.1. Login... 4 2.2. Ayuda... 4 2.3. Pantalla de Solicitudes de Registro... 5 2.4. Listado de documentos

Más detalles

MANUAL DE INSTALACIÓN

MANUAL DE INSTALACIÓN CADUSB y Programas de Microsoft Excel para lectores de presiómetro ELx MANUAL DE INSTALACIÓN Versión 1.0 - Rev 1 Fecha de Revisión: Abril 2011 Versión 1.0 Rev 1 - Abril 2011 TABLA DE CONTENIDOS INFORMACIÓN

Más detalles

APLICACIÓN DE ACCESO REMOTO PARA POCKET PC. MANUAL DE USUARIO (Release 1.42)

APLICACIÓN DE ACCESO REMOTO PARA POCKET PC. MANUAL DE USUARIO (Release 1.42) APLICACIÓN DE ACCESO REMOTO PARA POCKET PC MANUAL DE USUARIO () Índice INTRODUCCIÓN... 3 MANUAL INSTALACIÓN DEL SOFTWARE... 4 GUIA USUARIO... 5 Iniciar la Aplicación Control Remoto... 5 Bienvenido... 5

Más detalles

NOTIFICACIÓN DE INCIDENCIAS RELACIONADAS CON MEDICAMENTOS DE USO HUMANO GUÍA PARA LA PRESENTACIÓN DE NOTIFICACIONES

NOTIFICACIÓN DE INCIDENCIAS RELACIONADAS CON MEDICAMENTOS DE USO HUMANO GUÍA PARA LA PRESENTACIÓN DE NOTIFICACIONES NOTIFICACIÓN DE INCIDENCIAS RELACIONADAS CON MEDICAMENTOS DE USO HUMANO GUÍA PARA LA PRESENTACIÓN DE NOTIFICACIONES Versión: 18/01/2010 V1.0- - 1 ÍNDICE 1 Descripción general de la presentación de NOTIFICACIONES...

Más detalles

GESTOR DE DESCARGAS. Índice de contenido

GESTOR DE DESCARGAS. Índice de contenido GESTOR DE DESCARGAS Índice de contenido 1. Qué es DocumentosOnLine.net?...2 2. Qué es el Gestor de Descargas?...3 3.Instalación / Configuración...5 4.Descarga de Documentos...9 5.Búsqueda / Consulta de

Más detalles

Router ADSL Libertad en una caja

Router ADSL Libertad en una caja Router ADSL Libertad en una caja Guía de la tarjeta Ethernet y protocolo TCP/IP 1 Índice 1. Introducción 3 2. Preinstalación de la tarjeta Ethernet 4 2.1 Descripción de la tarjeta Ethernet para bus PCI

Más detalles

GE Power Management GE_LOCAL. Software de Comunicación. Instrucciones GEK 105568C

GE Power Management GE_LOCAL. Software de Comunicación. Instrucciones GEK 105568C GE Power Management Software de Comunicación GE_LOCAL Instrucciones GEK 105568C ,1',&( 1. INSTALACIÓN...3 1.1. REQUERIMIENTOS DEL SISTEMA...3 1.2. INSTALACIÓN DEL PROGRAMA...3 1.2.1. Instalación con disquetes....3

Más detalles

Comunicación NS12 y 3G3MV a través del GateWay

Comunicación NS12 y 3G3MV a través del GateWay Informe Técnico Comunicación Guía entre Rápida NS12 y 3G3MV a través del GateWay 1. Introducción 2. GateWay 3. Conexiones 4. Parametrizaje 3G3MV 5. Software GateWay 6. Configuración del NS 7. Uso de la

Más detalles

Centro Universitario de Ciencias Exactas e Ingenierías DIVISION DE ELECTRONICA Y COMPUTACION

Centro Universitario de Ciencias Exactas e Ingenierías DIVISION DE ELECTRONICA Y COMPUTACION SISTEMA DE MONITOREO POR INTERNET CON ENVÍO DE IMÁGENES Ricardo Hernández Durán (Ingeniería en Comunicaciones y Electrónica) Gabriela Ramos Rosas (Licenciatura en Informática) Víctor Jiménez García (Ingeniería

Más detalles

SIMULADOR DE SISTEMAS DE EVENTOS DISCRETOS

SIMULADOR DE SISTEMAS DE EVENTOS DISCRETOS SIMULADOR DE SISTEMAS DE EVENTOS DISCRETOS MANUAL DE USUARIO 1.1 Introducción. El simulador de sistemas de eventos discretos está compuesto por dos aplicaciones: el Simulador de redes de Petri y el Simulador

Más detalles

ZKTime Monitor : Programa de Control de Presencia y/o Accesos.

ZKTime Monitor : Programa de Control de Presencia y/o Accesos. ZKTime Monitor : Programa de Control de Presencia y/o Accesos. ZKTime Monitor es una Aplicación Informática que controla los Bonos de Accesos en una Empresa. El sistema consta del Software y Terminales

Más detalles

Guía de Usuario Convertidor USB-Serial

Guía de Usuario Convertidor USB-Serial Guía de Usuario Convertidor USB-Serial Tecnología Digital del Bajío Av. Vicente Guerrero 1003 Irapuato, Gto. Mex. C.P. 36690 Teléfono: (462) 145 35 22 www.tecdigitaldelbajio.com ventas@tecdigitaldelbajio.com

Más detalles

ACTUALIZACION MANUAL: MODO OFFLINE (Ejemplo: WINDOWS 7-32 bits):

ACTUALIZACION MANUAL: MODO OFFLINE (Ejemplo: WINDOWS 7-32 bits): ACTUALIZACION MANUAL: MODO OFFLINE (Ejemplo: WINDOWS 7-32 bits): Si el cliente no dispone de conexión a internet en el ordenador conectado a la TRS 5000 EVO, se puede dar de alta en la web de JMA, siempre

Más detalles

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes 1 Objetivos Ingeniería Técnica Informática de Sistemas Curso 2003/2004 En la presente sesión se pretende familiarizar al alumno

Más detalles

U.T.4.EL ENTORNO DE DESARROLLO

U.T.4.EL ENTORNO DE DESARROLLO U.T.4.EL ENTORNO DE DESARROLLO Lenguaje Java Estamos en unos días en los que cada vez más la informática invade más campos de nuestra vida, estando el ciudadano medio cada vez más familiarizado con términos

Más detalles

PROCESO DE SIMULACIÓN EN PROTEUS

PROCESO DE SIMULACIÓN EN PROTEUS USB PROCESO DE SIMULACIÓN EN PROTEUS Departamento de Electrónica Fundación San Valero Microchip PIC18F4550 1 Microchip Firmware PIC18F4550 La velocidad de transferencia a ido aumentando rápidamente a lo

Más detalles

Windows XP Instalación y configuración de hardware

Windows XP Instalación y configuración de hardware Servicio de Informática Atención al Usuario Windows XP Instalación y configuración de hardware Sección de Atención al Usuario Ultima modificación: 01 de Julio de 2.003 Instalación y configuración de hardware

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 2: Servicios Básicos. Enrutamiento

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 2: Servicios Básicos. Enrutamiento Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows Módulo 2: Servicios Básicos. Enrutamiento Aulas en red. Aplicaciones y servicios. Windows Enrutamiento El Servicio de Enrutamiento y Acceso

Más detalles

MANUAL DE AYUDA. SAT Móvil (Movilidad del Servicio Técnico)

MANUAL DE AYUDA. SAT Móvil (Movilidad del Servicio Técnico) MANUAL DE AYUDA SAT Móvil (Movilidad del Servicio Técnico) Fecha última revisión: Abril 2015 INDICE DE CONTENIDOS INTRODUCCION SAT Móvil... 3 CONFIGURACIONES PREVIAS EN GOTELGEST.NET... 4 1. INSTALACIÓN

Más detalles

ACTUALIZACION AUTOMATICA: MODO ONLINE (Ejemplo: WINDOWS 7-32 bits):

ACTUALIZACION AUTOMATICA: MODO ONLINE (Ejemplo: WINDOWS 7-32 bits): ACTUALIZACION AUTOMATICA: MODO ONLINE (Ejemplo: WINDOWS 7-32 bits): Una vez se haya instalado el software de PC de la TRS5000, se arranca el programa bien automáticamente desde el propio instalador (launch

Más detalles

Redes de área local en centros educativos. Windows

Redes de área local en centros educativos. Windows Ministerio de Educación Redes de área local en centros educativos. Windows Módulo 6: W7-Gestión de imágenes Instituto de Tecnologías Educativas 2011 En este apartado nos centraremos en la gestión de la

Más detalles

CÓMO CONECTARNOS A INTERNET

CÓMO CONECTARNOS A INTERNET CÓMO CONECTARNOS A INTERNET Podemos conectarnos a la Red partiendo de dos posibilidades: Si nuestro ordenador forma parte de una red local, es decir, está conectado a otros ordenadores por un cable y dicha

Más detalles

Desarrollo de una interfaz RS-232 para el manejo de un coche de radiocontrol desde el PC

Desarrollo de una interfaz RS-232 para el manejo de un coche de radiocontrol desde el PC Desarrollo de una interfaz RS-232 para el manejo de un coche de radiocontrol desde el PC A. Muñoz, A. Millan, P. Ruiz-de-Clavijo, J. Viejo, E. Ostua, D. Guerrero Grupo ID2 (Investigación y Desarrollo Digital).

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

ANÁLISIS Y APLICACIÓN INFORMÁTICA PARA IMPLEMENTACIÓN SOBRE PLC DE SISTEMAS AUTOMÁTICOS DESARROLLADOS CON HERRAMIENTAS DE ALTO NIVEL

ANÁLISIS Y APLICACIÓN INFORMÁTICA PARA IMPLEMENTACIÓN SOBRE PLC DE SISTEMAS AUTOMÁTICOS DESARROLLADOS CON HERRAMIENTAS DE ALTO NIVEL ANÁLIS Y APLICACIÓN INFORMÁTICA PARA IMPLEMENTACIÓN SOBRE PLC DE STEMAS AUTOMÁTICOS DESARROLLADOS CON HERRAMIENTAS DE ALTO NIVEL Mónica Baigorri Martínez (1) e-mail: Monica.baigorri@die.unirioja.es Emilio

Más detalles

JGCBusing Manual de Usuario v1.0

JGCBusing Manual de Usuario v1.0 JGCBusing Manual de Usuario v1.0 Agosto 2012 Tabla de Contenido 1. Introducción... 3 2. JGCBusing. Herramienta Web... 4 2.1. Descripción... 4 2.2. Creación de una configuración desde cero... 8 2.3. Generación

Más detalles

AUTOMATIZACIÓN - CURSO: 2010-2011- Práctica 3: Automatización de una Puerta de Garaje mediante Arduino

AUTOMATIZACIÓN - CURSO: 2010-2011- Práctica 3: Automatización de una Puerta de Garaje mediante Arduino AUTOMATIZACIÓN - CURSO: 2010-2011- Fernando Torres Medina Juan Antonio Corrales Ramón Carlos Alberto Jara Bravo Grupo de Innovación Educativa en Automática Departamento de Física, Ingeniería de Sistemas

Más detalles

TECNOLOGIAS DE LA INFORMACION: ARQUITECTURA DEL ORDENADOR

TECNOLOGIAS DE LA INFORMACION: ARQUITECTURA DEL ORDENADOR TECNOLOGIAS DE LA INFORMACION: ARQUITECTURA DEL ORDENADOR En esta unidad vamos a estudiar el ORDENADOR, sus principios de funcionamiento, elementos que lo componen y las funciones que cumplen dentro del

Más detalles

NOTA DE APLICACIÓN. RS-485 a 2 hilos: Guía de conexión

NOTA DE APLICACIÓN. RS-485 a 2 hilos: Guía de conexión NOTA DE APLICACIÓN Código: DC.DNA.09 Fecha: 09/09/08 RS-485 a 2 hilos: Guía de conexión Índice 1. Introducción...1 2. Topología de una red RS-485 (2h)...1 2.1 Elementos de la red... 2 3. Conexión de una

Más detalles

CAPÍTULO VI. RESULTADOS, PRUEBAS Y CONCLUSIONES DE LA APLICACIÓN.

CAPÍTULO VI. RESULTADOS, PRUEBAS Y CONCLUSIONES DE LA APLICACIÓN. CAPÍTULO VI. RESULTADOS, PRUEBAS Y CONCLUSIONES DE LA APLICACIÓN. Finalmente en este último capítulo se conocen los resultados, las pruebas y las conclusiones finales de la aplicación Web para el monitoreo

Más detalles

Web ITSM -GUIA RÁPIDA DE USUARIO-

Web ITSM -GUIA RÁPIDA DE USUARIO- Web ITSM -GUIA RÁPIDA DE USUARIO- Manual básico de la aplicación WebITSM donde se visualiza la funcionalidad completa de la misma y la forma adecuada y eficaz de utilizarla. Ingeniería Técnica en Informática

Más detalles

ESCUELA SUPERIOR DE INFORMATICA Prácticas de Estadística UNA SESIÓN EN SPSS

ESCUELA SUPERIOR DE INFORMATICA Prácticas de Estadística UNA SESIÓN EN SPSS UNA SESIÓN EN SPSS INTRODUCCIÓN. SPSS (Statistical Product and Service Solutions) es un paquete estadístico orientado, en principio, al ámbito de aplicación de las Ciencias sociales, es uno de las herramientas

Más detalles

DESCRIPCION GENERAL, PUESTA EN MARCHA Y CONFIGURACION DEL PROGRAMA GESTECNET MANUAL DEL USUARIO

DESCRIPCION GENERAL, PUESTA EN MARCHA Y CONFIGURACION DEL PROGRAMA GESTECNET MANUAL DEL USUARIO DESCRIPCION GENERAL, PUESTA EN MARCHA Y CONFIGURACION DEL PROGRAMA GESTECNET MANUAL DEL USUARIO - 1 - EXTRUCTURA DEL PROGRAMA GESTECNET GestecNET es una solución para la gestión de plantas de hormigón,

Más detalles

Software EasyKool. Manual de instrucciones

Software EasyKool. Manual de instrucciones Software EasyKool Manual de instrucciones 2 1 Índice 1 Índice 1 Índice... 3 1.1. Indicaciones sobre este manual... 5 2 Especificaciones... 5 2.1. Uso... 5 2.2. Requisitos del sistema... 6 3 Primeros pasos...

Más detalles

En el presente capítulo se describe la programación del instrumento virtual y cómo

En el presente capítulo se describe la programación del instrumento virtual y cómo Capítulo 6. Instrumentación virtual En el presente capítulo se describe la programación del instrumento virtual y cómo éste controla el circuito de captura de señales, la llamada telefónica y escribe los

Más detalles

GUÍA DEL USUARIO DE SOFTWARE

GUÍA DEL USUARIO DE SOFTWARE GUÍA DEL USUARIO DE SOFTWARE Serie RJ El contenido de esta guía y las especificaciones de este producto pueden cambiar sin notificación. Brother se reserva el derecho de modificar sin previo aviso las

Más detalles

Fundamentos de Informática. Primer Curso de Ingenieros Químicos. Práctica 1. Dev C++ Compilador de C para Windows

Fundamentos de Informática. Primer Curso de Ingenieros Químicos. Práctica 1. Dev C++ Compilador de C para Windows Práctica 1 Dev C++ Compilador de C para Windows 1. Desarrollo de la práctica Posiblemente, el mejor modo de aprender estas nociones, es comenzar con la escritura de un primer programa en Dev-C++, tal como

Más detalles

Programador de microcontroladores PICs ENIGMA

Programador de microcontroladores PICs ENIGMA Programador de microcontroladores PICs ENIGMA Este tutorial te permitirá construir el hardware del programador USB, la ventaja de construir este hardware; es la de poder utilizarlo con el software de programación

Más detalles

TARJETA ETHERNET Y PROTOCOLO TCP/IP

TARJETA ETHERNET Y PROTOCOLO TCP/IP TARJETA ETHERNET Y PROTOCOLO TCP/IP ÍNDICE 1 Introducción 5 3.2 Actualización de los drivers 3.3 Configuración de TCP/IP 14 18 2 Preinstalación de la Tarjeta Ethernet 7 2.1 Descripción de la Tarjeta Ethernet

Más detalles

Programador de PIC s y Memorias EEPROM

Programador de PIC s y Memorias EEPROM Programador de PIC s y Memorias EEPROM Technical Revision Federico Lugo Revision A1 2013 FETRONICS 2 Descripción MicroProg es un herramienta de Grabacion, Borrado Verificacion y Depuracion programas (.hex)

Más detalles

OpenIRS DOCENTIA Módulo de Gestión. Manual de Usuario.

OpenIRS DOCENTIA Módulo de Gestión. Manual de Usuario. OpenIRS DOCENTIA Manual de Usuario. Versión 3.0.4 Diciembre 2013 Vicerrectorado de Evaluación de la Calidad 1 Contenido 1. INTRODUCCIÓN... 4 2. INSTALACIÓN DEL MÓDULO... 6 2.1. Requisitos Previos... 6

Más detalles

WINDOWS 2008 5: TERMINAL SERVER

WINDOWS 2008 5: TERMINAL SERVER WINDOWS 2008 5: TERMINAL SERVER 1.- INTRODUCCION: Terminal Server proporciona una interfaz de usuario gráfica de Windows a equipos remotos a través de conexiones en una red local o a través de Internet.

Más detalles

V5.05 Manual de Usuario CRecorder V1.00.000 20110610

V5.05 Manual de Usuario CRecorder V1.00.000 20110610 V5.05 Manual de Usuario CRecorder V1.00.000 20110610 i Contenido Introducción Breve... 1 Funciones... 1 Composición del producto... 1 Registro, descarga e instalación... 2 Proceso de registro de usuario...

Más detalles

Programando con SinaProg. Manual de usuario para programar microcontroladores Atmel AVR en Windows con SinaProg

Programando con SinaProg. Manual de usuario para programar microcontroladores Atmel AVR en Windows con SinaProg Programando con SinaProg Manual de usuario para programar microcontroladores Atmel AVR en Windows con SinaProg Este documento se encuentra protegido por una licencia Creative Commons Creative Commons:

Más detalles

Introducción. Mensaje de los Desarrolladores

Introducción. Mensaje de los Desarrolladores Introducción En Aspec System estamos preocupados por los cabios tecnológicos de la vida cotidiana así como las integraciones de la tecnologías de la información en el llamado tele gobierno que está integrando

Más detalles

Gestor de aplicaciones Java. Esta herramienta es el intérprete de los archivos de clase generados por el javac (compilador).

Gestor de aplicaciones Java. Esta herramienta es el intérprete de los archivos de clase generados por el javac (compilador). CAPÍTULO 4 Requerimientos de software Este capítulo presenta las herramientas necesarias para la construcción y ejecución de programas en el lenguaje de programación JAVA, los requerimientos mínimos de

Más detalles

Introducción a la Programación en Java. Page 1

Introducción a la Programación en Java. Page 1 Introducción a la Programación en Java Page 1 Qué es Java? Java es un lenguaje de programación de propósito general, orientado a objetos que fue diseñado específicamente para tener tan pocas dependencias

Más detalles

Manual del usuario. Flash Point Genius. FLASH POINT GENIUS: Programación Serial para turismos

Manual del usuario. Flash Point Genius. FLASH POINT GENIUS: Programación Serial para turismos Manual del usuario Flash Point Genius FLASH POINT GENIUS: Programación Serial para turismos 2010 INDICE 1. INTRODUCCIÓN 3 2. COMPONENTES DEL SISTEMA FLASH POINT 3 3. REQUISITOS DEL SISTEMA 4 4. INSTALACIÓN

Más detalles

ENVÍO DE E-MAIL POR MEDIO DE SMTP

ENVÍO DE E-MAIL POR MEDIO DE SMTP UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA ELO 322: REDES DE COMPUTADORES I ENVÍO DE E-MAIL POR MEDIO DE SMTP Alumnos Ariel Mancilla G. 2521040-9 Daniel Spataris J. 2521029-8

Más detalles

Hecho por Víctor Orozco (tuxtor@shekalug.org) Puerto paralelo

Hecho por Víctor Orozco (tuxtor@shekalug.org) Puerto paralelo Hecho por Víctor Orozco (tuxtor@shekalug.org) Puerto paralelo Un puerto paralelo es una interfaz entre un ordenador y un periférico cuya principal característica es que los bits de datos viajan juntos

Más detalles

Portal Del Emisor MANUAL DEL USUARIO. Plataforma de Facturación Electrónica

Portal Del Emisor MANUAL DEL USUARIO. Plataforma de Facturación Electrónica Portal Del Emisor MANUAL DEL USUARIO Plataforma de Facturación Electrónica 1. Índice 1. Índice... 2 2. Descripción General... 3 2.1. Alcance... 3 2.2. Flujo de navegación... 4 2.3. Perfil del Usuario...

Más detalles

Notas para la instalación de un lector de tarjetas inteligentes.

Notas para la instalación de un lector de tarjetas inteligentes. Notas para la instalación de un lector de tarjetas inteligentes. Índice 0. Obtención de todo lo necesario para la instalación. 3 1. Comprobación del estado del servicio Tarjeta inteligente. 4 2. Instalación

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Guía de uso de Moodle para participantes

Guía de uso de Moodle para participantes Guía de uso de Moodle para participantes ÍNDICE 1 QUÉ ES MOODLE?... 3 2 INTRODUCCIÓN A LA PLATAFORMA... 4 2.1 ACCESO... 4 2.2 CURSO... 5 2.2.1 BLOQUES... 6 3 RECURSOS Y MÓDULOS... 8 3.1 TRANSMISIVOS...

Más detalles

UNIVERSIDAD DE SALAMANCA

UNIVERSIDAD DE SALAMANCA UNIVERSIDAD DE SALAMANCA FACULTAD DE CIENCIAS INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Resumen del trabajo práctico realizado para la superación de la asignatura Proyecto Fin de Carrera. TÍTULO SISTEMA

Más detalles

Practica de Control y Programación de Robots ROBOT HERMES. Curso 2007-2008

Practica de Control y Programación de Robots ROBOT HERMES. Curso 2007-2008 Practica de Control y Programación de Robots ROBOT HERMES Curso 2007-2008 CAMPUS TECNOLÓGICO DE LA UNIVERSIDAD DE NAVARRA NAFARROAKO UNIBERTSITATEKO CAMPUS TEKNOLOGIKOA Paseo de Manuel Lardizábal 13. 20018

Más detalles

Backharddi. 1.1. Introducción. 1.2. Cómo obtener Backharddi? MAX 3.1: Madrid_LinuX Manual de Utilización

Backharddi. 1.1. Introducción. 1.2. Cómo obtener Backharddi? MAX 3.1: Madrid_LinuX Manual de Utilización Backharddi Nota: Este manual solamente cubre la creación de imágenes en dispositivos locales, discos duros tanto internos como conectados a un puerto usb. Posteriormente se completará con la posibilidad

Más detalles

La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México

La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México Licencia La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México S. A de C.V., Está protegida por derechos de autor y / u otras leyes aplicables. Cualquier uso diferente a

Más detalles

Manual Usuario Tacotel Lector

Manual Usuario Tacotel Lector Índice 1 Introducción...3 2 Requisitos...3 2.1 Instalación del lector de tarjetas...3 2.2 Máquina Virtual de Java...5 2.2.1 Problemas ejecución versión 7 de Java...5 2.3 Acceso puerto remoto: 5555...6

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

DESCRIPCION DEL SITEMA MASTER.

DESCRIPCION DEL SITEMA MASTER. DESCRIPCION DEL SITEMA MASTER. ESTRUCTURA. El sistema MASTER (Sistema Modular para Control Adaptativo en Tiempo Real) se ha implementado en base a un computador compatible PC-AT, dotado de una tarjeta

Más detalles

Prácticas PRÁCTICA 6. VLANs: Virtual Local Area Networks

Prácticas PRÁCTICA 6. VLANs: Virtual Local Area Networks Redes de Área Local e Interconexión de Redes Prácticas PRÁCTICA 6. VLANs: Virtual Local Area Networks 1. Introducción Una VLAN (Virtual Local Area Network) o red virtual es un grupo flexible de dispositivos

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

I NTRODUCCIÓN 1. ORDENADOR E INFORMÁTICA

I NTRODUCCIÓN 1. ORDENADOR E INFORMÁTICA I. INTRODUCCIÓN 1. ORDENADOR E INFORMÁTICA 1.1. Informática Informática (Información Automática) es la ciencia y la técnica del tratamiento automatizado de la información mediante el uso de ordenadores.

Más detalles

Seminario WEB Monitores OBDII. Sistemas Mexicanos de Diagnóstico Automotriz 2012

Seminario WEB Monitores OBDII. Sistemas Mexicanos de Diagnóstico Automotriz 2012 1 Objetivos Mostrar la importancia del buen entendimiento de los monitores continuos y no continuos de sistemas OBDII 2 Contenido Introducción OBDII Conector Protocolos Modos de diagnóstico Modo 01 (datos)

Más detalles

Sistema de Adquisición de Datos INGKA-SAD. Guía de Uso

Sistema de Adquisición de Datos INGKA-SAD. Guía de Uso Sistema de Adquisición de Datos INGKA-SAD Guía de Uso Introducción I NTRODUCCIÓN El sistema de adquisición de datos I NGKA -S AD es una interfaz entre el ambiente y el mundo digital, sirviendo como herramienta

Más detalles

Manual del Programa Conecta 3V Para Teléfonos Móviles.

Manual del Programa Conecta 3V Para Teléfonos Móviles. Manual del Programa Conecta 3V Para Teléfonos Móviles. Realizado por Xuitec S.L. Versión del documento 1.0 Página 1 de 18 Índice: 1. Introducción...3 2. Instalación y puesta en marcha...4 3. Menú Principal.

Más detalles

I N S T R U C C I O N E S

I N S T R U C C I O N E S I N S T R U C C I O N E S I n d i c e CONEXIÓN DE APARATOS... 4 Instalación y actualización... 4 Ejecución... 8 DESCRIPCIONES BÁSICAS... 8 Artículos... 8 Agentes... 10 Proveedores... 12 Impresora... 14

Más detalles

Ayuda para la instalación Componente Firma Digital INDICE. 1 Configuración previa...2. 1.1 Configuración Internet Explorer para ActiveX...

Ayuda para la instalación Componente Firma Digital INDICE. 1 Configuración previa...2. 1.1 Configuración Internet Explorer para ActiveX... INDICE 1 Configuración previa...2 1.1 Configuración Internet Explorer para ActiveX...2 1.2 Problemas comunes en sistema operativo Windows...8 1.2.1 Usuarios con sistema operativo Windows XP con el Service

Más detalles

CERTIFICADOS ELECTRÓNICOS Y LECTORES DE TARJETAS LTC31 USB CERTIFICADOS ELECTRÓNICOS Y LECTORES DE TARJETAS LTC31 USB

CERTIFICADOS ELECTRÓNICOS Y LECTORES DE TARJETAS LTC31 USB CERTIFICADOS ELECTRÓNICOS Y LECTORES DE TARJETAS LTC31 USB CERTIFICADOS ELECTRÓNICOS Y LECTORES DE TARJETAS LTC31 USB 1 LECTORES DE TARJETAS... 2 2. INSTALACIÓN DE DRIVERS DEL LECTOR DE TARJETAS LTC31 USB.... 2 3. INSTALACIÓN DE LOS MÓDULOS DE SEGURIDAD... 5 3.1

Más detalles

Manual de Usuario IFI Web. Transmisión / recepción de ficheros.

Manual de Usuario IFI Web. Transmisión / recepción de ficheros. Manual de Usuario IFI Web. Transmisión / recepción de ficheros. Servicios de cesión de datos para las Administraciones Públicas Unidad de Infraestructuras Octubre 2013 Versión: 2.1 INDICE 0. INTRODUCCIÓN...

Más detalles

Placa de control MCC03

Placa de control MCC03 Placa de control MCC03 Placa de control MCC03 La placa de control basada en el micro controlador PIC 16F874A de Microchip, es la encargada del procesar los datos que se introducen en el sistema y actuar

Más detalles

MANUAL DEL INSTALADOR

MANUAL DEL INSTALADOR MANUAL DEL INSTALADOR Índice Índice... 2 Instalación... 3 Extracción de archivos... 3 Actualización de los archivos de sistema... 3 Pantalla inicial... 4 Selección de la ruta de instalación... 4 Selección

Más detalles

(volver a Tabla de Contenidos)

(volver a Tabla de Contenidos) Para escribir, compilar y ejecutar un programa en Java lo único que realmente se necesita y no viene incluido con el sistema operativo es el kit de desarrollo de Java, denominado SDK (Software Development

Más detalles

1.- SOBRE NADILUX 2.- GESTIÓN DE INVENTARIO Y GEOLOCALIZACIÓN

1.- SOBRE NADILUX 2.- GESTIÓN DE INVENTARIO Y GEOLOCALIZACIÓN INDICE 1.- SOBRE NADILUX... 2 2.- GESTIÓN DE INVENTARIO Y GEOLOCALIZACIÓN... 2 2.1 - CENTROS DE MANDO... 3 2.2 - PUNTOS DE LUZ... 4 2.2.1 MODIFICAR PUNTOS DE LUZ... 5 2.3 MAPA... 5 2.3.1 STREET VIEW...

Más detalles

TALLER COMPUTACIÓN II

TALLER COMPUTACIÓN II Prof. Martín Ferreyra TALLER COMPUTACIÓN II MANEJO AVANZADO DE MS WORD COMBINAR CORRESPONDENCIA Combinar Correspondencia Instituto Secundario John Kennedy Unidad 2. Combinar correspondencia (I) Mediante

Más detalles

DISPLAYS DE CRISTAL LIQUIDO

DISPLAYS DE CRISTAL LIQUIDO DISPLAYS DE CRISTAL LIQUIDO INDICE MANUAL DE REFERENCIA DEL LCD 1.- INTRODUCCION 2.- CARACTERISTICAS DEL DISPLAY 2.1.- Aspecto físico 2.2.- Alimentación 2.3.- Los caracteres del LCD 2.4.- La memoria del

Más detalles