f Proyecto OBDII ~ Ingenieria a nivel industrial

Visita mi canal de youtube

domingo, 16 de julio de 2017

Proyecto OBDII







Nuestro objetivo para este proyecto fue construir un dispositivo compatible con OBD-II que se comunique con cualquier coche habilitado para OBD-II y lea datos en tiempo real, así como realizar pruebas de rendimiento y diagnósticos básicos.

Si alguna vez ha tenido que llevar su coche a la tienda debido a la temida "Check Engine" de luz, puede tener el mismo aprecio por este proyecto como lo hicimos. Desde 1996, todos los automóviles vendidos en los Estados Unidos han sido requeridos para implementar el estándar de diagnóstico a bordo (OBD-II). Esta norma permite a los mecánicos y técnicos de reparación comunicarse con la computadora de a bordo de un vehículo y leer los datos de ella, incluso por qué está encendida la luz del motor de control. Los lectores OBD-II comerciales están disponibles, pero ofrecen una funcionalidad limitada y suelen ser caros. Además, no son tan geniales como el proyecto que decidimos construir.

Diseño de alto nivel

Comenzamos nuestro proyecto basado en un chip que está diseñado para manejar la interpretación OBD-II, el ELM327 de ELM Electronics. Este chip tiene la capacidad de transmitir en cualquiera de los diferentes estándares de transmisión implementados por diferentes fabricantes de automóviles, y fue la base para el diseño de hardware de nuestro proyecto. Convierte los diferentes formatos de comunicaciones del vehículo en cadenas ASCII que se transmiten utilizando la serie RS232. Muchos proyectos OBD-II de encargo existen en la tela y sacamos ideas de estos diseños, que se enumeran en nuestra sección de las referencias. En su mayor parte, nuestro diseño de hardware se basó en las instrucciones contenidas en la hoja de datos ELM327 y en los otros componentes que compramos, como el MCP2551 (Transceptor CAN) y nuestra pantalla LCD compatible con HD44780 de 4 líneas.

Utilizamos las ideas de estructura de menús de nuestro laboratorio de sistemas de seguridad como base para algunos de nuestros programas, así como la forma de implementar las comunicaciones UART entre el microcontrolador y el ELM327.

A continuación se muestra un dibujo de alto nivel de cómo se conectó cada dispositivo en nuestro proyecto. Esto muestra cómo la MCU se comunica con los diversos componentes necesarios para implementar la norma OBD-II. Las flechas de transmisión del ELM327 para las comunicaciones estándar SAE e ISO indican hardware de transmisión y recepción para ambos, ya que no funcionan a 5V como el ELM327.

En cuanto a las cuestiones legales que rodean este proyecto, no creemos que hemos recortado los límites legales en la creación o uso de nuestro proyecto. Nuestro código de controlador de pantalla LCD cae bajo reglas de código abierto y el resto del código es nuestra propia creación. Si intentáramos producir este dispositivo comercialmente, podríamos estar obligados a pagar por nuestro uso de los estándares SAE e ISO que hemos implementado. Dado que no estamos creando este dispositivo para la venta comercial, nuestro uso de la información de las normas SAE e ISO, tal como lo proporciona Wikipedia, cae bajo un uso justo.




Compensaciones de hardware y software

Una de las principales decisiones de diseño en este laboratorio fue usar el ELM327 para comunicarse con el vehículo. Es ciertamente posible, y se ha hecho antes, para utilizar un microcontrolador para implementar OBD-II comunicaciones con una marca de fábrica específica del coche. Esto es porque aunque el OBD-II es un estándar implementado en todos los coches vendidos en los EE.UU. hoy en día, cada empresa de automóviles ha implementado de manera diferente como se describe a continuación, lo que resulta en cinco protocolos de señalización distintos. Debido a esto, si hubiéramos optado por implementar toda la señalización y modulación en software, sólo habríamos tenido tiempo de implementar un protocolo de señalización específico que sólo funcionaría en ciertos tipos de automóviles. Debido a que queríamos ser capaces de interactuar con muchos tipos diferentes de coches, elegimos utilizar el ELM327.

