Documento de Arquitectura para el

Sistema de Información del Centro de

Diagnóstico Automotor CDA

SUMARIO: 1. Introducción. 2. Problema. 3. Solución propuesta. Referencias.

1. Introducción

Con fundamento en el Código Nacional de Tránsito Terrestre [1], Artículo 28. “Para que un
vehículo pueda transitar por el territorio nacional, debe garantizar como mínimo el perfecto
funcionamiento de frenos, del sistema de dirección, del sistema de suspensión, del sistema de
señales visuales y audibles permitidas y del sistema de escape de gases; y demostrar un estado
adecuado de llantas, del conjunto de vidrios de seguridad y de los espejos y cumplir con las
normas de emisión de gases que establezcan las autoridades ambientales”.

Un Centro de Diagnóstico Automotor CDA es un “Ente estatal o privado destinado al examen

técnico-mecánico de vehículos automotores y a la revisión del control ecológico conforme a las
normas ambientales” [1].

La revisión técnica de vehículos tiene su origen en la necesidad de asegurar unos determinados

niveles de mantenimiento y seguridad de los vehículos una vez matriculados y puestos en
circulación. Dicho funcionamiento se verifica mediante la Revisión Técnico mecánica y de
Emisiones Contaminantes (RTMyEC) y dicha revisión se realiza en los CDA debidamente
autorizados.

Para la puesta en marcha de un CDA deben atenderse aspectos legales y normativos, los cuales
se relacionan en la Ilustración 1.
 Ilustración 1. Aspectos Legales y normativos para un Centro de Diagnóstico Automotor

La ilustración 2 presenta, según la NTC 5375 [3], los pasos que se realizan en una revisión
técnico mecánica y relaciona las normas técnicas aplicables en Colombia para las pruebas.
 Ilustración 2. Pasos y pruebas a realizarse en una revisión técnico mecánica

2. Problema

Teniendo en cuenta las condiciones de obligatoriedad de la revisión técnico mecánica

establecida por el gobierno nacional, los propietarios de los vehículos (clientes) deben llevar a
un CDA para obtener el correspondiente certificado resultado de la revisión.
Para esto el cliente lleva el vehículo al CDA donde, al llegar, registran la información general del
vehículo. Un operario lo recibe, realiza una inspección visual del vehículo, registra observaciones
(rayones, farolas, etc.) y permite el ingreso a parqueaderos.

En el área administrativa, cliente solicita el servicio de revisión técnico mecánica presentando

tarjeta de propiedad del vehículo, el SOAT al día y RUNT. Con los documentos en orden, se
realiza la facturación. Se autoriza el ingreso del vehículo a la línea de revisión donde lo recibe el
operario de pista, se realizan las pruebas y registran los resultados en cada una de las
estaciones. Al pasar por todas las estaciones, el jefe técnico valida el documento o solicita
repetición de alguna prueba.

Teniendo los resultados de las pruebas se construye el informe de revisión, dando dictamen de
aprobación, se genera el certificado técnico mecánico y se realiza el reporte al RUNT (cuando
se aprueba la revisión).

Todos los días, o de acuerdo al estado de los equipos, los operarios deben realizar la calibración
y mantenimiento de los equipos de toma de medidas. La información de calibración,
mantenimiento y fallas debe ser registrado según indica la norma.

Al momento de registrar la información, se ha detectado problemas relacionados a:

 Ingreso de resultados de las pruebas de forma manual en formatos impresos, lo que induce
al error ya sea voluntario o involuntario.
 Perdida o daño de documentos. No se cuenta con respaldo.
 No hay conectividad con sistemas externos que faciliten el registro de información.

3. Solución Propuesta

Como solución al problema planteado, se propone la implementación de un sistema que gestione

la información del Centro de Diagnóstico Automotor CDA, llevando la trazabilidad de la
información de los vehículos desde el momento del ingreso al CDA hasta su salida,
contemplando el registro de la información de resultados de las pruebas y la emisión del
correspondiente certificado técnico-mecánico, si el dictamen de la prueba es satisfactorio.
La captura de la información que envían los dispositivos requeridos para cada una de las
pruebas, se hará directamente al sistema. Si algún dispositivo no cuenta con la posibilidad de
enviar los resultados, estos serán ingresados al sistema por el operario.

Por gestión documental, se requiere que se guarde la información y los documentos soportes a
cada revisión técnico mecánica.

Por legislación nacional, se requiere que se establezca comunicación con el RUNT para registro
de la información relacionada a la revisión y al certificado técnico mecánico, y con el sistema de
la DIAN para la facturación electrónica.

Para ver de forma general los pasos de la revisión técnico mecánica, en la ilustración 3 se
presenta el diagrama de actividades.

Ilustración 3. Diagrama de actividades de la revisión técnico mecánica

El diagrama de despliegue (Ilustración 4) muestra las relaciones físicas de los distintos nodos
que componen un sistema y la distribución de los componentes sobre cada nodo.

Ilustración 4. Diagrama de despliegue de la solución

Arquitectura de Software

