Pulse Width Filter¶

El bloque Pulse Width Filter modela el comportamiento esperado para un filtro de pulso ancho. Debido a las Limitaciones de Modelado con XCos el modelado conceptual en XCos de éste módulo es bastante complicado.

El objetivo del modelado de Pulse Width Filter con XCos es poder simular el comportamiento esperado antes de implementarlo en código. El modelo es una implementación gráfica y formal utilizando un lenguaje completamente diferente al de la implementación (estamos hablando de un módulo de software). Ésto nos permitirá no sólo simular y documentar qué se espera del bloque antes de desarrollarlo, sino también es una especie de segunda implementación que, sometida a las mismas entradas, nos puede dar unos resultados diferentes de los que nos dará la implementación, y que pongan, por tanto, en duda la corrección de la misma.

El bloque, posteriormente, será implementado con software, que seguramente vendrá automáticamente generado a partir de un diseño de una máquina de estados que lo cumpla. Productiva y prácticamente hablando, sería ideal que el modelado fuese la propia máquina de estados (aunque cumpla peor la labor de poner en tela de juicio la implementación, al ser más parecida a ésta última), pero las Limitaciones de Modelado con XCos nos lo impiden.

Un posible modelado de la funcionalidad (no hacer caso a los cambios en la entrada a menos que superen una anchura mínima especificada como parámetro de la función) incluiría un sencillo contador que nos contara el tiempo de pulso y que se reseteara a cada cambio, sin embargo tampoco hemos podido llegar a ese modelado debido a las consabidas Limitaciones de Modelado con XCos. Así pues el modelado en XCos de la funcionalidad a desarrollar es bastante complejo. En ciertos casos como éste podríamos haber optado por directamente no modelar el comportamiento esperado, pues disponemos de los métodos tradicionales para validar y verificar software, pero en ésta ocasión queremos documentar el procedimiento.

Especificación y plan de validación¶

En un desarrollo según un [[method:Modelo en V]] deberíamos primero trabajar en la especificación y en el plan de validación. Así pues, nuestro modelo debe intentar ser un reflejo de ésto. En vez de desarrollar el módulo en el contexto en el que vamos a usarlo (el fichero XCos de Estudio RT de Luces de Cruce II), vamos a hacerlo en un nuevo fichero donde podamos tenerlo sólo a él y realizar las validaciones pertinentes sin para ello tener que construir y estimular todo el sistema del que forma parte.

Imaginemos que la especificación fuese el siguiente texto:

• Pulse Width Filter debe ser un bloque que tome una señal booleana (entero de valores 0 o 1) y nos de una salida.
• Inicialmente la salida ha de ser 0.
• Si la entrada cambia con respecto a la salida (p.e. la entrada pasa a 1 cuando la salida es 0), la salida sólo “seguirá” a la entrada ésta cuando haya pasado un cierto tiempo estable, sin cambiar.
• El tiempo será discreto, por lo que el parámetro de tiempo que debe usarse estará expresado en iteraciones de la ejecución del bloque.

Una primera aproximación de una interfaz puede verse aquí:

En éste diagrama vemos que la entrada y la salida se comparan en la gráfica. De ésta forma podremos ver cómo la salida sigue a la entrada a una distancia de 10 ejecuciones de la función, siempre y cuando ésta sea estable.

Podríamos trazar un plan de validación con la siguiente forma:

• Test 0: Si la entrada está todo el rato a cero entonces la salida es siempre cero.
• Test 1: Si la entrada está todo el rato a uno entonces la salida será inicialmente cero y 10 iteraciones después pasará a 1 y se mantendrá.
• Test 2: Si le pasamos un tren de pulsos como entrada, cuyo periodo sea 18 y el duty sea del 50%, entonces la salida permanecerá a 0 todo el tiempo.
• Test 3: Si le pasamos un tren de pulsos como entrada, cuyo periodo sea 20 y su duty 60% arriba, entonces la salida subirá a 1 justo 11 iteraciones después del primer flanco de subida de la entrada, permaneciendo allí todo el rato.
• Test 4: Si le pasamos un tren de pulsos de entrada, cuyo periodo sea 22 y su duty del 50%, habría que esperar que la salida cambiase a 1 justo 11 iteraciones después del primer flanco de subida, y a partir de ahí empezara a oscilar cada 11 iteraciones entre valor 0 y valor 1 dándonos como salida una señal cuadrada.

En éste momento ya tenemos una especificación y un plan de validación. Antes de desarrollar el contenido vamos a desarrollar el entorno de test del pland de validación. Después construiremos un modelo y le haremos pasar los tests, luego desarrollaremos el sistema en software y lo “embeberemos” en una copia de éste mismo entorno de validación, y verificaremos no sólo que también lo pasa, sino que además su comportamiento es “semejante” al del modelo (típicamente el software debe comportarse como un seguidor del modelo, pudiendo incluso tener un tiempo de latencia de 0 según el sistema desarrollado.

Vamos a hacer una aproximación mejor:

En Simulación→Configuración→Asignar Contexto hemos añadido éstas constantes que nos han permitido una definición más elegante:

T_FILT_LUCES_CORTAS = 10
T_CYCLE = 0.010

Como podemos ver a la izquierda, podemos seleccionar el número de test, y éste número escogerá la entrada que va a inyectarse al sistema en ésta iteración.
Los test 0 y 1 toman constantes, y el resto trenes de pulsos. A continuación se listan aquí las configuraciones de:

• test_2_input:
  • Delay 0.
  • Duty 50%.
  • Period: ((T_FILT_LUCES_CORTAS-1)*2)*T_CYCLE.
  • Amplitude: 1
• test_3_input:
  • Delay 0.
  • Duty 60%.
  • Period: ((T_FILT_LUCES_CORTAS)*2)*T_CYCLE.
  • Amplitude: 1
• test_4_input:
  • Delay 0.
  • Duty 50%.
  • Period: ((T_FILT_LUCES_CORTAS+1)*2)*T_CYCLE.
  • Amplitude: 1

De esa forma podríamos probar el funcionamiento para diferentes tiempos de ciclo y diferentes parámetros de filtrado.

Todavía podríamos darle una vuelta más a nuestro sistema de validación: añadir una gráfica que nos muestre en los momentos en los que se han producido los errores.