Pulse Width Filter » History » Version 1
Txinto Vaz, 02/24/2015 12:20 PM
1 | 1 | Txinto Vaz | h1. Pulse Width Filter |
---|---|---|---|
2 | 1 | Txinto Vaz | |
3 | 1 | Txinto Vaz | 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. |
4 | 1 | Txinto Vaz | |
5 | 1 | Txinto Vaz | 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. |
6 | 1 | Txinto Vaz | |
7 | 1 | Txinto Vaz | 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. |
8 | 1 | Txinto Vaz | |
9 | 1 | Txinto Vaz | 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. |
10 | 1 | Txinto Vaz | |
11 | 1 | Txinto Vaz | h2. Especificación y plan de validación |
12 | 1 | Txinto Vaz | |
13 | 1 | Txinto Vaz | 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. |
14 | 1 | Txinto Vaz | |
15 | 1 | Txinto Vaz | Imaginemos que la especificación fuese el siguiente texto: |
16 | 1 | Txinto Vaz | * Pulse Width Filter debe ser un bloque que tome una señal booleana (entero de valores 0 o 1) y nos de una salida. |
17 | 1 | Txinto Vaz | * Inicialmente la salida ha de ser 0. |
18 | 1 | Txinto Vaz | * 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. |
19 | 1 | Txinto Vaz | * 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. |
20 | 1 | Txinto Vaz | |
21 | 1 | Txinto Vaz | Una primera aproximación de una interfaz puede verse aquí: |
22 | 1 | Txinto Vaz | |
23 | 1 | Txinto Vaz | {{thumbnail(PWF01.png, size=700, title=Diagrama de especificación y plan de validación de PWFilter 1)}} |
24 | 1 | Txinto Vaz | |
25 | 1 | Txinto Vaz | 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. |
26 | 1 | Txinto Vaz | |
27 | 1 | Txinto Vaz | Podríamos trazar un plan de validación con la siguiente forma: |
28 | 1 | Txinto Vaz | |
29 | 1 | Txinto Vaz | Test 0: Si la entrada está todo el rato a cero entonces la salida es siempre cero. |
30 | 1 | Txinto Vaz | 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á. |
31 | 1 | Txinto Vaz | 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. |
32 | 1 | Txinto Vaz | 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. |
33 | 1 | Txinto Vaz | 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. |
34 | 1 | Txinto Vaz | |
35 | 1 | Txinto Vaz | 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. |
36 | 1 | Txinto Vaz | |
37 | 1 | Txinto Vaz | Vamos a hacer una aproximación mejor: |
38 | 1 | Txinto Vaz | |
39 | 1 | Txinto Vaz | {{thumbnail(PWF02.png, size=700, title=Diagrama de especificación y plan de validación de PWFilter 2)}} |
40 | 1 | Txinto Vaz | |
41 | 1 | Txinto Vaz | En Simulación->Configuración->Asignar Contexto hemos añadido éstas constantes que nos han permitido una definición más elegante: |
42 | 1 | Txinto Vaz | |
43 | 1 | Txinto Vaz | <pre> |
44 | 1 | Txinto Vaz | T_FILT_LUCES_CORTAS = 10 |
45 | 1 | Txinto Vaz | T_CYCLE = 0.010 |
46 | 1 | Txinto Vaz | </pre> |
47 | 1 | Txinto Vaz | |
48 | 1 | Txinto Vaz | 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. |
49 | 1 | Txinto Vaz | Los test 0 y 1 toman constantes, y el resto trenes de pulsos. A continuación se listan aquí las configuraciones de: |
50 | 1 | Txinto Vaz | * test_2_input: |
51 | 1 | Txinto Vaz | ** Delay 0. |
52 | 1 | Txinto Vaz | ** Duty 50%. |
53 | 1 | Txinto Vaz | ** Period: ((T_FILT_LUCES_CORTAS-1)*2)*T_CYCLE. |
54 | 1 | Txinto Vaz | ** Amplitude: 1 |
55 | 1 | Txinto Vaz | * test_3_input: |
56 | 1 | Txinto Vaz | ** Delay 0. |
57 | 1 | Txinto Vaz | ** Duty 60%. |
58 | 1 | Txinto Vaz | ** Period: ((T_FILT_LUCES_CORTAS)*2)*T_CYCLE. |
59 | 1 | Txinto Vaz | ** Amplitude: 1 |
60 | 1 | Txinto Vaz | * test_4_input: |
61 | 1 | Txinto Vaz | ** Delay 0. |
62 | 1 | Txinto Vaz | ** Duty 50%. |
63 | 1 | Txinto Vaz | ** Period: ((T_FILT_LUCES_CORTAS+1)*2)*T_CYCLE. |
64 | 1 | Txinto Vaz | ** Amplitude: 1 |
65 | 1 | Txinto Vaz | |
66 | 1 | Txinto Vaz | De esa forma podríamos probar el funcionamiento para diferentes tiempos de ciclo y diferentes parámetros de filtrado. |
67 | 1 | Txinto Vaz | |
68 | 1 | Txinto Vaz | 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. |