El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos
de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos
(Modelo, Vista y Controlador). El Patrón MVC se ve frecuentemente en aplicaciones Web, donde
la Vista es la página HTML y el código que provee de datos dinámicos a la página; el Modelo es
el Sistema de Gestión de Base de Datos y la Lógica de negocio; el Controlador es el responsable
de recibir los eventos de entrada desde la Vista.

Siguiendo la arquitectura MVC, se contempla el desarrollo de:

 Un sistema de información web, en intranet, para registrar información de las pruebas,
bitácoras, mantenimiento y fallas todo esto bajo un esquema de autenticación y autorización
por puesto de trabajo
 Un sitio web, en internet, donde se presente información relacionada al CDA.
 Un sistema de información web, en intranet, para la gestión documental.

Ilustración 5. Modelo Vista Controlador – MVC

Para la gestión documental, se cuenta con un proceso especializado para escanear los formatos
de las revisiones técnico mecánicas, a las cuales se realizará un proceso OCR para obtener
información en texto para ser registrada en la base de datos. Las imágenes se ubicarán en el
gestor de documentos.

Ilustración 6. Flujo de datos para documentar las revisiones técnico mecánicas

Atributos de calidad

El equipo ATAM se conformó con los stakeholders que se presentan a continuación.

 Operario: Javier
 Arquitecto: Jairo
 Líder técnico: Steven
 Desarrollador: Diego
 Auxiliar Administrativo: Hermes
 Cliente: Andrea
 Usuario: Henry
 Jefe técnico: Julián
 DBA: Paola
 Infraestructura y soporte: Andrés
 RUNT: Rogerio

Los atributos de calidad definidos para el rol de operario, se presentan en el árbol de atributos
de la tabla 1.

Tabla 1. Árbol de atributos

Atributo Refinamiento Requerimiento

Seguridad Autenticación Los usuarios deben autenticarse con sus

credenciales de empleado

Fiabilidad Capacidad de Poder restablecer el sistema y recuperar los datos

recuperación afectados en una falla, en un corto tiempo.

Usabilidad Inteligibilidad Que la aplicación no entorpezca el registro de la

información
 Usabilidad Facilidad de Aplicación fácil de usar que no requiera el tener
aprendizaje manuales de usuario extensos y el tiempo máximo
para aprender a usar la aplicación no será de mas
de 20 minutos.

Usabilidad Atractividad Que la aplicación sea amigable y presente

claramente la información que se lee de los
dispositivos y que se registra

Eficiencia Tiempo de La aplicación cuenta con tiempos adecuados de

respuesta respuesta.

Conclusiones

1. El uso de diagramas permite tener una visión común para todos los stakeholders del sistema
en relación a las funcionalidades y arquitectura del sistema.
2. Conocer y comprender el negocio es vital para obtener una visión global del funcionamiento
del sistema a modelar.
3. El diseño de la arquitectura es un proceso iterativo, el cual se realiza con el propósito de
mitigar riegos relativos a la arquitectura y ayudar al entendimiento del negocio y de los
requerimientos del mismo.
4. El uso de patrones de arquitectura permite hablar con claridad y alto nivel a los participantes
del proyecto, sin necesidad de reinventar la rueda, ya que se cuenta con opciones útiles a
problemas conocidos.
5. Se proponen sistemas basados en aplicaciones web (intranet, internet) siguiendo la
arquitectura de software basada en el patrón Modelo Vista Controlador (MVC), que permite
abordar diferentes requerimientos no funcionales como construir distintas interfaces de
usuario a partir del mismo de esquema de datos, la fácil escalabilidad sin modificar el modelo
y el acceso seguro a los datos.
6. A su vez, con el patrón de flujo de datos, se establecen filtros que pueden ser remplazados /
modificados / agregados / eliminados, dando flexibilidad a las funcionalidades especificas
involucradas en cada etapa del proceso modelado.
Referencias

[1] Congreso de la Republica de Colombia (2002), Ley 769 de 2002- Código Nacional de Tránsito
Terrestre, Bogotá, D.C., Colombia

[2] ICONTEC (2010), NORMA TÉCNICA COLOMBIANA NTC 5385, Centros de Diagnóstico
Automotor. Especificaciones del Servicio, 2010-10-20, Bogotá, D.C., Colombia

[3] ICONTEC (2012), NORMA TÉCNICA COLOMBIANA NTC 5375, Revisión Técnico-Mecánica
y de Emisiones Contaminantes en Vehículos Automotores, 2012-05-16, Bogotá, D.C., Colombia

[4] Introducción a la Arquitectura de Software. http://carlosreynoso.com.ar/arquitectura-de-

software, 2009. Fecha de Consulta: noviembre/diciembre de 2018

[5] Modelado y Diseño de Arquitectura de Software. Fernando Barraza A. MS.c.

http://decc.javerianacali.edu.co/wiki/lib/exe/fetch.php?media=materias:s2_conceptosdemodelad
o.pdf. Fecha de Consulta: diciembre de 2018

[6] Arquitecturas de Software. César Javier Acuña. http://pegasus.javeriana.edu.co/~mad/

Arquitecturas de SW.pdf. Fecha de Consulta: diciembre de 2018.

[7] Architectural Patterns and Styles. Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy
http://courses.ece.ubc.ca/417/public/Designing_Architectures.pdf. Fecha de Consulta: diciembre
de 2018.