Al decidir sobre una interfaz de usuario sabíamos que requeriríamos la entrada de los usuarios de los botones como se implementó en nuestro diseño final. También queríamos usar un LCD compatible con HD 44780 como el que se usa en el laboratorio. Dado que queríamos mostrar más información y hacerla fácilmente legible en un coche oscuro, elegimos una bonita línea azul retroiluminada HD 44780 LCD compatible que se encuentra en Ebay.

Estándares

Había por definición muchos estándares que necesitábamos para que nuestro proyecto funcionara correctamente. El primero, y más obvio, es el estándar OBD-II. Se ha requerido en los coches vendidos en los EE.UU. desde 1996. Una de las principales especificaciones de OBD-II es el conector: un 16-pin (2x8) SAE J1962 conector. Un lado femenino universal se proporciona en el coche, generalmente debajo del volante en el lado del conductor. También especifica un conjunto estándar de códigos de problemas de diagnóstico (DTC) que permiten a la mecánica identificar problemas con el vehículo, como cuando se enciende la luz "Check Engine".

Los protocolos de señalización son importantes para ser conscientes de, a pesar de que no tuvimos que implementar cada uno individualmente en nuestro diseño. SAE J1850 define el protocolo estándar utilizado por la mayoría de los fabricantes de automóviles estadounidenses. Ford Motor Company utiliza una variación en el protocolo J1850 con modulación de ancho pulsado y un + 5V de alta tensión en las líneas de comunicación. General Motors utiliza una variación en el protocolo J1850 con un formato de ancho pulsado variable y un voltaje de + 7V en las líneas de comunicación.

Existen tres protocolos de señalización estándar ISO: ISO 9141-2, ISO 14230 KWP2000 e ISO 15765 CAN. ISO 9141-2 es muy similar a RS-232, pero utiliza el voltaje de la batería (12V) como una señal de alto voltaje y se utiliza principalmente en Chrysler, vehículos europeos y asiáticos. ISO 14230 KWP2000 es casi idéntico a ISO 9141-2 pero con longitudes de mensaje más grandes. Por último, el protocolo ISO 15765 CAN (Controller Area Network) se ha introducido como el único protocolo de señalización de los vehículos vendidos en los Estados Unidos a partir de 2008.


Hardware Design






Debido a la naturaleza de este proyecto había un componente de hardware significativo al diseño. Los principales componentes de hardware como se muestra arriba en el diseño de alto nivel son: el ELM327, el hardware del transceptor ISO / SAE / CAN, la MCU y la placa de destino, la pantalla LCD y los botones. Al principio tomamos la decisión de diseño que sería más conveniente utilizar este dispositivo si estaba completamente libre de batería, completamente alimentado a través del puerto OBD-II que atrae 12V del sistema eléctrico del coche. Esto era consistente con el objetivo de nuestro diseño, que era hacer un fácil utilizar el lector de OBD-II que se utiliza típicamente en garages y no necesariamente en proximidad cercana a un enchufe.

Regulacion de voltaje

Para dividir correctamente las partes de hardware diferentes de este diseño requiere una comprensión de lo que hace cada parte y qué tipo de señales y voltajes que llevará. El tablero objetivo del microcontrolador es un tablero digital con todos los niveles de voltaje existentes entre 0 y 5V. La decisión fue tomada temprano para dejar el regulador de voltaje en este tablero y regular el 12V del coche a 5V en el tablero del blanco usando el regulador incorporado proporcionado (LMV340LAZ). El ELM327 es similar en función al microcontrolador en que opera principalmente en señales digitales de 5 V, ya que es un microcontrolador en sí. El transceptor MCP2551 CAN también es un dispositivo digital. Estos dos IC junto con LEDs indicadores y un cristal de 4MHz para el ELM327 se colocaron juntos en una placa que denominamos "placa digital".

