Estudio RT de Luces de Cruce II¶

Aproximación 5¶

Tras unos cuantos cambios hemos llegado a éste proyecto LucesDeCruce05.zcos .

Aquí hemos introducido muchos cambios, que pasaremos a enumerar:

• Hemos determinado que la funcionalidad “Luces Cortas” y “Luces Largas” tienen muchas cosas en común, son análogas, así que hemos puesto uno junto al otro.
• Nos interesa ver cómo ambas funcionalidades comparten el mismo “mensajero”, por lo que aunque tengamos dos grupos funcionales sólo tenemos una cadena de mensajería CAN (en el centro del diagrama). Las señales CAN se multiplexan para dar lugar al mismo mensaje CAN, podemos entender dicho mensaje CAN como la suma de las señales agrupadas bajo el mismo identificador de mensaje y que se envían a la vez.
• Para hacer menos aparatoso el diagrama, hemos encapsulado todas las salidas gráficas en un bloque.
• Para mejorar la legibilidad hemos pasado las líneas de monitorización a verde, dejando las funcionales en azul.
• Hemos cambiado el contenido de algunas de las señales que van a las gráficas, pues nos consideraba más interesante que las señales a monitorizar tuviesen retardos entre ellas, a ser posible estos retardos fuesen bien distribuidos en el tiempo.

En los sucesivos apartados mostraremos el interior de cada subbloque, pues ahí es donde radica la esencia de ésta transformación.

Bloque ECU1_luces_xxx¶

PuertoDI y Logica ECU1 ya los conocemos. Hemos añadido un bloque que hace el filtrado por tiempo de una entrada booleana. El módulo se llama Pulse Width Filter, y lo hemos metido dentro de un “wrapper”, ya que el módulo utiliza señales “flotantes” y, dentro de ECU1_luces_xxx, las necesitamos enteras.

Dentro de éste wrapper encontramos el bloque Pulse Width Filter. Para conocer el interior de dicho bloque, navegue hasta la descripción: Pulse Width Filter.

Bloque ECU2_luces_xxx¶

Éste bloque ya lo conocíamos, simplemente en ésta aproximación ha perdido su bloque CAN ECU2 INPUT, que ha pasado a ser un bloque común de ambas funcionalidades.

Bloque CANECU12ECU2¶

Éste bloque codifica el mensaje ECU12ECU2 que sale de la ECU1 y va a parar a la ECU2. En la aproximación anterior el mensaje sólo llevaba una señal, ahora llevará varias, pues pasa a ser un bloque horizontal que da servicio a varias funcionalidades.

Como vemos en el diagrama, hay un demultiplexor y un multiplexor, y hay un bloque “sample & hold” por cada señal. En realidad querríamos tener, simplemente, un bloque S/H que aceptara entradas multiplexadas, puesto que el momento en el que vamos a simular el envío periódico de la información por CAN es el mismo para todas las señales del mensaje, sin embargo hacemos éste bloque así debido a una de las Limitaciones de modelado con XCos, que es que el bloque S/H no permite más que entradas individuales.

Lo mismo sucederá con cada uno de los bloques de la cadena de transmisión del CAN (delay Bus CAN y CAN_ECU2_INPUT), cada uno de los cuales demultiplexará, procesará y volverá a multiplexar el contenido del bus.

Bloque Delay Bus CAN¶

En éste bloque hemos eliminado las conversiones de entero a flotante y viceversa. Debido a que estamos simulando un comportamiento que no va a ser programado en software funcional (el bus CAN es un bus físico gobernado por controladores hardware/software configurables cuyo software no hay que programar desde el nivel de aplicación) no tenemos especial interés en controlar los tipos durante la cadena CAN, podemos trabajar como le es más sencillo al XCos, que es en números flotantes.

Bloque CAN_ECU2_INPUT¶

El bloque ha cambiado con respecto a su diseño anterior:

• Demultiplexor para sacar las señales del bus.
• El Delay actúa ahora sobre una señal en coma flotante, por lo que simplemente hay que convertir al final a un valor entero (no hace falta el bloque Delay Binario).

Bloque de gráficas¶

Podemos ver cómo hemos encapsulado las gráficas para restarle importancia en el diagrama principal.