uCANca

h1. Estudio RT de Luces de Cruce

{{>toc}}

En el siguiente estudio vamos a diseñar un esquema en XCos para mostrar la cadena de acciones y su temporización de un caso típico en que un mensaje CAN está implicado entre que se detecta el evento y se produce la respuesta del sistema.  Para éste estudio supondremos que un usuario usa una palanca para encender las luces de un vehículo, que dicha palanca está conectada a la ECU1, que la ECU1 traslada la petición a la ECU2 mediante una señal CAN, y que la ECU2 es la que maneja las luces.

Como este estudio sirve también como documentación, iremos haciendo el esquema incrementalmente, con aproximaciones criticables y correcciones.

h2. Primera aproximación

Véase el siguiente diagrama que se encuentra en el fichero attachment:LucesDeCruce01.zcos .

{{thumbnail(LucesDeCruce01.png, size=700, title=Luces de cruce aproximación 01)}}

El diagrama muestra el camino desde la palanca del usuario hasta que se activan las luces.  Se centra en el software, de forma que los tiempos consumidos por el hardware son cero.

* En la primera parte "Palanca" vemos un interruptor que modeliza la palanca.

* En "PUERTO DI" (digital input) modelizamos el paso de señal eléctrica a variable disponible para la lógica software.

** Hay un bloque S/H que captura la entrada y la "latcha" cada X tiempo.  Éste tiempo viene marcado por un reloj, éste reloj crea un evento por cada ciclo de lectura de las entradas de la ECU1 (lo llamamos ECU1_poll_eventos).  De esa forma si nuestro ciclo de programa es 10 ms tardaremos como mucho 10 ms en ver cambiar el puerto.

** Hay un conversor que nos permite adaptar la señal XCos de valor real (double) a valor entero (byte, booleano), ya que el bloque de lógica no puede operar con valores reales.

* En "LOGICA ECU1" hemos modelizado una lógica muy sencilla: una AND con un valor positivo (es decir, realmente la lógica deja pasar el valor que nos viene del puerto DI).  Evidentemente la lógica de la ECU1 no hace sólo eso, pero como bloque a "ocupar un espacio y redefinir más adelante" ya está bien así.  La lógica también tiene su tiempo de ejecución, ECU1_logica.

* En "ENVIO CAN" también modelizamos un tiempo cíclico en el que el mensaje CAN se envía, de manera análoga a cómo lo hicimos con la lectura de "PUERTO DI".  En éste caso el tiempo es el de periodicidad del mensaje CAN: CAN_ECU12ECU2.

* A la derecha de "ENVIO_CAN" hemos añadido unos monitores para ver la salida en ese instante.

* "RECEPCION_CAN" modeliza la lectura de los mensajes CAN, con tiempo CAN_ECU2_INPUT, que es el tiempo que tarda la ECU2 en obtener los mensajes CAN que hayan llegado por el bus.

* "LOGICA_ECU2" modeliza la labor de la ECU2.  En éste caso y para hacer un poco más fácil saber que todo está bien conectado hemos hecho una lógica que es una NOT de la entrada.  Se ejecuta cada ECU2_logica tiempo.

* "PUERTO_DO" (digital output) modeliza la escritura del puerto de salida hacia las luces, que se ejecuta cada ECU2_poll_salidas tiempo.

* Por último tenemos una visualización en ese punto.

Tal como está diseñado este proyecto XCos, la luz se apagará cuando la palanca pida que esté encendido, y viceversa.  Esta no es la funcionalidad demandada, pero sirve como ilustración.

h3. Críticas

* Poco encapsulado: Más adelante utilizaremos subsistemas para encapsular cada etapa.

* No hay forma de comparara la entrada y la salida: añadiremos visualizadores gráficos que sobre un mismo lienzo pinte varias de las señales presentes en el sistema.

* Las lógicas son muy pobres: más adelante ya se cambiarán.

* No está presente el filtrado que hay que hacer a la entrada de la palanca en la ECU1 para no dar una orden de encendido de luces por una activación fortuita.

h2. Segunda aproximación.

En ésta aproximación hemos dejado el sistema sin encapsular, pues aún pensamos que didácticamente es necesario entender la cadena con los elementos básicos.  Tampoco hemos cambiado aún la lógica ni hemos aplicado filtrados.  Hemos aplicado cambios en respuesta al resto de críticas.