La placa analógica contenía gran parte del hardware de transmisión y recepción necesario para implementar los protocolos SAE e ISO, así como la regulación de voltaje. A diferencia de la tarjeta digital de 5V, esta "tarjeta analógica" contiene niveles de voltaje de 12V, 5V y 6V en una placa. Un regulador de 12V-5V de 78L05 proporciona la fuente de 5V para la placa digital, así como parte de la interfaz SAE. La interfaz SAE también requiere una fuente de 6V, que es proporcionada por un regulador 317L. La interfaz ISO funciona con el voltaje de la batería y por lo tanto el 12V del coche se utiliza para impulsar los transistores para la comunicación ISO que también se encuentra en esta placa. El 12V no está conectado en ninguna parte cerca del ELM327 en la placa digital en un intento de aislar lo más posible de los 12V que pueden (y una vez durante este proyecto) destruir el ELM327.

ELM327

El ELM327 es realmente un PIC de microcontrolador especialmente programado diseñado para manejar comunicaciones en el estándar OBD-II. Funciona en el riel de 5V suministrado en la placa digital y proporciona realimentación de depuración a través de 4 LED que indican las líneas Tx y Rx para el coche y RS232 Tx y Rx. Funciona a una frecuencia de 4MHz según lo proporcionado por un cristal unido.

Los datos se reciben a través de uno de los tres estándares de señalización y luego por el ELM327 que interpreta los datos y los transmite en una línea RS232 estándar que puede ser leída por el ATMega644. De forma similar, cuando un MCM envía un comando al ELM327, se interpreta y se convierte en el protocolo de señalización correcto que se transmite entonces al automóvil. El ELM327 no lee en realidad los comandos o datos que se están enviando, sino que simplemente convierte los datos ASCII en la línea RS232 a los voltajes adecuados en el puerto OBD-II.

El hardware de transmisión se utiliza para convertir la señal de salida de la ELM327 en los voltajes adecuados para el coche. Dado que el protocolo SAE requiere 5V o 7V dependiendo de si está utilizando el modo PWM o VPW, ambos voltajes se alimentan usando pares de transistores (PNP y NPN) a la línea de transmisión real que se conecta al puerto OBD-II. El 7V (más cercano a 6,5V en la práctica) se proporciona desde el regulador 317L.

El hardware de transmisión ISO es un diseño relativamente básico que convierte el nivel 5V del ELM327 al voltaje de la batería 12V atando los pines ELM327 a la base de 2 transistores NPN en una configuración de emisor común. De forma similar, el protocolo CAN se implementa dentro del MCP2551 que está conectado con dos líneas al ELM327.

En el apéndice se muestra un esquema detallado de cómo se conectaron los equipos ELM327, MCP2551 y el transceptor. En el esquema es una interfaz opcional RS232 que decidimos no implementar ya que no era necesario para las comunicaciones con la MCU. El principal problema que encontramos con esta parte del proyecto fue un soplado ELM327 debido a una fuente de 12V llegar a la placa digital. Bruce y los TAs fueron capaces de ayudarnos a localizar la fuente de la alta tensión (un resistor mal soldado que fue "extraído" con un poco de fuerza adicional) y el problema fue corregido.


LCD

Con el fin de reutilizar tanto código como sea posible de los controladores de LCD existentes, optamos por adquirir una pantalla LCD con un controlador compatible Hitatchi HD44780 a bordo. Este es el mismo controlador de LCD que se utiliza en la biblioteca de LCD proporcionada por Bruce Land como parte de este curso, y lo elegimos debido a nuestra familiaridad con él. Dado que sabíamos que queríamos tener una estructura de menú relativamente grande con etiquetas de botón en pantalla, elegimos una pantalla de 4 líneas debido a la mayor área de escritura que nos proporcionó. La pantalla LCD se conecta a la placa de destino a través de las cabeceras y el contraste se cablea usando un divisor de voltaje a un ajuste que se consideró razonable. La luz de fondo azul a esta pantalla fue cableada a 5V a través de un resistor de 330 ohmios que resultó ser eficaz a través de la experimentación.

Botones

Para la entrada del usuario elegimos utilizar 4 botones básicos que encontramos en el laboratorio. Estos botones cierran un circuito internamente cuando son presionados y son de resorte para abrir cuando no se presionan. Se cablean a tierra en un lado y en los pasadores A0 a A3 en el otro lado. Estas clavijas están atadas a resistencias de 5V a 10 kilo-ohmios de manera que cuando se presiona el botón, se lee 0V en el pin del microcontrolador y sólo se extrae una pequeña cantidad de corriente (0,5 mA).

Junta de destino

Con el fin de reducir el factor de forma global de nuestro dispositivo, elegimos construir un tablero objetivo para el ATMega644. No todos los puertos se utilizan, pero el UART (pins D0 y D1) son los únicos utilizados para comunicarse con el ELM. El puerto C se utiliza para escribir en la pantalla LCD y A0 a A3 se utilizan para leer la información de pulsación del botón. Todo excepto las líneas UART se conecta utilizando un tablero de cabecera que simplifica el cableado durante el proceso de desarrollo. Durante el proceso de desarrollo, uno de los problemas con los que nos topamos era que el tablero objetivo a veces no se comunicaba correctamente con el ELM327. Después de mucha depuración y asistencia de Bruce, se encontró que el problema era un interruptor de alimentación suelto en el tablero objetivo que fue soldado nuevamente y corregido.



La placa objetivo fue diseñada por Bruce Land para el curso ECO 4760.

Diseño de software

volver arriba
El software para el lector OBD2 hace uso de una máquina de estado para impulsar la comunicación UART basada en un estado de menú dado. El diseño del software comienza con una máquina de estado de nivel superior, que describe la interacción entre la arquitectura del menú y la comunicación UART. A continuación se describen la arquitectura del menú y la funcionalidad del dispositivo, la comunicación UART, las macros y la dinámica de los botones.

Descargue el código fuente aquí: OBD2.c

Máquina de estado de nivel superior


Encender

Cuando el dispositivo es alimentado por primera vez, se produce una secuencia de inicialización, como se muestra por el nodo 'apagado'. El primer comando, echo apagado (consulte la tabla para más detalles sobre el comando), desactiva el ELM327 de hacer eco de los caracteres recibidos al host, el ATmega644. La pantalla de inicio de encendido mostrada a continuación se completa después de solicitar la identificación de versión del ELM327. La pantalla se mantiene durante dos segundos y se reenvía al menú principal.

Menú principal

Todos los caminos conducen al menú principal. Esta pantalla presenta al usuario con cinco secciones: medidores, diagnósticos, sobre, ensayos y unidades. Se utiliza una flecha como icono indicador para la navegación por menús. Cuando regresa al menú, el cursor se restablece de nuevo a los indicadores. El usuario puede desplazarse por los submenús pulsando el botón hacia arriba o hacia abajo, y confirmando pulsando el botón derecho. Para asegurar que el búfer de recepción se restablece antes de entrar en otro estado de petición, el índice de búfer de recepción se pone a cero al volver al menú principal.


Medidores

La pantalla de indicadores muestra la velocidad, revoluciones por minuto, voltaje de la batería y temperatura del refrigerante del motor en un diseño fácil de leer. Después de imprimir el texto estático (todo el texto además de los números), el programa entra en un bucle de transmisión / recepción para actualizar las mediciones lo más rápido posible (consulte la tabla de solicitud de la ECU). Si el usuario desea volver al menú principal, presionando el botón izquierdo saldrá de los medidores después de la próxima recepción.

Si este dispositivo estaba en uso fuera de los Estados Unidos y el usuario deseaba cambiar los indicadores de las unidades inglesas a las unidades métricas (SI), es suficiente una visita a la sección de unidades del menú principal. Después de elegir las unidades apropiadas, volver a los medidores refleja la selección en la velocidad y la temperatura del refrigerante. Es interesante observar que la ECU codifica estos datos en kilómetros por hora y Celsius respectivamente, y macros, como se definen en la tabla, se utilizan para mostrar estos datos bajo la opción de unidad en inglés.


Diagnóstico