Fichero: attachment:LucesDeCruce02.zcos 

{{thumbnail(LucesDeCruce02.png, size=700, title=Luces de cruce aproximación 02)}}

Como puede observarse, hemos añadido unos bloques llamados Delay y Delay Binario.

* Delay es un bloque que nos proporciona XCos que puede retrasar una señal durante un tiempo determinado.  

* Delay binario es una adaptación que hemos hecho del bloque para que pueda trabajar con señales binarias, ya que Delay solo trabaja con números reales.

Hemos añadido éstos bloques para que cada etapa consuma algo de tiempo.  De lo contrario serían instantáneas y sucede, que al coincidir en el tiempo el momento en que una etapa produce una señal y otra etapa la consume, no se obtiene el esperado retardo acumulado entre etapas.

También hemos añadido una gráfica que nos permite ver cuatro señales:

* La petición justo antes de entrar en la lógica de la ECU1 (tras el puerto digital).

* La petición cuando la ECU1 la envía por CAN.

* La petición a la entradad de la lógica de la ECU2 (tras haber sido adquirida por el CAN).

* La salida digital de encendido de luces.

La gráfica resultante puede verse en 

{{thumbnail(LucesDeCruce02Graficas.png, size=700, title=Luces de cruce aproximación 02)}}

h3. Críticas

* Poco encapsulado: Más adelante utilizaremos subsistemas para encapsular cada etapa.

* Las lógicas son muy pobres: más adelante ya se cambiarán.

* No está presente el filtrado que hay que hacer a la entrada de la palanca en la ECU1 para no dar una orden de encendido de luces por una activación fortuita.

h2. Tercera aproximación

En esta iteración hemos resuelto el tema del encapsulado.

Fichero: attachment:LucesDeCruce03.zcos 

{{thumbnail(LucesDeCruce03.png, size=700, title=Luces de cruce aproximación 03)}}

Hemos procedido de la siguiente forma:

* Para hacer un subsistema hemos seleccionado todos los elementos que tenían que conformarlo y hemos ejecutado la opción "Región al superbloque".  En el interior hemos arreglado los bloques para que los caminos sean legibles siempre de izquierda a derecha.

* Hemos segregado la visualización de la funcionalidad.  No hemos querido crear salidas específicas de visualización.  Cuando ha hecho falta convertir antes de visualizar se ha puesto el conversor junto a los visualizadores, dejando el bloque resultante limpio.

En concreto, he aquí el interior del subsistema "Lógica ECU1".

{{thumbnail(LucesDeCruce03LogicaECU1.png, size=700, title=Luces de cruce aproximación 03)}}

La gráfica resultante puede verse en la siguiente ilustración.

{{thumbnail(LucesDeCruce03Graficas.png, size=700, title=Luces de cruce aproximación 03)}}

Como vemos no se comporta exactamente igual ya que, aparte de los cambios de encapsulado, la tercera gráfica (que antes se muestreaba de la línea de justo después de la lectura CAN de la ECU2, antes de ejecución de la lógica) ahora se está muestreando de la línea de después de la lógica ECU2.  Por tanto no estamos mostrando el mismo valor.

h3. Críticas

* Las lógicas son muy pobres: más adelante ya se cambiarán.

* No está presente el filtrado que hay que hacer a la entrada de la palanca en la ECU1 para no dar una orden de encendido de luces por una activación fortuita.

h2. Cuarta aproximación.

En ésta aproximación simplemente hemos encapsulado aún más.  Nótese el cambio de nomenclatura, mientras antes se hablaba de ECU1 y ECU2 ahora se habla de ECU1_luces_cortas y ECU2_luces_cortas.

Ésto se debe a que sólo estamos tratando la funcionalidad de luces cortas, y ya preveemos que muchas otras funcionalidades tendrán un tratamiento igual.  Así ECU1 sería la suma de todas las funcionalidades que la componen, entre ellas ECU1_luces_cortas.

Fichero: attachment:LucesDeCruce04.zcos 

{{thumbnail(LucesDeCruce04.png, size=700, title=Luces de cruce aproximación 04)}}

h3. Críticas

* Las lógicas son muy pobres: más adelante ya se cambiarán.

* No está presente el filtrado que hay que hacer a la entrada de la palanca en la ECU1 para no dar una orden de encendido de luces por una activación fortuita.

Seguimos en [[Estudio RT de Luces de Cruce II]].