En el submenú de diagnóstico, el usuario tiene dos opciones: verificar o borrar los códigos del motor. El cursor se ajusta inicialmente para comprobar los códigos del motor, ya que se supone que el usuario desea detectar errores antes de borrar las notificaciones. Se tomó una decisión de diseño para aceptar sólo los tres primeros códigos en caso de que haya más de tres códigos de motor marcados. La longitud de respuesta de una solicitud de código de motor varía dependiendo de la cantidad de errores. Cada línea de datos consta de seis bytes, y un error dado se describe en dos bytes. Excluyendo la primera línea de datos, tres códigos de error están contenidos en un paquete de error. Los valores hexadecimales en bruto de los errores se muestran para el usuario y se pueden referenciar en una tabla de búsqueda externa. El desarrollo posterior incluiría una tabla de consulta a bordo que contiene información de error.

Después de revisar los errores presentes en el coche, el usuario tiene la opción de borrar todos los códigos de problemas almacenados y apagar el indicador de control del motor. SAE especifica que cualquier herramienta de exploración comercial confirma que la solicitud de borrado es intencional, por lo que se implementó una pantalla de descargo de responsabilidad. Tras la confirmación, se envía la solicitud de código claro (consulte la tabla) y la respuesta se juzga por su éxito o falla. Después del éxito o falla, el programa regresa al menú principal.


Acerca de

Cada dispositivo fabricado se codifica con un identificador único según lo establecido por los desarrolladores. El propósito de este menú es mostrar el número de serie del dispositivo. Después de entrar en este submenú una vez, la MCU almacena el número de serie y no lo solicita si se vuelve a introducir la pantalla about.



Ensayos

Este submenú prepara al usuario para entrar en el modo de sincronización de cero a sesenta millas por hora. Al comenzar la prueba, la MCU muestra instrucciones para el usuario. Si el vehículo se está moviendo cuando comienza la prueba, se le dice al conductor que reduzca a cero. Después de que el coche ha llegado a una parada completa, al conductor se le instruye para proceder cuando esté listo. Tan pronto como la velocidad es leída por la MCU como mayor que cero, el temporizador comienza. La prueba se completa con alcanzar sesenta millas por hora o más de sesenta segundos, momento en el que la velocidad y el tiempo se congelan. El usuario puede volver al menú principal después de completar la prueba.

Selección de Unidad

Esta pantalla permite al usuario seleccionar desde el sistema de unidades en Inglés y Métrico (SI). La tercera línea de la pantalla indica la configuración actual. Cualquier cambio en este submenú se reflejará automáticamente en los otros menús.


Comunicación UART

Los dos microcontroladores, el ATmega644 y el ELM327, contienen una interfaz de tipo UART estándar, y se comunican a través de los pines TX y RX. El juego de caracteres ASCII se utiliza tanto en las solicitudes como en las respuestas al ELM327. Es importante tener en cuenta la diferencia en el carácter final de un mensaje tanto para la transmisión de la MCU como para la respuesta del ELM327. Al enviar una petición al ELM327, un retorno de carro (valor hexadecimal 0x0D) indica la terminación de un mensaje; Sin embargo, el ELM327 puede responder con un mensaje de varias líneas, utilizando el carácter de retorno de carro para simplemente terminar una línea de datos. En su lugar, el ELM327 utiliza un ">" (valor hexadecimal 0x3E) para notificar al MCU que está en estado inactivo y listo para recibir caracteres.

Hay dos tipos diferentes de mensajes que se pueden enviar al ELM327. El primer tipo de mensaje comienza con "AT", como se muestra en la tabla siguiente, y se utiliza para leer o modificar datos en el propio ELM. Uno de los lujos asociados con el ELM327 es que el análisis de mensajes no distingue entre mayúsculas y minúsculas. Esto significa que los comandos "ATRV", "en rv" y "aT Rv", todos leen el voltaje.



El segundo tipo de comando, que se muestra en la tabla siguiente, es interpretado por el ELM327, reformateado en el protocolo apropiado, y enviado a la ECU a bordo del automóvil. Tales órdenes se componen de un modo y un id de parámetro (PID). Aunque el ELM327 es capaz de distinguir qué mensajes están destinados a ECU, no supervisa el contenido de los mensajes.

Macros

Antes de que comience el programa, se han definido macros para simplificar la conversión de datos que se produce a lo largo del programa, como la interpretación de RPM o el cambio del inglés a unidades métricas.


Botón Navegación

Además del hardware asociado con la navegación de botones, este dispositivo utiliza la pantalla lcd para indicar el significado de los botones izquierdo y derecho. En ciertos menús, como el menú principal, el botón izquierdo no tiene un propósito, mientras que en otros se vincula al menú principal. El propósito del botón derecho también cambia dado el menú. Por ejemplo, en la pantalla de medidores, el botón derecho no tiene ningún propósito, mientras que en el menú de ensayos, inicia la prueba de cero a sesenta millas por hora.

Resultados del Diseño

volver arriba
Precisión y tiempo

Este dispositivo experimenta variaciones de tiempo como resultado de las diferencias en el tiempo de respuesta de la ECU. Los protocolos OBD2 no están sujetos a restricciones de temporización específicas. Este factor limitante afecta tanto a los medidores como a las mediciones del ensayo. En la pantalla de medidores, la velocidad, la rpm, la tensión y la temperatura del refrigerante se actualizan tan rápido como la ECU pueda responder. Tan pronto como se recibe la respuesta anterior, se transmite la solicitud para la siguiente medición. Aparte de los indicadores, el temporizador de cero a sesenta millas por hora es dramáticamente afectado. La prueba cronometrada depende de la frecuencia de actualización de la medición de velocidad. El tiempo de prueba se muestra después de que la medición de velocidad se ha recibido correctamente. En promedio, la resolución del temporizador en el ensayo es de 0,3 segundos.

Consideraciones de seguridad

Cuando la construcción de un dispositivo utilizado en un automóvil, la seguridad es una preocupación importante. Para empezar, es muy importante mantener los ojos en la carretera. Mientras que el dispositivo muestra información útil sobre el funcionamiento del vehículo, no se pretende en modo alguno distraer al conductor. La propuesta de diseño incluía una función de texto a voz, que, debido a limitaciones de tiempo, no estaba totalmente integrada. Esto permitiría al conductor ser consciente de la información mostrada en la pantalla, sin causar una distracción visual.

Además del uso general del dispositivo, las capacidades específicas del ELM327 necesitan ser consideradas. Como se mencionó anteriormente, el ELM327 es capaz de manipular protocolos para la transmisión de datos, pero no supervisa los mensajes específicos. Dado el comando para borrar los códigos del motor, el ELM327 actúa inmediatamente, pero el SAE especifica que las herramientas de exploración verifican que la petición es intencional. Para cumplir con estas especificaciones, incluimos una advertencia que cuestiona al usuario si reparó el motor antes de restablecer la información almacenada.

Mientras que algunos fabricantes tienen códigos personalizados disponibles para modificar los datos del ECU, no hay códigos disponibles para controlar los sistemas físicos del coche. Si el lector OBD2 falla y transmite códigos aleatorios a la ECU, los sistemas físicos no funcionarán mal. No es posible que el dispositivo conduzca el coche, aumente la velocidad, aplique las pausas o apague / encienda el motor.
Al probar este dispositivo, tanto Mike como Avi estaban seguros de usar sus cinturones de seguridad y cumplir con las reglas de la carretera, incluyendo los límites de velocidad, los marcadores de carril, y señalado, cuando sea apropiado. El dispositivo fue leído y operado únicamente por el pasajero, para asegurar la seguridad del conductor y de los pasajeros.

Interferencia / Usabilidad

El lector OBD2 no parecía tener un impacto en su entorno. El dispositivo no hace uso de ningún sistema inalámbrico, ni hace sonidos molestos que podrían distraer a otros estudiantes en el laboratorio.

La construcción final del dispositivo es extremadamente fácil de usar. El aspecto elegante - caja negra con nada más que una pantalla lcd y botones visibles para los usuarios - presenta un producto. Evitar el aspecto de un par de placas de circuito conectado por cable elimina el estrés que el usuario podría experimentar en la fijación de un dispositivo de este tipo a su coche. Los colores de la pantalla, azul y blanco, no discriminan para los usuarios de color-ciego; Sin embargo, con la falta de texto a voz, los que sufren de ceguera completa no pueden utilizar nuestro dispositivo. Esto es probable que no sea un problema, ya que los usuarios no deben operar maquinaria pesada en el primer lugar. Se ha supuesto que el usuario es alfabetizado, ya que la lectura es un aspecto esencial de este proyecto. La práctica de codificación era tal para asegurar que no se podía hacer daño al ECU. No hay ninguna combinación de presiones de botón que el usuario pueda realizar para provocar la reescritura de parámetros de a bordo.

Consideraciones éticas

Como ingenieros eléctricos que reciben instrucción en una institución tan prestigiosa como la Universidad de Cornell, debemos mantener los más altos estándares de investigación y desarrollo según lo establecido por el Código de Ética de la IEEE. Si bien hemos acordado no aceptar el soborno con respecto a la regla número cuatro, muchas compañías diferentes como ELM electronics y Carplugs.com patrocinaron muestras bajo el acuerdo de que publicaríamos un banner en nuestro sitio web. Creemos que esto no es una forma de soborno, sino una forma respetable de trueque. Después de discutir el código de ética al escribir este informe, hemos cumplido con nuestro deber de ayudarnos mutuamente a reforzar los códigos. Nuestra comunicación a lo largo del proyecto nunca creó tensión o conflicto, ni tampoco la discriminación por raza, religión, género, edad, discapacidad o nacionalidad. Todas las contribuciones de otros, como Bruce Land y Ruibing Wang, fueron debidamente documentadas. La honestidad y la crítica positiva establecieron un ambiente de trabajo placentero.

El desarrollo de este dispositivo no es en modo alguno destinado a contratistas externos. Esto reduce la limitación de la formación adecuada en el área específica del desarrollo electrónico del automóvil. A través de nuestra investigación, pudimos tomar decisiones educadas en relación con la seguridad de la herramienta de exploración de automóviles, como se ejemplifica en nuestra renuncia para restablecer los códigos de problemas del motor.

Consideraciones legales

Nuestro dispositivo no contiene un transmisor de RF por lo que no cae bajo las regulaciones de la FCC. Sin embargo, como se mencionó anteriormente, si se vendiera comercialmente se necesitarían adquirir las aprobaciones apropiadas para implementar los estándares SAE e ISO. Además, las consideraciones legales deben tenerse en cuenta con la seguridad del producto. Hemos hecho todo lo posible para que nuestro producto sea lo más seguro posible. Si tuviéramos tiempo adicional habríamos implementado capacidades de texto a voz para permitir al conductor interactuar con el sistema sin mirar la pantalla, pero por ahora los pasajeros pueden usar el sistema durante las maniobras de conducción. Finalmente, mediante la implementación de una pantalla de confirmación para nuestra función de código claro, cumplimos con los requisitos SAE sobre cómo los lectores OBD-II borran los códigos de problemas de diagnóstico.

Pensamientos finales

En general, encontramos este proyecto muy satisfactorio, aunque nos encontramos con nuestra justa parte de los obstáculos en el camino. Como Bruce había indicado al principio de este proyecto, el hardware fue encontrado como una fuente importante de problemas durante la depuración y pruebas de nuestro dispositivo. Las resistencias rotas, los cables mal conectados y los circuitos integrados fritos dificultaban enormemente nuestros esfuerzos, ya que no había manera de probar nuestro software sin tener que funcionar correctamente.

Elegimos este proyecto porque ambos disfrutamos de los coches y la idea de interactuar con las computadoras que se han vuelto tan frecuentes en nuestros coches hoy fue emocionante para nosotros. Estamos muy contentos de haber elegido este proyecto porque las horas de prueba fueron mucho más agradables porque encontramos el tema tan interesante. También es campo emocionante para trabajar con porque hay tanto espacio para expandir nuestra idea

Appendix



Hardware Communications Schematic




ELM327 Hardware Schematic








1 comentario:

  1. te la Rifas, ando investigand paara un proyecto similar con raspberry pi con interfaz HMI Gracias!

    ResponderEliminar