Rad Alt.

Universidad de Costa Rica Facultad de Ingeniera Escuela de Ingeniera Elctrica
IE 0502 Proyecto Elctrico
"VERIFICACIN DE FUNCIONAMIENTO DEL SISTEMA DE MANTENIMIENTO A BORDO PARA EL ALTMETRO DE RADIO DIGITAL DE BAJO RANGO (DIGITAL LOW RANGE RADIO ALTIMETER ONBOARD MAINTENANCE SYSTEM DLRA-OMS)"
Por: Mara Jos Amado Martnez
Ciudad Universitaria Rodrigo Facio Julio del 2008
VERIFICACIN DE FUNCIONAMIENTO DEL SISTEMA DE MANTENIMIENTO A BORDO PARA EL ALTMETRO DE RADIO DIGITAL DE BAJO RANGO (DIGITAL LOW RANGE RADIO ALTIMETER ONBOARD MAINTENANCE SYSTEM DLRA-OMS)"
Por: Mara Jos Amado Martnez
Sometido a la Escuela de Ingeniera Elctrica de la Facultad de Ingeniera de la Universidad de Costa Rica como requisito parcial para optar por el grado de: BACHILLER EN INGENIERA ELCTRICA Aprobado por el Tribunal:
_________________________________ Ing. Luca Acua Avedao Profesor Gua
_________________________________ Ing. Jorge Romero Profesor lector
_________________________________ Ing. Gustavo Cubas Lector
ii
DEDICATORIA
A mi mam que adems de los genes correctos, me brind su incondicional ayuda y su constante apoyo. Eres un orgullo seorita master. A mi pap, mi inspiracin a seguir, todo un modelo de un ingeniero. T dedicacin al trabajo y tus enseanzas me impulsaron a estudiar esta carrera. Los dos son un gran orgullo para mi, me dieron los dos mejores regalos que una persona puede recibir, primero la vida, y segundo una educacin y una carrera, los quiero muchsimo, muchas gracias por todo! A mi futuro esposo, t me inspiras a levantarme cada maana e intentar ser mejor. TE AMO.
iii
NDICE GENERAL
NDICE DE FIGURAS ................................................................................. vi NDICE DE TABLAS................................................................................. viii NOMENCLATURA...................................................................................... ix RESUMEN..................................................................................................... xi 1

1.1
CAPTULO 1: Introduccin................................................................... 1
Objetivos.................................................................................................................5 1.1.1 Objetivo general..............................................................................................5 1.1.2 Objetivos especficos ......................................................................................5
2
2.1
CAPTULO 2: Marco Terico ............................................................... 7

2.1.1 2.1.2 2.1.3 2.1.4 2.1.4.1 2.1.4.2 2.1.4.3 2.1.4.4 Estndar DO-178B..................................................................................................7 Ciclo de vida del software. .............................................................................9 Proceso de Planeacin de Software. .............................................................10 Proceso de Desarrollo de Software...............................................................11 Procesos Integrales .......................................................................................13 Garanta de Calidad ..........................................................................................13 Gestin de Calidad............................................................................................13 Enlaces de Certificacin ...................................................................................15 Verificacin ......................................................................................................15
2.1.4.4.1 Revisin ..............................................................................................15 2.1.4.4.2 Anlisis ...............................................................................................16 2.1.4.4.3 Pruebas................................................................................................17 2.2 Descripcin del sistema: El sistema de mantenimiento a bordo para el Altmetro de Radio Digital de bajo rango. ............................................................................................19 2.2.1 Intefaz con el usuario....................................................................................20 2.2.2 Modo Normal................................................................................................21 2.2.3 Modo Interactivo...........................................................................................21 2.2.4 Gestor de NVM.............................................................................................22 2.2.5 Equipo de prueba empotrado (BITE)............................................................22 2.2.6 Inicializacin del sistema..............................................................................22 2.2.7 Traductor de Fallas. ......................................................................................22 2.2.8 Unidad de Software de computadora, funcin principal MAIN...................23 2.3 Lenguaje C............................................................................................................24 iv
2.4 2.5
Code Composer Studio .....................................................................................25 ASTAT..................................................................................................................26
3
3.1 3.2 3.3 3.4 3.5 3.6 3.7
CAPTULO 3: Requerimientos............................................................ 28
XX01.....................................................................................................................30 XX02.....................................................................................................................30 XX03.....................................................................................................................31 XX04.....................................................................................................................32 XX05.....................................................................................................................32 XX06.....................................................................................................................33 XX07.....................................................................................................................33
4
4.1 4.2 4.3 4.4 4.5 4.6 4.7
CAPTULO 4: Casos de prueba........................................................... 35

Casos de prueba para XX01..................................................................................36 Casos de prueba para XX02..................................................................................37 Casos de prueba para XX03..................................................................................37 Casos de prueba para XX04..................................................................................39 Casos de prueba para XX05..................................................................................40 Casos de prueba para XX06..................................................................................40 Casos de prueba para XX07..................................................................................41
5
5.1 5.2 5.3 5.4
CAPTULO 5: Procedimientos de prueba .......................................... 43

Procedimiento de prueba para el XX01 y el XX02 ..............................................44 Procedimiento de prueba para el XX03................................................................47 Procedimiento de prueba para el XX04................................................................48 Procedimiento de prueba para el XX05................................................................50
6
6.1 6.2 6.3 6.4
CAPTULO 6: Pruebas 6...................................................................... 53

Resultados de pruebas para el XX01 y XX02. .....................................................53 Resultados de pruebas para el XX03. ...................................................................58 Resultados de pruebas para el XX04. ...................................................................62 Resultados de pruebas para el XX05, XX06 y XX07...........................................65
7 8
8.1 8.2
CAPTULO 7: Anlisis de Cobertura Estructural............................. 74 CAPTULO 8: Conclusiones y recomendaciones ............................... 80

Conclusiones.........................................................................................................80 Recomendaciones .................................................................................................81
BIBLIOGRAFA.......................................................................................... 82 ANEXOS ....................................................................................................... 84
NDICE DE FIGURAS
Figura 1.1 Ciclo de vida del SW .................................................................... 2 Figura 2.1 Ciclo de vida del sistema SW ...................................................... 9 Figura 2.2 Proceso de Revisin.................................................................... 16 Figura 2.3 Anlisis de cobertura estructural por nivel de software ......... 18 Figura 2.4 Concepto de Altmetro de radio bsico .................................... 20 Figura 5.1 Funcin de transmisin alterada .............................................. 47 Figura 5.2 Funcin de cmputo de paridad alterada. ............................... 47 Figura 5.3 Procedimiento de prueba para XX03 ....................................... 48 Figura 5.4 Extracto alterado del cdigo de la funcin ProcessLabel065066. .................................................................................... 50 Figura 5.5 Procedimiento de prueba para XX05, XX06 y XX07.............. 52 Figura 6.1 Paso 49 del procedimiento de prueba del XX01 y XX02......... 54 Figura 6.2 Paso 52 del procedimiento de prueba del XX01 y XX02......... 54 Figura 6.3 Paso 56 del procedimiento de prueba del XX01 y XX02......... 56 Figura 6.4 Paso 59 del procedimiento de prueba del XX01 y XX02......... 56 Figura 6.5 Paso 150 del procedimiento de prueba del XX01 y XX02....... 57 Figura 6.5 Paso 153 del procedimiento de prueba del XX01 y XX02....... 57 Figura 6.6 Paso 2 del procedimiento de prueba del XX03. ....................... 58 Figura 6.7 Paso 3 del procedimiento de prueba del XX03. ....................... 59 Figura 6.8 Paso 10 del procedimiento de prueba del XX03. ..................... 60 Figura 6.9 Reporte de resultados de ASTAT, XX03, paso 2..................... 61 Figura 6.10 Reporte de resultados de ASTAT, XX03, paso 3................... 61 Figura 6.11 Reporte de resultados de ASTAT, XX03, paso 10................. 61 Figura 6.12 Paso 19 del procedimiento de prueba del XX04. ................... 62
vi
Figura 6.13 Paso 37 del procedimiento de prueba del XX04. ................... 63 Figura 6.14 Paso 46 del procedimiento de prueba del XX04. ................... 64 Figura 6.15 Paso 54 del procedimiento de prueba del XX04. ................... 65 Figura 6.16 Paso 2 del procedimiento de prueba de XX05, XX06 y XX07. ....................................................................................................................... 66 Figura 6.17 Paso 3.1 del procedimiento de prueba de XX05, XX06 y XX07.............................................................................................................. 66 Figura 6.18 Paso 3.2 del procedimiento de prueba de XX05, XX06 y XX07.............................................................................................................. 67 Figura 6.19 Paso 14 del procedimiento de prueba de XX05, XX06 y XX07. ....................................................................................................................... 68 Figura 6.20 Paso 15.1 del procedimiento de prueba de XX05, XX06 y XX07.............................................................................................................. 69 Figura 6.21 Paso 15.2 del procedimiento de prueba de XX05, XX06 y XX07.............................................................................................................. 70 Figura 6.22 Paso 16 del procedimiento de prueba de XX05, XX06 y XX07. ....................................................................................................................... 70 Figura 6.23 Paso 17 del procedimiento de prueba de XX05, XX06 y XX07. ....................................................................................................................... 71 Figura 6.24 Reporte de resultados de ASTAT, paso 3............................... 72 Figura 6.25 Reporte de resultados de ASTAT, paso 15............................. 72 Figura 6.26 Reporte de resultados de ASTAT, paso 17............................. 73 Figura 7.1 Pantalla del analizador antes de correr la prueba. ................. 75 Figura 7.2 Pantalla del analizador despus de correr la prueba. ............. 75 Figura 7.3 Texto extrado de la prueba. ..................................................... 76 Figura 7.4 Extracto del anlisis de cobertura estructural......................... 77 Figura 7.5 Reporte de cobertura estructural de ProcessLabel065066 . 78 Figura 7.6 Resumen del reporte de cobertura estructural de ProcessLabel065066 ................................................................................. 78
vii
NDICE DE TABLAS
Tabla 2.1 Relacin entre niveles de certificacin, objetivos e independencia ................................................................................................. 8 Tabla 3.1 Caractersticas de un requerimiento....................................... 29 Tabla 4.1: Contenidos de un caso de prueba.............................................. 35 Tabla 4.2: Casos de prueba para XX01...................................................... 36 Tabla 4.3: Caso de prueba para XX02 ....................................................... 37 Tabla 4.4: Casos de prueba para XX03...................................................... 38 Tabla 4.6: Casos de prueba para XX04...................................................... 39 Tabla 4.6: Casos de prueba para XX05...................................................... 40 Tabla 4.7: Casos de prueba para XX06...................................................... 40 Tabla 4.8: Casos de prueba para XX07...................................................... 41 Tabla 5.1: Estructura de un procedimiento de prueba ............................. 43 Tabla 5.2: Extracto del procedimiento de prueba del XX01 y el XX02 ... 44 Tabla 5.3: Extracto del procedimiento de prueba del XX04 .................... 49
viii
NOMENCLATURA
ASTAT Avionyx Software Test Automation Tool. Herramienta de automatizacin de pruebas de Avionyx. CCS CSC Computadora. CSU DLRA Rango. FAA Federal Aviation Administration. Administracin Federal de Computer Software Unit. Unidad de software de computador. Digital Low Range Altimeter. Altmetro de Radio Digital de Bajo Code Composer Studio. Compilador de lenguaje C. Computer Software Components. Componentes de Software de
Aviacin de Estados Unidos. FT GEL Faults translator. Traductor de fallas General Extension Language (Basado en C de la TI) Lenguaje General de extensin HI HW IM MAIN McBSP NM NVM OMS OMSSDD Host Interface. Interfaz con el usuario. Hardware. Componentes fsicos de un computador. Interactive Mode. Modo Interactivo. Funcin principal. Multi-channel Buffered Serial Port (estndar de Texas Instruments) Normal Mode. Modo Normal Non-volatile Memory. Memoria no voltil. On Board Maintenance System. Sistema de Mantenimiento a bordo. Documento de Especificacin de Requerimientos de Software para el
Sistema de Mantenimiento a bordo del Altmetro de Radio Digital. OMSSRS Documento de Descripcin de Diseo de Software para el Sistema
de Mantenimiento a bordo del Altmetro de Radio Digital. PDS RF Procesador de Seal Digital. Radio frecuencia ix
RTCA DO-178B
Software Considerations in Airborne Systems and Equipment
Certification. Es un estndar de certificacin de software. Tambin ser llamado simplemente DO-178B SI SVCP System Initialization. Inicializacin del sistema Software Verification Cases and Procedures. Casos y Procedimientos
de Verificacin de Software. SVR SVP SW Software Verification Report. Reporte de verificacin de software. Software Verification Plans. Planes de verificacin de software Software. Componentes lgicos de un computador.
RESUMEN
El DO-178B, Software Considerations in Airborne Systems and Equipment Certification es el estndar para el desarrollo de software aceptado por la Administracin Federal de Aviacin de Estados Unidos (FAA: Federal Aviation Administration.) como medio de certificacin de software en aviacin. El objetivo de este proyecto consiste en la verificacin del funcionamiento del mdulo de interfaz con el hardware del DLRA-OMS. Este proceso se realiza con el objetivo de verificar los requerimientos del equipo e identificar los errores en su diseo de software para as prevenir un fallo en el sistema de la aeronave y poder dar confianza de su seguridad. Para verificar este mdulo, se crearon una serie de casos de prueba en el capitulo 4: Casos de prueba, los cuales se implementaron en procedimientos de prueba, capitulo 5: Procedimientos de Prueba. Estas pruebas se ejecutaron y se analizaron los resultados obtenidos. Tambin, se realiz un anlisis de cobertura estructural. Una prueba puede fallar por distintas razones. Puede deberse a fallos en el requerimiento, errores en el cdigo, pruebas incorrectas o deficiencias en las herramientas utilizadas. Es posible no obtener una cobertura estructural del 100%. Esto es aceptable si se determina que las lneas que no fueron levantadas son cdigo desactivado.
xi
CAPTULO 1: Introduccin
Cuando se trata de vidas humanas nunca se consideran demasiadas las medidas de
seguridad, de aqu que para los sistemas de aviacin es de gran importancia desarrollar equipos que ayuden a minimizar la cantidad de accidentes. Si bien es cierto la mayora de los accidentes son ocasionados por errores humanos por parte del piloto, el disminuir su carga laboral y presentar la informacin de vuelo de forma ms accesible ayuda considerablemente a evitar situaciones de peligro. A inicios de los aos 80, se hizo popular el uso de sistemas digitales en avinica, de aqu surgi la necesidad de establecer guas de calidad para estos. La Administracin Federal de Aviacin de Estados Unidos (FAA-Federal Aviation Administration), que es la autoridad certificadora de ese pas, recomienda el uso del estandar DO-178B (Software Considerations in Airborne Systems and Equipment Certification) como un medio pero no el nico medio para verificar un sistema. La FAA certifica el sistema en general, no solo el software (SW), de aqu que el hardware (HW) tambin debe ser aprobado. Sin embargo, el DO-178B se refiere solamente a la certificacin de SW. El DO-178B fue creado en consenso por la comunidad de avinica. Describe los objetivos y actividades para los procesos de software. En l se define el ciclo de vida de un programa en 3 partes bsicas, el planeamiento, el desarrollo y los procesos integrales. El planeamiento define los medios para producir el software que van a satisfacer los requerimientos del sistema. En el desarrollo, se crea el programa, este consta de 4 fases, la 1
creacin de requerimientos de alto nivel, el diseo, que consiste en los requerimientos de bajo nivel y la arquitectura del software, escribir el cdigo y finalmente la integracin del SW con el HW, para lo que se necesita el cdigo objeto ejecutable. Por otro lado, los procesos integrales consisten en el Proceso de Verificacin, el proceso de Gestin de la Configuracin de Software, el proceso de Garanta de Calidad del software y los Enlaces de Certificacin. El ciclo de vida se puede entender mejor en la figura 1.1.
Figura 1.1 Ciclo de vida del SW [1] Como se puede ver en esta figura, los procesos integrales se realizan de forma paralela, tanto al proceso de planeacin como al proceso de desarrollo del SW y hasta se extiende aun despus de que estos dos han concluido. Es importante destacar que entre estos procesos existe retroalimentacin, de aqu que si en el desarrollo se encuentra un problema, este puede modificar las salidas del proceso de planeamiento.
Este trabajo se va a enfocar en el proceso de verificacin de software. El DO-178B define 5 niveles de certificacin de software (A, B, C, D y E), los cuales dependen de los efectos de una falla en la nave, los pasajeros y la tripulacin, siendo A el nivel ms alto. La verificacin del Sistema de Mantenimiento a bordo (OMS) del Altmetro de Radio Digital de Bajo Rango (DLRA) se va a hacer bajo el nivel C. enfoca en el Mdulo de Interfaz con el HW. Para certificar un sistema a nivel C se deben cumplir 57 de los objetivos presentados en el DO-178B. Sin embargo, se puede verificar que cumpla ms, esto para hacer el sistema ms confiable, el problema con esto es que se incrementan los costos de desarrollo. Algunos de estos objetivos requieren de independencia. La independencia se refiere a que la verificacin la debe realizar una persona ajena al proceso de desarrollo. El DO-178B identifica 3 tipos de verificacin, la revisin, el anlisis y las pruebas. La revisin generalmente est guiada por una lista de objetivos que deben ser cumplidos. La revisin proporciona una opinin, o anlisis cualitativo del sistema. Existen revisiones formales e informales. Las revisiones informales generalmente son realizadas por colegas. Por otro lado, para una revisin formal se convoca a una reunin en la que se discuten los errores encontrados y se toma una decisin acerca de si tomar accin correctiva o no. La decisin debe ser respetada y no se le pueden hacer cambios no autorizados al artefacto en revisin. Este proyecto se
El anlisis puede examinar la funcionalidad, funcionamiento, trazabilidad e implicaciones de seguridad de los componentes de SW y su relacin con otros componentes dentro del sistema o equipo. Finalmente, el proceso de prueba consiste en ejercitar un sistema o componente con el fin de verificar que cumple los requerimientos y detectar errores. El DO-178B pide que se realicen pruebas basadas en los requerimientos, lo cual quiere decir que todos los requerimientos deben ser probados. Se requiere tambin que el sistema cumpla con Anlisis de Cobertura Estructural, esto es que todas las estructuras del cdigo sean ejercitadas en las pruebas, lo cual no es lo mismo que pruebas de Cobertura Estructural. Para lograr Cobertura estructural existen 3 tipos de anlisis, los cuales dependen del nivel del SW, as para un nivel D o E no se necesita, para un nivel C se requiere Cobertura de Declaraciones, para un nivel B, Cobertura de Decisiones y para un nivel A Condicin Modificada/Cobertura de Decisiones. La Cobertura de Declaraciones consiste en que todas las declaraciones en un sistema sean invocadas al menos una vez. La Cobertura de Decisiones implica que todos los puntos de entrada y salida en el programa y todas las decisiones hayan tomado todos los resultados posibles al menos una vez. Y la Condicin Modificada/Cobertura de Decisiones dice que todos los puntos de entrada y salida en el programa y todas las decisiones hayan tomado todos los resultados posibles al menos una vez y que adems que se vea que cada condicin en una decisin afecta la salida de esta.
El proceso de verificacin tiene el objetivo de encontrar errores, sin embargo una vez encontrados estos errores no es responsabilidad del verificador corregirlos, sino nicamente comunicarlos al desarrollador del sistema.
1.1 Objetivos
1.1.1 Objetivo general
Verificar el correcto funcionamiento del mdulo de interfaz con el hardware a partir del conjunto de requerimientos de software que describen dicho mdulo dentro del DLRAOMS.
1.1.2 1
Objetivos especficos
Escribir un conjunto de casos de prueba a partir de los requerimientos de software a examinar incluyendo pruebas para analizar el comportamiento del sistema en condiciones inesperadas.
Escribir procedimientos para implementar los casos de prueba escritos en el objetivo anterior.
Realizar anlisis de cobertura estructural del cdigo fuente a partir de la ejecucin de los casos de prueba.
1.2
Metodologa
La metodologa para realizar este proyecto consistir en el desarrollo de casos de prueba basados en requerimientos para el interfaz con el usuario del DLRA-OMS, proporcionados por la empresa. Procedimientos para los casos de prueba y finalmente se realizara anlisis de cobertura estructural del cdigo.
2
2.1
CAPTULO 2: Marco Terico

Estndar DO-178B
La principal diferencia entre crear software para equipo de aviacin y otro tipo de
software se encuentra en el estndar RTCA DO-178B (Software Considerations in Airborne Systems and Equipment). Este fue desarrollado por la Comisin Tcnica de Radio para Aeronutica (Radio Technical Comisin for Aeronoutics, Inc: RTCA) para definir los lineamientos necesarios para la creacin de software a utilizar en aviacin y es el documento aceptado por la FAA como medio de certificacin de este. El nivel de certificacin del software depende de los efectos de una condicin de falla en el sistema. Este nivel se determina del Proceso de Valoracin de Seguridad y Anlisis de Peligro. De acuerdo al DO-178B las condiciones de falla estn divididas de la siguiente forma:
Catastrfica: Una falla puede producir que la aeronave se estrelle, as como mltiples muertes en los pasajeros y tripulacin. Peligrosa: Gran impacto negativo en la seguridad o funcionalidad de la aeronave. Reduccin de la capacidad de la tripulacin para operar la aeronave debido a aflicciones fsicas o una elevada carga de trabajo. Lesiones fatales o serias a los pasajeros.
Mayor: Impacto negativo considerable en la seguridad o funcionalidad de la aeronave. Reduccin de la capacidad de la tripulacin para operar la aeronave
debido a aflicciones fsicas o una incrementada carga de trabajo. Posibles lesiones para los pasajeros. Menor: Incomodidad fsica para los pasajeros o cambio de plan de vuelo. Sin efecto: Sin impacto en la seguridad u operacin de la aeronave o en la tripulacin. Posibles inconveniencias para los pasajeros. La cantidad de objetivos, ya sea con o sin independencia, que un sistema debe cumplir depende del nivel del software. La relacin entre el nmero de objetivos y el nivel de certificacin se puede ver en la tabla 2.1.
Tabla 2.1 Relacin entre niveles de certificacin, objetivos e independencia. [4]
Nivel
Condicin de falla
Objetivos
Con independencia
Catastrfica
66
25
Peligrosa
65
14
Mayor
58
Menor
28
Sin efecto
Como se puede ver en la tabla, cuanto mayor sea el efecto de la falla mayor ser la cantidad de objetivos a cumplir, y la independencia de estos, as para una falla Catastrfica de deben cumplir 66 requerimientos, de los cuales 25 deben ser con independencia. Aunque se observa la diferencia entre certificar a nivel A y a B es un solo requerimiento a cumplir, ms adelante se ver que este requerimiento es de gran importancia e implica bastante ms trabajo cumplirlo.
2.1.1
Ciclo de vida del software. El ciclo de vida de un sistema de avinica no solo se compone del ciclo de vida del
software. Es importante considerar la definicin del hardware y las limitaciones de este, antes de comenzar con el desarrollo del software. En la figura 2.1 se puede observar el ciclo de vida de un sistema de aviacin y su relacin con el ciclo de vida del software.
Figura 2.1 Ciclo de vida del sistema SW [2] 9
Como se percibe en la imagen, el ciclo de vida del software tiene como entradas los requerimientos del sistema referidos al software, el nivel de certificacin del software, la definicin del hardware y las limitaciones de diseo. Por otro lado, tiene como salidas los limites de contencin de error, las fuentes de error, ya sea que hayan sido eliminadas, o solamente identificadas y finalmente la arquitectura y requerimientos del software. El ciclo de vida del software est compuesto por 3 partes bsicas, el planeamiento, el desarrollo y los procesos integrales, como se puede ver en la figura 1.1. A continuacin, se hablar ms detalladamente de ellos.
2.1.2
Proceso de Planeacin de Software. Este proceso tiene como objetivos definir las actividades del Proceso de Desarrollo
del software y de los procesos integrales, determinar las interrelaciones entre los procesos, su secuencia, los mecanismos de retroalimentacin y los criterios de transicin. En este proceso, se definen estndares para desarrollo de software consistentes con los objetivos de seguridad del sistema. En esta etapa, se debe coordinar el desarrollo y la revisin de planes para el software que cumplan con el DO-178B. El Plan de Desarrollo de software establece los medios para cumplir los objetivos del proceso de desarrollo de software, adems del ambiente de desarrollo a utilizar. Existen 3 estndares de desarrollo de software, el Estndar para Requerimientos de Software, el Estndar para Diseo de Software y el Estndar para Programacin de Software.
10
En el Estndar para Requerimientos de software, se definen los mtodos, reglas y herramientas a utilizar en el desarrollo de los requerimientos de alto nivel de abstraccin. Los requerimientos de alto nivel de abstraccin son aquellos que describen la funcionalidad del software al nivel de funciones, sin dar mucho detalle del cdigo de implementacin. En el Estndar para Diseo de software, se especifican los mtodos, reglas y herramientas a utilizar en el desarrollo de la arquitectura del software y los requerimientos de bajo nivel de abstraccin. Los requerimientos de bajo nivel de abstraccin describen el software al nivel de las instrucciones de cdigo, proveen detalle acerca del cdigo a ejecutar. Finalmente, el Estndar para Programacin de Software define los lenguajes de programacin, mtodos, reglas y herramientas a utilizar en el proceso de programacin e implementacin del software.
2.1.3
Proceso de Desarrollo de Software. El DO-178B acepta diferentes ciclos de desarrollo de software, estos son: Software Previamente desarrollado o Comercial: Consta de los procesos de requerimientos e integracin de software. Componente simple: Consta de requerimientos, codificacin e integracin. Catarata tradicional: Requerimientos, diseo, codificacin e integracin. Prototipo: Requerimientos, codificacin, integracin, codificacin,
integracin, requerimientos, diseo, codificacin y finalmente integracin.
11
El DO-178B provee una descripcin breve de los procesos de requerimientos, diseo, programacin e integracin, pues estos tienden a variar segn la metodologa de diseo aplicada. El Proceso de Requerimientos de Software tiene como objetivo establecer los requerimientos de alto nivel, as como indicar el proceso de Valoracin de seguridad del sistema para los requerimientos derivados. La salida de este proceso es el Documento de Requerimientos de Software, el cual contiene la definicin de los requerimientos de alto nivel de abstraccin, incluyendo los requerimientos derivados. En el Proceso de Diseo de Software se deben establecer los requerimientos de bajo nivel de abstraccin y la arquitectura del software. Aqu, tambin se pueden presentar requerimientos derivados, por lo que se debe indicar el proceso de Valoracin de seguridad para estos. La salida de este proceso es la Descripcin del Diseo de software, en este se definen los requerimientos de bajo nivel de abstraccin y la arquitectura del software, que va a satisfacer los requerimientos de alto nivel. El Proceso de Programacin de Software consiste en el desarrollo del Cdigo Fuente de forma que sea verificable y consistente, este debe implementar correctamente los requerimientos de bajo nivel de abstraccin. La salida es el Cdigo Fuente. Finalmente, en el Proceso de Integracin se genera el Cdigo Objeto Ejecutable, el cual se carga en el hardware, para lograr as la integracin de estos. El lenguaje utilizado depende del proyecto, este puede ser lenguaje C, C++, Pascal, ADA, a nivel de lenguaje de ensamblador, entre otros.
12
2.1.4
Procesos Integrales Los procesos integrales estn divididos en Verificacin del Software, Garanta de
Calidad del Software, Gestin de Calidad del Software y los Enlaces de Certificacin. Estos procesos se dan durante todo el ciclo de vida del software, es decir que ocurren de forma paralela tanto al proceso de Planeacin como al proceso de Desarrollo de Software. 2.1.4.1 Garanta de Calidad El objetivo de este proceso es obtener garanta de que los procesos del software cumplen con los planos y estndares aprobados, garanta de que el criterio de transicin para los procesos del ciclo de vida del software se satisfacen y de que una revisin de conformidad de los productos de software se realiza. El gerente de Garanta de Calidad de Software debe ser independiente al equipo de desarrollo y verificacin de software. Este se encarga de auditar el desarrollo de software y los procesos integrales, y demostrar que los planes y estndares se siguieron. Aunque se permiten algunas desviaciones de los planes o estndares, estas deben ser documentadas y justificadas. 2.1.4.2 Gestin de Calidad Algunos de los objetivos de este proceso son: Proveer control de las entradas y salidas de los procesos. Proveer la habilidad para replicar el Cdigo Objeto Ejecutable.
13
Proveer un punto para revisin conocido, evaluando estado y control de cambios por medio del control de los objetos de gestin y el establecimiento de puntos de referencia.
Asegurar que se mantiene archivo y control seguro de los objetos de gestin. Se encarga del proceso de reporte de errores.
En el proceso de gestin de calidad es importante crear suficientes documentos que hagan posible replicar el sistema en caso de un nuevo proyecto o para entender las causas de un posible accidente. De aqu que todo debe ser archivado por el tiempo que una aeronave que utilice ese software contine operando. Una vez que un documento o artefacto ha sido publicado, a este no se le pueden realizar cambios no autorizados, de aqu que el proceso de gestin de calidad debe analizar si el cambio es necesario o no, y se debe realizar un Anlisis de Impacto por el cambio, es decir se debe analizar todo lo que este cambio pueda afectar, ya sea dentro del mismo documento, o artefacto u otros. Cuando se encuentra un problema se nombra una directiva compuesta por miembros del equipo de desarrollo, gestin de producto y el gerente de Garanta de seguridad. Esta directiva es la encargada de analizar el problema y decidir si se debe hacer el cambio o no. Si se aprueba un cambio al documento, se realiza el anlisis de impacto y se cambia cualquier otro documento o artefacto afectado. Estos cambios deben ser documentados.
14
2.1.4.3 Enlaces de Certificacin El objetivo de este proceso es establecer comunicacin y entendimiento entre el solicitante y la Autoridad Certificadora. Se debe proveer evidencia a la Autoridad Certificadora de que el ciclo de vida del Software cumple con los planes y estndares aprobados.
2.1.4.4 Verificacin De acuerdo al DO-178B el proceso de verificacin se define como la evaluacin tcnica de los resultados de los procesos de desarrollo de software y de los procesos de verificacin de software. El objetivo general es detectar y reportar errores que pueden haber sido introducidos durante los procesos de desarrollo de software. Este proceso, sin embargo no se encarga de corregir los errores, esto es parte del proceso de desarrollo de software. De acuerdo al DO-178B existen 3 mtodos de verificacin, la revisin, el anlisis y las pruebas.
2.1.4.4.1
Revisin
Proveen una evaluacin cualitativa de exactitud. Usualmente se utiliza una lista, la cual es definida en el Plan de Verificacin de Software. Para hacer una revisin se llama a una reunin a la que deben asistir el autor (la persona que escribi el artefacto que va a ser revisado), el moderador (el conductor de la reunin), el escriba (es la persona encargada de tomar nota, es decir producir un registro de 15
la reunin) y los revisores del documento. En estas reuniones algunos participantes pueden tener varios roles, sin embargo, aunque el autor puede ser un revisor, no puede ser el nico, ni puede ser el escriba o moderador. Se debe producir un registro con los defectos encontrados y la forma en que fueron tratados. En la figura 2.2 se puede ver el proceso de revisin por el que pasa un artefacto.
Figura 2.2 Proceso de Revisin [2] 2.1.4.4.2 Anlisis
Un anlisis puede examinar en detalle la funcionalidad, operacin, relacin e implicaciones de seguridad de un componente de software y su relacin con otros componentes dentro del sistema o equipo de aviacin. Un anlisis produce evidencia repetible de exactitud. El anlisis se puede utilizar cuando una prueba en especfico no se puede desarrollar para probar la exactitud de la implementacin de un requerimiento. 16
2.1.4.4.3
Pruebas
Hacer pruebas es el proceso de ejercitar un sistema o componente para verificar que satisface requerimientos especficos y para detectar errores. Los objetivos de las pruebas son: Demostrar que el software satisface los requerimientos. Demostrar con un alto grado de confianza que los errores que podran llevar a una falla inaceptable sean removidos. Probar un software constituye gran parte del esfuerzo del desarrollo de este. Para un sistema crtico, las pruebas son las que requieren ms trabajo. El proceso de prueba es destructivo, los analistas deben desarmar el cdigo, por esto no es aceptable que el autor pruebe su propio cdigo. El proceso de pruebas puede tomar mucho tiempo, probar un sistema exhaustivamente no es prctico, se debe encontrar la ptima cantidad de pruebas que cumplan con el estndar DO-178B y provean una buena relacin costo/beneficio. La salida del proceso de prueba es el documento Casos y Procedimientos de Verificacin de Software (Software Verification Cases and Procedures: SVCP), el cual est compuesto de casos de prueba y su respectivo procedimiento. Un caso de prueba es un grupo de entradas, condiciones de prueba y resultados esperados, mientras que un procedimiento de prueba son los pasos para la ejecucin de los casos de prueba.
17
Existen dos categoras para los casos de prueba, normal y robusto. Un caso de prueba normal demuestra la habilidad del software pare responder a condiciones y entradas normales. Un caso de prueba robusto demuestra la habilidad del software para responder a condiciones y entradas anormales. El DO-178B requiere pruebas basadas en los requerimientos y que se realice anlisis de cobertura estructural, el cual se refiere a analizar que toda la estructura del cdigo sea ejercitada por medio de pruebas. El tipo de anlisis de cobertura estructural depende del nivel del software. En la siguiente figura 2.3 se puede ver como se debe realizar este anlisis para los diferentes niveles de Software.
Figura 2.3 Anlisis de cobertura estructural por nivel de software. [2] La Cobertura de Declaraciones consiste en que todas las declaraciones en un sistema sean invocadas al menos una vez.
18
La Cobertura de Decisiones implica que todos los puntos de entrada y salida en el programa y todas las decisiones hayan tomado todos los resultados posibles al menos una vez. Y la Cobertura de Decisin/Condicin Modificada dice que todos los puntos de entrada y salida en el programa y todas las decisiones hayan tomado todos los resultados posibles al menos una vez y que adems que se vea que cada condicin en una decisin afecta la salida de esta. El objetivo de ms a cumplir para el nivel A, de acuerdo al estndar DO-178B se refiere a la Cobertura de Decisin/Condicin Modificada.
2.2 Descripcin del sistema: El sistema de mantenimiento a bordo para el Altmetro de Radio Digital de bajo rango.
El Altmetro de Radio Digital (DLRA) utiliza la tcnica de onda continua de frecuencia de banda ancha modulada para medir la distancia entre el avin y el terreno en un rango de -20 a +5700 pies. El DLRA transmite una seal RF de frecuencia modulada en una onda triangular y recibe la seal despus de que esta se refleja en el suelo. La altitud se calcula determinando la diferencia entre la frecuencia de la seal reflejada y la frecuencia de la seal al instante en que la seal reflejada es recibida. Esta frecuencia es directamente proporcional al tiempo requerido para que la seal viaje la distancia del avin al piso y de vuelta al avin. En la figura 2.4 se puede ver esta operacin.
19
Figura 2.4 Concepto de Altmetro de radio bsico. [5]*
El Sistema de Mantenimiento a Bordo (OMS-DLRA) se encarga de manejar las fallas que puedan presentarse en el sistema, as como de registrarlas para recuperarlas luego. Asimismo es el encargado de realizar las pruebas de funcionamiento de los procesadores de clculo de altura. El software del OMS-DLRA se organiza en 7
Componentes de Software de Computadora (Computer Software Components: CSC), los cuales se descomponen a su vez en unidades de software (Computer Software Unit: CSU), la Interfaz con el Usuario (HI), Modo Normal (NM), Modo Interactivo (IM), Gestor de NVM (Memoria no voltil) (NVM), Equipo de Prueba empotrado (BITE), Inicializacin de sistema (SI) y Traductor de fallas (FT) y una Unidad de Software de computadora (Computer Software Unit: CSU), la funcin principal (MAIN).
2.2.1
Intefaz con el usuario. La interfaz con el usuario es responsable de controlar el flujo de datos con el
usuario, datos de CMS, fallas internas y externas, datos de inter-procesador entre el modo 20
Normal, el Interactivo, el gestor de NVM y BITE como est distribuido y procesado en el software del OMS. La interfaz con el usuario maneja los datos y estados de falla actuales para poder mantener la ejecucin apropiado del software del OMS. El cdigo para esta funcin est escrito en C.
2.2.2
Modo Normal. El Modo Normal es el responsable de todos los procesamientos normales. Utiliza la
ltima informacin de vuelo y los datos de falla actuales para construir y transmitir el bloque de etiquetas 356. El bloque 356 contiene los datos que soportan el modo normal. Durante el modo normal las fallas sern actualizadas. El sistema revisa la memoria, para ver si se han agregado nuevas fallas, el nmero de estas y la clase. Esta informacin se incluye en el bloque 356 y se envan al Interfaz con el usuario cada 100 ms.
2.2.3
Modo Interactivo. El modo interactivo realiza la interaccin con el sistema de mantenimiento de
cmputo durante el modo interactivo. Es el responsable de controlar cual men se muestra y de salir de modo interactivo, ya sea cuando el estado de vuelo cambia de en el suelo a en el aire o el usuario decide salir. Existen varios mens interactivos para el usuario que incluyen la informacin de las fallas, la opcin de iniciar una prueba de funcionamiento, limpiar el estudiar de fallas, entre otros.
21
2.2.4
Gestor de NVM. La memoria no voltil se utiliza para mantener los registros de las fallas. El
procesador se encarga de registrar la bitcora de los fallos del sistema (DLRA) en la NVM. De forma que una vez que el FT ha definido la unidad de informacin de la falta esta es registrada en memoria por medio del mdulo de manejo de memoria.
2.2.5
Equipo de prueba empotrado (BITE).
Consiste en una serie de funciones que permiten mantener el control del estatus de si mismo. Estas funciones se encargadan de verificar el estado de la memoria. Se evala la funcionalidad de las locaciones de memoria mediante una prueba a cada locacin de memoria y por separado se analiza la integridad del programa mediante el clculo de una prueba de redundancia cclica (CRC). 2.2.6 Inicializacin del sistema. La inicializacin del sistema es responsable de configurar el software y Hardware del OMS. Contiene informacin para configurar el temporizador del software, la comunicacin por medio de los buses con el procesador, el acceso a memoria, las interrupciones, entre otros.
2.2.7
Traductor de Fallas.
El OMS mantiene una bitcora completa de los fallos que le ocurren en su propio funcionamiento y principalmente los fallos en los procesadores de clculo de altitud (PDSP y MDSP). Estas fallas son reportadas a travs de los buses ARINC 429 que se conectan 22
mediante una interfaz a los puertos McBSP del procesador del OMS-DLRA. Los datos all transmitidos deben transformarse en una unidad estndar de datos de forma que la informacin ms importante asociada (fecha, hora, fuente de error, procesador asociado, etc.) pueda luego ser analizada.
2.2.8
Unidad de Software de computadora, funcin principal MAIN. El software del OMS-DLRA esta definido por el control de un ciclo principal con
interrupciones definidas. Para tener un control de caractersticas de manejo de la pila (stack) y la capacidad de procesamiento (throughput) las diferentes funcionalidades estn organizadas en grupos que se ejecutan a diferentes frecuencias de forma que se distribuya la carga de trabajo. Las funciones ms importantes se ejecutan a la mayor frecuencia y las dems se distribuyen segn su prioridad. Hay rutinas que no se manejan dentro del ciclo principal del programa sino como interrupciones. Estas son las rutinas de atencin de los puertos de comunicacin con el procesador principal (PDSP) y con el procesador monitor (MDSP). Estos puertos son los McBSP (Puerto Serial Bufferizado Multi-canal). El sistema tambin posee la interrupcin del temporizador que determina la unidad de procesamiento cada 5ms y la interrupcin externa de fallo de potencia.
23
2.3 Lenguaje C.
C es un lenguaje de programacin de nivel medio, ya que combina los elementos del lenguaje de alto nivel con la funcionalidad del ensamblador. Sus instrucciones consisten de trminos que se asemejan a expresiones algebraicas, adems de ciertas palabras claves en ingls como if (si condicional), else (si no), for (para), do (haga) y while (mientras). C contiene un gran nmero de operadores, los cuales facilitan la redaccin de programas fuente muy concisos. C tiene un repertorio de instrucciones muy pequeo, sin embargo al incluir funciones de biblioteca, se mejoran las instrucciones bsicas. Otra caracterstica importante de C es que los programas son muy portables, esto se debe a que las funciones de biblioteca se encargan de la mayora de las caractersticas de la computadora. El acceso a cada funcin de biblioteca es idntico en todas las versiones de C, de esta forma, la mayora de los programas en C se pueden compilar y ejecutar en muchas computadoras diferentes prcticamente sin modificaciones. En C todo programa consta de uno o varios mdulos llamados funciones. La funcin principal llamada main es la primera en ejecutarse. Esta puede acceder a las otras funciones. Cada funcin debe contener: Una cabecera de funcin, esto es el nombre de esta con una lista de argumentos (smbolos que representan entradas al programa). Una lista de declaracin de argumentos Una instruccin compuesta, que contiene el resto de la funcin.
24
El lenguaje C se cre principalmente para la programacin en sistemas UNIX, sin embargo se utiliza tambin para el desarrollo de otros sistemas operativos como Windows o Linux. Es muy usado en aplicaciones cientficas, industriales, simulaciones de vuelo, etctera; es decir, se aplica en diversas reas. El mayor problema que presenta el desarrollo con el lenguaje C es que su velocidad de desarrollo es mucho menor a los lenguajes de tipo de dato dinmico. Por otro lado, los programas terminados en C presentan una mejor utilizacin de los recursos de hardware. El mantenimiento tambin es ms difcil y costoso que con el resto de lenguajes [11]. Hay compiladores de C disponibles para computadores de diversos tipos. Un compilador es un programa informtico que traduce un programa escrito en un lenguaje de programacin a una representacin en cdigo binario que la mquina ser capaz de interpretar. El compilador que se utilizar en este proyecto es el Code Composer Studio (CCS) , versin 3.3.
2.4 Code Composer Studio

Este compilador fue creado por Texas Instruments. Este es un entorno de programacin que se usa para implementar varios algoritmos y cargar cdigo en un Procesador de Seal Digital (PSD).
25
CCS tiene herramientas y soporte de software para aplicaciones de tiempo real de sistemas empotrados. Permite a diseadores de PSD moverse rpidamente entre cada fase del proceso de desarrollo, incluyendo diseo, codificacin y construccin del cdigo objeto ejecutable, depuracin, anlisis y mejoras. El CCS tiene las siguientes caractersticas: Editor, depurador y director de proyectos integrado. Puntos de prueba conectados al archivo de entradas/salidas, pantalla grafica, o escritos de GEL (GEL es un entorno de programacin de Java). Anlisis avanzado de seales grficas. Lenguaje de scripts de GEL para pruebas automatizadas y caracterizacin del entorno. Sistema visual de manejo de proyectos.
2.5 ASTAT.
La herramienta de automatizacin de pruebas de Avionyx, ASTAT (Avionyx Software Test Automation Tool) es una aplicacin creada en la empresa que facilita la verificacin y validacin basada en requerimientos por medio de sus scripts de alto nivel e interfaz grfica. La caracterstica clave de esta herramienta es su capacidad de encapsular detalles de comunicacin de programacin de bajo nivel en un lenguaje basado en JavaScript, que 26
soporta un enfoque de tipo paso a paso. Este lenguaje es mejorado con comandos especficos que proveen capacidad de temporizador, manipulacin de mensajes definidos por el usuario, verificacin de resultados automatizada y guiada por el usuario y la generacin de reportes de resultados de pruebas, entre otros.
27
CAPTULO 3: Requerimientos
Los requerimientos del Interfaz de usuario del Sistema de Mantenimiento a bordo
del Altmetro de Radio digital estn divididos en requerimientos de alto nivel y requerimientos de bajo nivel. Los requerimientos de alto nivel son aquellos que describen el sistema de forma ms general, sin entrar en mucho detalle. Por otro lado los requerimientos de bajo nivel deben ser lo suficientemente especficos como para poder escribir cdigo a partir de ellos. Hay situaciones en las que los requerimientos de alto nivel son lo suficientemente detallados como para escribir cdigo a partir de ellos, en estos casos no se necesitan requerimientos de bajo nivel. Los requerimientos de alto nivel se documentan en el documento de Especificacin de Requerimientos de Software para el Sistema de Mantenimiento a bordo del Altmetro de Radio Digital (OMSSRS). Mientras que los requerimientos de bajo nivel se encuentran en el documento de Descripcin de Diseo de Software para el Sistema de Mantenimiento a bordo del Altmetro de Radio Digital (OMSSDD). Un requerimiento se define como la descripcin concisa y clara de lo que un sistema debe cumplir [5]. En la tabla 3.1 se definen las caractersticas que debe contener todo requerimiento de forma que en conjunto puedan definir al sistema.
28
Tabla 3.1
Caractersticas de un requerimiento. [5]

Descripcin El requerimiento debe tener tan solo una posible interpretacin. La salida para un set de entradas y estados iniciales debe ser uniequvoca. Corto y fcil de leer e interpretar pero contiene toda la informacin necesaria. No contradice lo descrito por otro requerimiento y utiliza un formato y trminos con el mismo significado y al estilo de otros requerimientos. Contiene toda la informacin necesaria y no es necesario leer ningn otro requerimiento para su entendimiento. Debe ser una caracterstica realista que pueda ser implementada con los recursos disponibles del sistema. El requerimiento puede ser comprobado por medio de cuatro posibles mtodos: Anlisis, inspeccin, demostracin o prueba. Los requerimientos deben ser suficientes pero no deben haber ms que redunden pues eso afectar su mantenibilidad Debe definir claramente su rastro hacia los objetivos, diseo y cdigo. Nada en el requerimiento debe ser implcito Para funciones generales comunes a muchos proyectos debera estar especificado de forma que su reutilizacin sea viable. Su impacto sobre el sistema debe ser determinado pues esto influir en el nfasis dado durante los procesos de desarrollo y en la verificacin.
Caracterstica Determinista y preciso Conciso Consistente Completo Alcanzable Verificable No redundantes Rastreable Explcitos Reutilizable Criticalidad anotada
Como se describi en captulos anteriores, el DO-178B requiere que se hagan pruebas basadas en los requerimientos, sin ver el cdigo que se va a verificar. El nmero de pruebas para cada requerimiento depende del tipo de requerimiento y de la cantidad de condiciones que este posea, as como tambin del nivel otorgado al software (de acuerdo con la Tabla 2.1). En este proyecto se verificarn 72 requerimientos de bajo nivel. Estos requerimientos fueron aportados a Avionyx por un cliente y son de carcter confidencial.
29
Los requerimientos a tratar se relacionan con las colas de transmisin y recepcin de datos del sistema. El sistema se debe verificar a nivel C, de los niveles descritos en el DO-178B. Para verificar a este nivel se debe cumplir con Cobertura de Decisin, sin embargo, para lograr mejor cobertura, se puede verificar a un nivel ms alto, de aqu que se hagan ms pruebas de las necesarias. A continuacin de detallarn los requerimientos a tratar en este proyecto. La totalidad de estos no se puede proveer, sin embargo, aqu se especificarn los ms significativos de estos. Se cambiaron los nombres de los requerimientos por cuestin de confidencialidad.
3.1 XX01
El OMS deber aadir el bit de paridad, (bit 32) a la palabra de datos seleccionada, de forma que esta contenga paridad par.[5] Este requerimiento es sencillo, se realiza una sola accin, la cual depende de la paridad de la palabra, si la palabra es par, el bit de paridad es 1, si es impar el bit de paridad ser 0. Se necesitan 2 casos de prueba.
3.2 XX02
El OMS deber dividir la palabra de datos de 32 bits en una LO WORD (palabra baja) y HI WORD (palabra alta). [5] Esta operacin se ejecutar siempre que se desee enviar una palabra, de aqu que solo se necesita un caso de prueba, ya que no se tiene ningn tipo de condicin para la divisin de la palabra.
30
3.3 XX03
Mientras la cola de recepcin de McBSP1 no este vaca, el OMS deber sacar de la cola los datos recibidos y guardarlos en el siguiente destino, si la palabra contiene paridad vlida: 052: Cola 052 del Monitor 054: Cola 054 del Monitor 060: Cola 060 del Monitor 066: Cola 066 del Monitor 125: Arreglo de etiquetas del Monitor 260: Arreglo de etiquetas del Monitor 227: Arreglo de etiquetas del Monitor 301: Arreglo de etiquetas del Monitor 302: Arreglo de etiquetas del Monitor 303: Arreglo de etiquetas del Monitor 155: Arreglo de etiquetas del Monitor 156: Arreglo de etiquetas del Monitor 057: Arreglo de etiquetas del Monitor. [5]
Este requerimiento, a pesar de que parece sencillo, tiene 13 posibles resultados, dependiendo de la palabra de datos recibida, el destino de esta puede tener varias colas. Para verificar este requerimiento correctamente se necesita un caso de prueba para cada
31
etiqueta con paridad vlida, y un caso de prueba para cada etiqueta con paridad invlida, y finalmente un caso de prueba en el que la cola este vaca; es decir un total de 27 pruebas.
3.4 XX04
Si los datos de InitData son vlidos, el OMS deber hacer los datos de la etiqueta 227 en el arreglo de etiquetas del Monitor igual a este valor, hacer la cuenta de frescura (FreshCount) igual a 3 y llamar a la funcin ProcessLabel227. [5] Para este requerimiento se pueden tener datos vlidos, o datos invlidos, que son los 2 casos de prueba posibles. Lo interesante es que se debe llamar una funcin, lo cual se ve claramente en el procedimiento de prueba, pues en el caso de prueba, el resultado esperado es ambiguo.
3.5 XX05
Si la cola de la etiqueta 065 no est vaca, el OMS deber extraer el valor del voltaje (ADC), bits 9 al 22, usando la siguiente frmula: ADCValue= ((Label065 & 003FFF00) >> 8). [5]
Este requerimiento incluye una ecuacin. Se requieren 2 casos de prueba, uno en el que la cola est vaca, y uno en el que no est vaca. La frmula toma el valor de la etiqueta 065, y de esta extrae lo bits del 9 al 22, en los que se guarda el valor de voltaje. Estos bits se mueven 8 espacios a la derecha, pues la
32
variable ADCValue consta de 4 bytes, y para capturar el valor entero, se deben tener los bits importantes en la palabra menos significativa de la etiqueta.
3.6 XX06
Si la cola de la etiqueta 066 no est vaca, el OMS deber extraer el valor del voltaje (ADC), bits 9 al 22, usando la siguiente frmula: ADCValue= ((Label066 & 003FFF00) >> 8). [5]
Este requerimiento incluye una. Se requieren 2 casos de prueba, uno en el que la cola est vaca, y uno en el que no est vaca. La frmula toma el valor de la etiqueta 066, y de esta extrae lo bits del 9 al 22, en los que se guarda el valor de voltaje. Estos bits se mueven 8 espacios a la derecha, pues la variable ADCValue consta de 4 bytes, y para capturar el valor entero, se deben tener los bits importantes en la palabra menos significativa de la etiqueta.
3.7 XX07
El OMS deber guardar los valores de ADC vlidos calculados en XX05 y XX06 en el arreglo ADCValueArray basado en lo siguiente:
33
ADC Value Array Location 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Label 065 065 065 065 065 065 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066 066
Word Index 0x00 0x01 0x02 0x03 0x04 0x05 0x00 0x01 0x05 * 0x07 * 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C
[5]
34
CAPTULO 4: Casos de prueba

Para verificar que los requerimientos nombrados en el captulo 3 se escribieron
diferentes casos de prueba, dependiendo del tipo de requerimiento. Para escribir estos casos de prueba se utiliza una tabla de la siguiente forma:
Tabla 4.1: Contenidos de un caso de prueba

Requerim iento Descripci n de la prueba Caso de prueba Normal / Robusto Condicione s iniciales Resumen de variables de entrada Resumen de resultados esperados Mtodo de prueba Tipo de prueba Procedi miento de prueba Come ntario s
OMSSD Dxxx
Esta prueba verifica que
OMSTC xxxx
xxx
xxx
xxxx
xxxx
xxxx
xxx
OMSTP xxx
En esta tabla, la descripcin de la prueba y el nmero de caso de prueba deben ser nicos. Los casos de prueba robustos se refieren a situaciones que el sistema no espera. El resumen de variables de entrada y de resultados esperados es una forma ms cmoda de acomodar estos, pues como se ve en el anexo 1, la lista de estos puede ser bastante larga. El mtodo de prueba habla del procedimiento de prueba, ya sea que esta debe hacerse de forma manual, o por medio de un escrito, que la automatiza. El tipo de prueba puede ser de caja blanca (en la que se cambian valores o se ponen puntos de alto dentro del programa), de caja negra (en el que se meten entradas y se revisan las salidas sin observar el cdigo) o mixto. El procedimiento de prueba se refiere al procedimiento que contiene la verificacin del caso de prueba en cuestin y finalmente la columna de comentarios es para agregar informacin adicional que se pueda necesitar.
35
Para las pruebas se vern solo las columnas de descripcin, Normal/Robusto, condiciones iniciales, Resumen de variables de entrada, resumen de resultados esperados, mtodo de prueba y tipo de prueba.
4.1 Casos de prueba para XX01

Como se vio en el captulo anterior para este requerimiento se necesitan 2 casos de prueba, uno para el caso en donde se tiene paridad par y otro para el caso de paridad impar. Estos se definen de la siguiente manera: Tabla 4.2: Casos de prueba para XX01
Descripcin de la prueba Este caso de prueba verifica que el bit de paridad es aadido a la palabra de datos seleccionada para las etiquetas de transmisin, cuando la paridad es par. Este caso de prueba verifica que el bit de paridad es aadido a la palabra de datos seleccionada para las etiquetas de transmisin, cuando la paridad es impar. Normal / Robusto Condiciones iniciales Resumen de variables de entrada Resumen de resultados esperados Mtodo de prueba Tipo de prueba
Normal
El sistema est corriendo
Bits [30-0] contienen un nmero par de unos
El bit 31 de la palabra es igual a 1 cuando los bits [30-0] contienen un nmero par de unos
Manual
Caja blanca
Normal
Bits [30-0] contienen un nmero impar de unos
El bit 31 de la palabra es igual a 0 cuando los bits [30-0] contienen un nmero impar de unos
Manual
Caja blanca
36

El caso de prueba para este requerimiento es:
Tabla 4.3: Caso de prueba para XX02

Descripcin de la prueba Esta prueba verifica que cada una de las palabras de 32 bits seleccionadas es dividida en LO WORD y HI WORD Normal / Robusto Condiciones iniciales Resumen de variables de entrada Resumen de resultados esperados Mtodo de prueba Tipo de prueba
Normal
Etiqueta = 0xFFFF8000
LoWord =0x8000 Manual HiWord =0xFFFF
Caja blanca

Como se vio en la seccin 3.3, para verificar este requerimiento se necesitan 27
casos de prueba diferentes, de los cuales 13 se refieren al caso en el que se recibe cada una
de las diferentes etiquetas con paridad vlida. Trece se refieren al caso en que se tiene cada
una de las diferentes etiquetas, pero con paridad invlida, y el ltimo caso de prueba se
refiere al caso en que la cola est vaca. En la siguiente tabla, se ve un caso con etiqueta
vlida y un caso con etiqueta invlida para una de estas. Adems, se ve el caso de la cola
vaca. 37
Tabla 4.4: Casos de prueba para XX03

Descripcin de la prueba Esta prueba verifica que mientras la cola de recepcin no est vaca, los datos recibidos (si contienen paridad vlida) son sacados de la cola y guardados en el destino correspondiente, para la etiqueta 052. Esta prueba verifica que mientras la cola de recepcin no est vaca, los datos recibidos (si no contienen paridad valida) son sacados de la cola pero no guardados en el destino correspondiente, para la etiqueta 052. Esta prueba verifica que si la cola de recepcin est vaca, nada se saca de la cola. Normal / Robusto Condiciones iniciales Resumen de variables de entrada Etiqueta = 052 con paridad valida (0x00000054) La Cola McBSP1 Rx no est vaca Origen de la etiqueta = Procesador de Monitor Destino de la etiqueta = Cola del Monitor 052 Etiqueta = 052 con paridad invlida (0x80000054) La Cola McBSP1 Rx no est vaca Origen de la etiqueta = Procesador de Monitor Destino de la etiqueta = Cola del Monitor 052 Origen de le etiqueta = Procesador de Monitor La etiqueta 052 no se guarda en la cola del Monitor 052 Caja blanca La etiqueta 052 se guarda un la cola del Monitor 052 Resumen de resultados esperados Mtodo de prueba Tipo de prueba
Normal
Manual
Caja blanca
Robusto
Manual
Robusto
La Cola McBSP1 Rx est vaca
Nada se saca de la cola.
Manual
Caja blanca
38

Descripcin de la prueba Esta prueba verifica que si InitData es vlido el OMS hace los datos de la etiqueta 227 en el arreglo del Monitor iguales a InitData, FreshCount igual a 3 y llama la funcin ProcessLabel227 Esta prueba verifica que si InitData es invlido el OMS no hace los datos de la etiqueta 227 en el arreglo del Monitor iguales a InitData, FreshCount es igual a 0 y no se llama la funcin ProcessLabel227 Normal / Robusto Condiciones iniciales Resumen de variables de entrada Etiqueta = 227 Origen de la etiqueta = Procesador del Monitor InitData es vlido InitData.Label227 es igual a 0x0F0F0F0F Etiqueta = 227 Origen de la etiqueta = Procesador del Monitor InitData es vlido InitData.Label227 es igual a 0x0F0F0F0F La etiqueta 227 no se hace igual a InitData (ParametricData Array[1][233].LabelWord= 0x00000000) FreshCount=0 No se llama a ProcessLabel227. La etiqueta 227 se hace igual a InitData (ParametricData Array[1][233].LabelWord= 0x0F0F0F0F) FreshCount=3 Se llama a ProcessLabel227. Resumen de resultados esperados Mtodo de prueba Tipo de prueba
Normal
InitData fue ledo de la memoria no voltil (NVM)
Manual
Caja blanca
Robusto
InitData fue ledo de la memoria no voltil (NVM)
Manual
Caja blanca
39

Descripcin de la prueba Esta prueba verifica que si la cola de la etiqueta 065 no est vaca, el valor ADC (bits 9 al 22) se extrae usando la frmula: ADCValue = ((Label065 & 003FFF00)>>8) Esta prueba verifica que si la cola de la etiqueta 066 est vaca, el valor ADC no se extrae. Normal / Robusto Condiciones iniciales Resumen de variables de entrada Etiqueta = 065 La cola de etiqueta 066 de Primario no est vaca Origen de etiqueta= Cola de etiqueta 065 de Primario Valor de ADC=0x0000 Etiqueta = 065 Origen de etiqueta= Cola de etiqueta 065 de Primario Valor de ADC=0x0000 Resumen de resultados esperados Mtodo de prueba Tipo de prueba
Normal
ADCValue = ((Label065 & 003FFF00)>>8)
Manual
Caja blanca
Robusto
La cola de etiqueta 065 de Primario est vaca
ADCValue = 0x0000
Manual
Caja blanca

Descripcin de la prueba Esta prueba verifica que si la cola de la etiqueta 066 no est vaca, el valor ADC (bits 9 al 22) se extrae usando la frmula: Normal / Robusto Condiciones iniciales Resumen de variables de entrada Etiqueta = 066 Origen de etiqueta= Cola de etiqueta 066 de Monitor Valor de ADC=0x0000 Resumen de resultados esperados Mtodo de prueba Tipo de prueba
Normal
La cola de etiqueta 066 de Monitor no est vaca
Manual
Caja blanca
40
Esta prueba verifica que si la cola de la etiqueta 066 est vaca, el valor ADC no se extrae.
Robusto
La cola de etiqueta 066 de Monitor est vaca
Etiqueta = 066 Origen de etiqueta= Cola de etiqueta 066 de Monitor Valor de ADC=0x0000
ADCValue = 0x0000
Manual
Caja blanca

Descripcin de la prueba Esta prueba verifica que los valores vlidos de ADC obtenidos de la etiqueta 065 son guardados en ADCValueArray dependiendo del ndice cuando WordIndex =0x00 Esta prueba verifica que los valores de ADC obtenidos de la etiqueta 065 no son guardados en ADCValueArray si WordIndex es mayor que 5 Normal / Robusto Condiciones iniciales Resumen de variables de entrada Etiqueta = 065 Origen de etiqueta= Cola de etiqueta 065 de Primario WordIndex =0x00 Valor de ADC=2132 Etiqueta = 065 Origen de etiqueta= Cola de etiqueta 065 de Primario WordIndex =0x06 Valor de ADC=0100 Resumen de resultados esperados Mtodo de prueba Tipo de prueba
Normal
Un valor de ADC fue calculado de la etiqueta 065
ADCValueArray[0]=2132
Manual
Caja blanca
Robusto
Ningun valor en ADCValueArray es igual a 0100
Manual
Caja blanca
41
Esta prueba verifica que los valores vlidos de ADC obtenidos de la etiqueta 066 son guardados en ADCValueArray dependiendo del ndice cuando WordIndex =0x00 Esta prueba verifica que los valores de ADC obtenidos de la etiqueta 066 no son guardados en ADCValueArray si WordIndex es igual a 2
Etiqueta = 066 Origen de etiqueta= Cola de etiqueta 066 de Monitor WordIndex =0x00 Valor de ADC=1111 Etiqueta = 066 Origen de etiqueta= Cola de etiqueta 066 de Monitor WordIndex =0x00 Valor de ADC=0100
Normal
ADCValueArray[6]=1111
Manual
Caja blanca
Robusto
Ningun valor en ADCValueArray es igual a 0100
Manual
Caja blanca
42
CAPTULO 5: Procedimientos de prueba

Los procedimientos de prueba describen los pasos a seguir para cumplir con los
casos de prueba descritos en el captulo anterior. Los procedimientos de prueba si estn basados en el cdigo. Lo primero que se debe hacer es un procedimiento de inicializacin del equipo y del programa. Para poder cumplir con los casos de prueba se pueden hacer archivos de puntos de alto, programas de GEL y programas en ASTAT. En este proyecto se utilizarn los archivos de puntos de alto y los programas en ASTAT. Un procedimiento puede enfocarse solamente a un requerimiento, o cubrir varios. Para cubrir varios, en un mismo grupo de pasos se agregan varios pasos de verificacin. En la compaa, Avionyx, para este proyecto se utilizaron tablas para el procedimiento estructuradas de la siguiente forma:
Tabla 5.1: Estructura de un procedimiento de prueba

PASO Instruccin Resultados esperados Resultados obtenidos Paso/Falla El resultado obtenido es el esperado: S_____ No____ OMSTP xxx Casos de prueba Comenta rios
Haga.
Verifique que.
En esta tabla, el paso se refiere al orden que se debe llevar en la realizacin de la prueba, la instruccin es la indicacin de la accin que se debe realizar. Los resultados
43
esperados son los que se deben obtener, de acuerdo al requerimiento, mientras que los resultados obtenidos son aquellos que se consiguen luego de realizar la prueba. Paso/Falla se refiere a la comparacin del resultado obtenido con el resultado esperado, si estos son iguales la prueba pasa, en caso contrario esta falla. Caso de prueba se refiere al caso de prueba con el que el paso de verificacin est relacionado. Finalmente, la columna de comentarios es para que la persona que corra la prueba aada informacin que considere pertinente. A continuacin, se vern los procedimientos que se crearon para cumplir con los casos de prueba del captulo 4.
5.1 Procedimiento de prueba para el XX01 y el XX02

Los pasos faltantes al inicio del procedimiento de la tabla 5.1 se refieren al procedimiento de inicializacin y a pasos para la verificacin de otros casos de prueba.
Tabla 5.2: Extracto del procedimiento de prueba del XX01 y el XX02 (los puntos de alto se indican abajo)
PASO Instruccin Agregue Data a la ventana (watch window) Permita que el sistema contine su ejecucin [presione F5] Asegrese de que el punto de alto [ BP_OMSTP20101_ 031 ] sea alcanzado Resultados esperados Resultados obtenidos Paso/Falla Casos de prueba Comentarios
46
47
48
44
49
50
Haga *Data igual a 0x7FFF8000 Permita que el sistema contine su ejecucin [presione F5] Asegrese de que el punto de alto [ BP_OMSTP20101_ 004 ] sea alcanzado El resultado obtenido es el esperado: Verifique que *Data sea igual a 0xFFFF8000 Aada LoWord y HiWord a la ventana Permita que el sistema contine su ejecucin [presione F5] Asegrese de que el punto de alto [ BP_OMSTP20101_ 005 ] sea alcanzado El resultado obtenido es el esperado: Verifique que LoWord sea igual a 0x8000 Permita que el sistema contine su ejecucin [presione F5] Asegrese de que el punto de alto [ BP_OMSTP20101_ 006 ] sea alcanzado El resultado obtenido es el esperado: Verifique que HiWord sea igual a 0xFFFF S _____ No _____ OMST C2010 9 S _____ No _____ OMST C2010 9 S _____ No _____ OMST C2011 4
51
52
53
54
55
56
57
58
59
45
. . .
. . .
. . .
. . .
. . .
. . .
. . .
150
Haga *Data igual a 0x7FFFC000 Permita que el sistema contine su ejecucin [presione F5] Asegrese de que el punto de alto [ BP_OMSTP20101_ 004 ] sea alcanzado El resultado obtenido es el esperado: Verifique que *Data sea igual a 0x7FFFC000 S _____ No _____ OMST C2011 5
151
152
153
La funcin que est siendo probada en este procedimiento es la de transmisin de datos, esta es McBSPTX, la cual est en la figura 5.1. En esta figura se ve el cdigo alterado ya que estos son propiedad del cliente y son confidenciales. La funcin ComputeParity se encarga de agregar el bit de paridad a la palabra, lo que se puede ver en la figura 5.2. Al igual que en la figura 5.1, este cdigo se encuentra alterado. Los puntos de alto son los marcados en rojo en las figuras. Entre parntesis se puede ver el nombre de estos puntos de alto.
46
Figura 5.1 Funcin de transmisin alterada
Figura 5.2 Funcin de cmputo de paridad alterada.
5.2 Procedimiento de prueba para el XX03.

Para este procedimiento se utiliz un script de ASTAT. Esta prueba est semiautomatizada. En la figura 5.3 se puede ver un extracto del procedimiento. Aqu se ve la implementacin de los casos de prueba de la seccin 4.3. Los pasos faltantes en el procedimiento se refieren a la inicializacin y al procesamiento de las otras etiquetas. En el anexo 2 se ven las funciones Golabelo() y Golabele(); estas se refieren al envo de etiquetas con paridad impar y par, respectivamente.
47
Figura 5.3 Procedimiento de prueba para XX03

Los casos de prueba para el requerimiento XX04 tienen varias salidas, incluyendo la llamada a una funcin. Para verificar estas salidas se van a necesitar varios pasos, adems de un punto de alto dentro de la funcin que es llamada.
48
Tabla 5.3: Extracto del procedimiento de prueba del XX04

PASO Instruccin Agregue CheckSum a la ventana (watch window) Agregue InitData a la ventana (watch window) Haga InitData.CheckSum igual a 0 Presione F5 Asegurese de que BP_OMSTP20200_ 003 sea alcanzado Presione F5 Verifique que BP_OMSTP2020 0_003 es alcanzado de nuevo, sin alcanzar BP_OMSTP2020 0_004 Verifique que ParametricDataAr ray[1][233].Label Word y ParamtricDataArr at[1][233].FreshC ount son iguales a 0. Haga InitData.Label227 igual a 0x0F0F0F0F Presione F5 Asegurese de que BP_OMSTP20200_ 004 sea alcanzado Verifique que ParametricDataAr ray[1][233].Label Word es igual a 0x0F0F0F0F Verifique que ParametricDataAr El resultado obtenido es el esperado: S _____ No _____ El resultado obtenido es el El resultado obtenido es el esperado: S _____ No _____ Resultados esperados Resultados obtenidos Paso/Falla Casos de prueba Comentarios
15
16
17 18
19 20
21
OMST C2022 9 OMST C2024 7
El resultado obtenido es el esperado: S _____ No _____
22 37 43 44
OMST C2022 9
45
46
OMST C2020 4 OMST C2020
49
ray[1][233].Fresh Count es igual a 3 53 Presione F5 Verifique que BP_OMSTP2020 0_006 sea alcanzado
esperado: S _____ No _____ El resultado obtenido es el esperado: S _____ No _____
54
OMST C2020 4

Este es otro ejemplo de procedimiento escrito en ASTAT. En este caso, se va a ver primero un extracto del cdigo.
Figura 5.4 Extracto alterado del cdigo de la funcin ProcessLabel065066.
En la figura 5.4 se puede ver que antes de calcular el valor de ADCValue se lee el ndice para ver si este es menor o igual a 5, para el caso de la etiqueta 065. En el
50
requerimiento XX05 esta condicin no est especificada, por lo que cuando se tiene un valor con ndice 6, el valor debe ser extrado y calculado, el requerimiento XX07 es el que dice que cuando el ndice es mayor que 6 el valor no debe ser guardado en el arreglo. El requerimiento XX05 va a fallar debido a una inconsistencia del requerimiento con el cdigo. Cuando se encuentran errores de este tipo, estos deben ser reportados al cliente, para que este haga las modificaciones que considere pertinentes. De igual forma va a pasar con el requerimiento XX06 cuando se prueben ndices de 2, 3, 4, 6 o mayores que 28 (0x1C). Como las pruebas deben escribirse basadas en el requerimiento, aun despus de ver el error en el cdigo se debe esperar que un valor de ADC sea calculado, es por esto que el requerimiento va a fallar. En la figura 5.5 se ver el script creado para estos 3 requerimientos.
51
Figura 5.5 Procedimiento de prueba para XX05, XX06 y XX07.
52
CAPTULO 6: Pruebas
Para realizar las pruebas es preferible que los procedimientos de prueba sean
llevados a cabo por una persona diferente a quien escribi el SVCP (documento que incluye casos y procedimientos de prueba), esto para lograr independencia, aun si el nivel C no requiere de independencia. Para el anlisis de este proyecto, se realizaron pruebas preliminares con los documentos, pues las pruebas formales aun no estn programadas para ser realizadas. A continuacin se presentan los resultados de estas.
6.1 Resultados de pruebas para el XX01 y XX02

Al correr el procedimiento de la tabla 5.2, se obtienen los resultados de los casos de prueba escritos para cada requerimiento. Con esto es que se puede determinar si el requerimiento fall o no. En la figura 6.1 se puede ver el sistema detenido en el punto de alto BP_OMSTP20101_031 (el puntero indica la instruccin que el sistema ejecutar a continuacin y el punto rojo indica el punto de alto). Como variable de entrada se tiene que *Data es igual a 0x7FFF8000. En la figura 6.2 se ve que luego de ejecutar la funcin (el sistema en el punto de alto BP_OMSTP20101_004) el valor de *Data es 0xFFFF8000.
53
Figura 6.1 Paso 49 del procedimiento de prueba del XX01 y XX02.
Si nos vamos a la tabla 4.2, en la columna de Resumen de resultados esperados se ve que se espera que el bit 31 de la palabra sea igual a 0 o a 1, dependiendo de la cantidad de unos presentes en la palabra. Si en hexadecimal la palabra es 0x7FFF8000, en binario esto se leer como 0111 1111 1111 1111 1000 0000 0000 0000, esta palabra contiene 16 unos, como 16 es una cantidad par de unos, se espera que el bit 31 (el primer bit) sea uno, es decir 1111 1111 1111 1111 1000 0000 0000 0000, o 0xFFFF8000 en hexadecimal.
54
Al comparar este resultado con el obtenido de la figura 6.2, se puede ver que para el primer caso de prueba de la tabla 4.2, la prueba pasa. Sin embargo, aun no se puede decir que el requerimiento pasa, pues primero se debe correr el segundo caso de prueba. Ahora, al continuar corriendo el programa, el sistema debe detenerse en el punto de alto BP_OMSTP20101_005, lo cual se puede ver en la figura 6.3. En este punto, se verifica el resultado, el cual de acuerdo a la tabla 4.3, columna de resultados esperados, debe ser LoWord = 0x8000. En la figura 6.3 se puede ver que este valor si es igual a 0x8000. En la tabla 4.3 se espera un resultado de LoWord = 0x8000 y de HiWord = 0xFFFF sin embargo, en la figura 6.3 HiWord es igual a 0x0000, lo cual podra significar que la prueba falla. Sin embargo, si se va al procedimiento de prueba de la tabla 5.2, se puede ver que la implementacin del caso de prueba para el requerimiento XX02 aun no ha finalizado. El siguiente punto de alto debe ser ejecutado para observar el cambio en HiWord. En la figura 6.4 se ve el resultado de esta ejecucin, y que efectivamente HiWord es igual a 0xFFFF.
55
Como ya se tiene el caso de prueba con los resultados esperados iguales a los obtenidos, este caso de prueba se puede marcar como aprobado, al igual que el requerimiento, ya que todos los casos de prueba (solo se tena uno) fueron aprobados.
56
El siguiente paso en el procedimiento de la tabla 5.2 se refiere al requerimiento XX01. Aqu, se prueba el segundo caso de prueba de este requerimiento. Para empezar, se tiene una palabra con un nmero impar de unos, como se ve en la figura 6.5, se tiene 0x7FFFC000 (0111 1111 1111 1111 1100 0000 0000 0000), la cual contiene 17 unos. De la tabla 4.2, el resultado esperado es que el bit 31 de la palabra sea 0, es decir 0111 1111 1111 1111 1100 0000 0000 0000, o 0x7FFFC000 en hexadecimal.
Figura 6.5 Paso 150 del procedimiento de prueba del XX01 y XX02. En la figura 6.6, se observa el resultado obtenido de la prueba, 0x7FFFC000, el cual es el mismo esperado por el caso de prueba, de aqu que el caso de prueba pas.
Figura 6.5 Paso 153 del procedimiento de prueba del XX01 y XX02. 57
Ahora, se tiene que ambos casos de prueba para el requerimiento XX01 obtuvieron como resultado el mismo que se esperaba, es decir, ambos casos de prueba pasaron, de aqu que el requerimiento es aprobado.
6.2 Resultados de pruebas para el XX03.

Este procedimiento est escrito en ASTAT, sin embargo, requiere de interaccin con el Code Composer Studio, por lo que no se le puede llamar un procedimiento automatizado, es ms bien mixto. Para verificar que la etiqueta 052, se guarda en la posicin especificada en el requerimiento, primero el sistema debe recibir esta etiqueta. La etiqueta es enviada utilizando la funcin GoLabelo();, como se ve en la figura 5.3. Con esta funcin, la etiqueta se despacha con paridad impar, es decir es una etiqueta vlida. Al recibir la etiqueta esta primeramente se mete en la cola del Monitor, de la cual luego se saca para guardarla en la cola especificada en el requerimiento. El punto de alto
BP_OMSTP20101_037 se ejecuta de primero, antes de verificar la paridad de la etiqueta con el fin de ver que esta fue exitosamente enviada. En la figura 6.6, se ve este paso, donde la etiqueta fue recibida y se va a probar su paridad.
Figura 6.6 Paso 2 del procedimiento de prueba del XX03. 58
De acuerdo al requerimiento, la etiqueta debe ser guardada en la cola 052 del Monitor. En el procedimiento, la forma de verificar que esta etiqueta fue guardada en el lugar correcto es ver que solamente el punto de alto que se encuentra justo despus del caso en que la etiqueta sea la 052 sea alcanzado. En la figura 6.7, se ve que el sistema est detenido en este punto de alto, es decir la etiqueta se guard en la cola correcta y el caso de prueba pas.
Figura 6.7 Paso 3 del procedimiento de prueba del XX03.
A continuacin, se debe probar el caso en el que una etiqueta invlida es enviada, esto se hace con ayuda de la funcin Golabele();, como se ve en el paso 10 de la figura 5.3. Al ejecutar este comando en ASTAT, la etiqueta no es enviada, esto debido a algn problema con el programa. El problema se est solucionando, sin embargo esta situacin sirve para ver el caso en el que una condicin no es asegurada. En la figura 6.8, se debe asegurar que el punto de alto BP_OMSTP20101_037 sea alcanzado, pero como la etiqueta no fue enviada, el sistema sigue corriendo sin detenerse en el punto de alto, as que se debe marcar la condicin como no asegurada.
59
Cuando una condicin no es asegurada, la prueba falla y el resto del procedimiento no se debe correr, de ah que el resto de las pruebas fallan. En un procedimiento manual, el probador debe indicar que el Asegrese no se cumpli y marcar las pruebas como fallidas. En ASTAT por otro lado, al marcar que la condicin no se cumpli, la prueba se termina automticamente. Finalmente, se puede decir que la prueba fall, es decir que el requerimiento fall, pero es importante anotar que el fallo no se di por un error en el requerimiento o en el cdigo del cliente, sino ms bien por un error en la herramienta utilizada. Esto implica que la herramienta debe ser corregida, y la prueba se debe correr de nuevo para verificar correctamente el requerimiento. El programa ASTAT al final de la prueba crea un reporte con los resultados de la ejecucin. En las figuras 6.9 y 6.10 se ven los casos de prueba que pasaron para la etiqueta 052. En la figura 6.11, se ve el paso 10, con el Asegrese que no se cumpli y en rojo se lee que la prueba fue terminada debido a que no se satisfizo una condicin.
60
Figura 6.9 Reporte de resultados de ASTAT, XX03, paso 2.
Figura 6.10 Reporte de resultados de ASTAT, XX03, paso 3.
Figura 6.11 Reporte de resultados de ASTAT, XX03, paso 10. 61
6.3 Resultados de pruebas para el XX04.

Este requerimiento se refiere a la inicializacin del sistema. Primero se verifica el caso robusto, en donde el dato InitData es invlido. Para identificar este dato como invlido se debe fallar la prueba de CheckSum, la cual identifica los datos como vlidos o invlidos. En la figura 6.12, se observa como el valor de InitData.CheckSum es distinto al valor de CheckSum; debido a que en el paso 17 de la tabla 5.3 el primer valor se cambi a 0, para obtener esta diferencia de valores.
Figura 6.12 Paso 19 del procedimiento de prueba del XX04. En esta figura, el paso que se ve es el 21, en el que el punto de alto BP_OMSTP20200_003 es alcanzado por segunda vez. De acuerdo a la tabla 4.4, el resultado esperado para el caso de prueba robusto es que los valores de la etiqueta 227 (posicin 233 en el arreglo paramtrico) sean iguales a cero. Como se ve en la figura 6.6, se
62
ve
que
ParametricDataArray[1][233].LabelWord
es
igual
que
ParametricDataArray[1][233].FreshCount es tambin igual a cero. Como este punto de alto es alcanzado dos veces sin detenerse en otro antes de la segunda vez, la funcin ProcessLabel227 no es llamada. De aqu, se puede concluir que este caso de prueba es aprobado. A continuacin, para probar el caso de prueba normal, en el punto de alto BP_OMSTP20200_003 se hace el valor de inicio de la etiqueta 227 igual a 0x0F0F0F0F, esto para saber el valor a esperar despus de la ejecucin de la funcin. Este paso se ve en la figura 6.13.
Ahora, la verificacin del dato de inicializacin se realiza en el punto de alto BP_OMSTP20200_004, el cual se presenta en la figura 6.14. En esta se puede ver que
63
ParametricDataArray[1][233].LabelWord
es
igual
0x0F0F0F0F
que
ParametricDataArray[1][233].FreshCount es igual a 3. Si se comparan estos resultados con los esperados de la tabla 4.4, se puede ver que son iguales.
Finalmente, para este caso de prueba, la funcin ProcessLabel227 debe ser llamada, para verificar esto se coloc un punto de alto dentro de la funcin, como se ve en la figura 6.15, este punto de alto fue alcanzado, lo que indica que la funcin fue llamada. La ejecucin de la misma no interesa, pues como se vio en la seccin 3.4, el requerimiento solo pide que la funcin sea llamada.
64
Ya que se tienen ambos casos de prueba para el requerimiento aprobados, el requerimiento tambin se considera aprobado.
6.4 Resultados de pruebas para el XX05, XX06 y XX07

Al empezar este script, se enva una etiqueta 065 con ndice 00 y ADC igual a 2132, como se ve en la figura 5.5. Al enviar esta etiqueta, la cola de esta deja de estar vaca, por lo que esta se procesa. El primer paso debe ser asegurarse de que la etiqueta fue recibida, y de que fue recibida con el ndice correcto, para observar esto, el punto de alto BP_OMSTP20300_002 debe ser alcanzado (el sistema solo se detiene aqu si la cola no est vaca). En la figura 6.16, se observa el sistema detenido en BP_OMSTP20300_002 y el ndice igual a 0.
65
Figura 6.16 Paso 2 del procedimiento de prueba de XX05, XX06 y XX07. Se debe verificar que el valor de ADC sea extrado de esta etiqueta. El valor enviado fue 2132, y como se ve en la figura 6.17, este es el valor que el procedimiento de ASTAT solicita, y el resultado obtenido en ADCValue. De aqu, que esta prueba para la etiqueta XX05 pas.
Figura 6.17 Paso 3.1 del procedimiento de prueba de XX05, XX06 y XX07.
66
Para el XX07 el valor de ADCValueArray en la posicin indicada por el ndice debe ser igual al valor de ADC extrado. En la figura 6.18, se ve como ADCValueArray[0] es igual a 2132, que en el paso anterior se extrajo de la etiqueta; es decir, este caso de prueba pasa.
Para el caso robusto de la prueba, cuando para la etiqueta 065 se tiene un ndice mayor a 5, se enva la etiqueta con ndice 6 y valor de ADC de 0100. Esta accin se ve en la figura 6.19.
67
Figura 6.19 Paso 14 del procedimiento de prueba de XX05, XX06 y XX07. Una vez enviada la etiqueta, el punto de alto, BP_OMSTP20300_002 es alcanzado y la etiqueta ser procesada. Al ejecutar la funcin, el valor de ADC debe ser extrado, sin embargo, como se ve en la figura 6.20 al alcanzar el punto de alto BP_OMSTP20300_004, que se encuentra al final de la funcin, el valor de ADC sigue siendo 0, y no 0100. Si se ve la tabla 4.5, el valor de ADC debe ser extrado siempre que la cola no est vaca, condicin que se dio al enviar la etiqueta en el paso anterior, por lo que el resultado esperado es que el valor de ADC enviado sea extrado de la etiqueta. De la figura 5.5 se ve que el valor de ADC enviado en la etiqueta es 0100, por lo que este es el valor que se espera a la salida. Esta diferencia entre el valor recibido y el valor esperado causa que la prueba falle, y aun cuando la prueba anterior del requerimiento paso, al fallar este, todo el requerimiento falla.
68
Ahora para el segundo caso de prueba del XX07, de acuerdo a la tabla 4.7, el resultado esperado es que ningn valor del arreglo de ADC sea igual a 0100. En la figura 6.21 se ven las 30 posiciones del arreglo despus de la ejecucin de la funcin; ninguna posicin contiene el valor 0100. El caso de prueba pasa, pues el resultado obtenido en esta si es igual al resultado esperado, y como se tienen 2 requerimientos diferentes con sus casos de prueba respectivos, el fallo del primero, no afecta al segundo.
69
De igual forma se realizan las pruebas para el requerimiento XX06. En la figura 6.22 se ve que se envi una etiqueta 066 con ndice 0.
Figura 6.22 Paso 16 del procedimiento de prueba de XX05, XX06 y XX07.
70
En la figura 6.23, se ve el valor extrado de ADC de 1111, el cual es el enviado (ver figura 5.5) por lo que esta prueba pasa. En esta misma figura, se ve la posicin 6 del arreglo, la cual es igual a 1111, por lo que la prueba del XX07 tambin pasa.
Figura 6.23 Paso 17 del procedimiento de prueba de XX05, XX06 y XX07. De forma similar al caso robusto del requerimiento XX07, la prueba para el requerimiento XX06 falla, pero la prueba para el XX07 pasa. En conclusin, para esta prueba los requerimientos XX05 y XX06 fallaron, mientras que el XX07 pas. En la figura 6.24, se ve el resultado para el paso 3, en la figura 6.25 el mismo para el paso 15 y en la figura 6.26 los resultados para el paso 17.
71
Figura 6.24 Reporte de resultados de ASTAT, paso 3.
72
73
CAPTULO 7: Anlisis de Cobertura Estructural

El anlisis de cobertura estructural depende del nivel de verificacin del sistema. En
este caso se debe verificar a nivel C, por lo que con las pruebas realizadas todas las lneas de cdigo deben ser ejecutadas al menos una vez. Para este proyecto, el anlisis de cobertura estructural se hace con ayuda de un Logical Analyser de Texas Instruments. Se utiliza un cdigo instrumentado al que se le aaden banderas, y se separa cada condicin en una decisin en una lnea para ser identificada ms fcilmente. Al correr este cdigo en el OMS, se activa la bandera cada vez que una lnea es ejecutada, este reporte es recolectado por el analizador, el cual crea un reporte en un archivo de texto con las banderas que fueron levantadas. Este reporte se enva al cliente. En este se incluyen todas las pruebas que se han corrido. El cliente a su vez enva un archivo obtenido de un programa, de carcter confidencial. En este archivo se incluyen los porcentajes de cobertura estructural obtenidos hasta el momento. Para las funciones que se estn analizando en este proyecto, el anlisis de cobertura estructural aun no se ha realizado. Sin embargo con las pruebas realizadas a otras funciones, la cobertura de estos ya esta cerca del 100 %. El analizador funciona de la siguiente forma. Se corre una prueba en el OMS, este guarda en memoria externa las banderas que fueron activadas, y la cantidad de veces que se pas por est lnea de cdigo. Al finalizar la prueba, estos datos se envan al analizador. En la figura 7.1 se ve la pantalla del analizador, aqu se ve la cuenta de lneas inicial en 1. En la figura 7.2 est la misma pantalla al finalizar la prueba, aqu se ve la cuenta final en 788, lo 74
cual quiere decir que se ejecutaron 788 comandos, entre los cuales una o varios lneas pudo ser ejecutada ms de una vez. Aqu tambin se ven, en la orilla izquierda los datos recolectados. La prueba que se corri para este ejemplo fue la prueba para los requerimientos XX05, XX06 y XX07.
Figura 7.1 Pantalla del analizador antes de correr la prueba.
Figura 7.2 Pantalla del analizador despus de correr la prueba. 75
Estos nmeros indican las banderas que fueron activadas y la cantidad de veces. El programa que utiliza el cliente, sin embargo no reconoce este formato, as que el texto debe ser extrado para darle el formato correcto. El texto en formato correcto se ve en la figura 7.3.
Figura 7.3 Texto extrado de la prueba.
El reporte que enva el cliente incluye todas las funciones del sistema y el porcentaje de cobertura logrado en ellas. Para este se puede elegir el nivel al que se est verificando el software, para obtener el reporte adecuado. Un extracto del reporte se ve en la figura 7.4.
76
Figura 7.4 Extracto del anlisis de cobertura estructural. En este extracto se ve el archivo process_065_066.c y sus funciones. La funcin ProcessLabel065066 es la que est siendo probada en el procedimiento para XX05, XX06 y XX07. Aunque estas pruebas no han sido realizadas para obtener cobertura estructural, se ve que con otras pruebas ya se obtuvo el 100 % de cobertura. El reporte tambin incluye un anlisis por funcin, aqu se ven las lneas que fueron ejecutadas en una ejecucin anterior y las que fueron ejecutadas en la ejecucin actual. Las lneas no ejecutables, como las de comentarios, vienen marcadas con un guin. En este reporte se incluye un resumen al final de la cobertura obtenida. Un ejemplo de este reporte se ve en la figura 7.5. El resumen se ve en la figura 7.6.
77
Figura 7.5 Reporte de cobertura estructural de ProcessLabel065066
Figura 7.6 Resumen del reporte de cobertura estructural de ProcessLabel065066
Hasta este momento del proyecto se tienen los siguientes porcentajes de cobertura estructural de las funciones que se estudiaron aqu: 100 % para la funcin HagaPar 82 % para la funcin Transmisin 91 % para la funcin McBSPQueuePut (XX03) 100 % para la funcin McBSPLabelArrayInit 100 % para la funcin ProcessLabel065066
78
Se espera que con la corrida de las pruebas en este proyecto se obtenga el 100 % de cobertura estructural, sin embargo esto no se podr ver aqu debido a que el proceso lleva un mnimo de dos semanas, entre la corrida de las pruebas y la respuesta del cliente. Es tambin posible que no se obtenga un 100 % de cobertura, cuando esto sucede, al finalizar las pruebas se deben analizar los resultados para ver por que no se obtuvo la totalidad de la cobertura. Esto se puede deber a 3 causas: Cdigo desactivado. Esto es cdigo que no es ejecutado, pero tiene una razn de estar ah, ya sea por consideraciones de Hardware o por cdigo defensivo. Cdigo muerto que debe ser removido. El cdigo muerto es cdigo que no debe estar presente ya que nunca ser ejecutado y no es cdigo defensivo. Pruebas insuficientes, o faltante de requerimientos.
79
CAPTULO 8: Conclusiones y recomendaciones
8.1 Conclusiones
Para verificar el correcto funcionamiento del mdulo de interfaz con el hardware se necesitan casos y procedimientos de prueba que comprueben el manejo correcto de los mensajes que se reciben y envan. Los casos de prueba que ejercitarn cada requerimiento dependen del tipo de requerimiento a probar. As como se puede tener un solo caso de prueba para un requerimiento, se pueden tener 20 para otro. Los casos de prueba contienen informacin de las condiciones iniciales, variables de entrada y resultados esperados de una prueba. Los casos de prueba se implementan por medio de procedimientos de prueba en los que se incluyen los pasos a seguir para cumplir con la informacin brindada por los primeros Un procedimiento de prueba puede ser manual, semi-automatizado o automatizado. Para automatizar un procedimiento en Avionyx se utiliza el programa ASTAT. Una prueba puede fallar por distintas razones. Puede deberse a fallos en el requerimiento, errores en el cdigo, pruebas incorrectas o deficiencias en las herramientas utilizadas. Para aprobar un sistema se deben cumplir todos los objetivos del DO-178B.
80
Para lograr cobertura estructural para un sistema que se verifica a un nivel C, se debe comprobar nicamente que todas las lneas de cdigo sean ejecutadas al menos una vez con las pruebas escritas para el software.
Es posible no obtener una cobertura estructural del 100%. Esto es aceptable si se determina que las lneas que no fueron ejecutadas son cdigo desactivado.
8.2 Recomendaciones
Es importante identificar los errores en los requerimientos en etapas tempranas del desarrollo de las pruebas de verificacin de estos, esto con el fin de reportarlos con tiempo, para que estos puedan ser corregidos y la verificacin del sistema tenga un resultado ms positivo. Las revisiones por parte de los colegas de los documentos de casos y procedimientos de prueba son de gran importancia, se deben realizar cuantas se puedan, para encontrar la mayor cantidad de defectos en los documentos en la hora del desarrollo, y no despus de que han sido entregados al cliente o peor aun, a la hora de realizar las pruebas.
81
BIBLIOGRAFA
Publicaciones: 1. Cubas, G. Introduction to DO-178B Certification Process, AVT-DO178-101B, 2007 2. Cubas, G. Introduction to Integral Processes, AVT-DO178-104A, 2007 3. Berrocal, A. Avionyx Software Test Automation Tool(ASTAT), 2008. 4. Avionyx S.A, DLRA-OMS Software Verification Plan (SVP). Heredia, Costa Rica. 2008 5. El cliente, DLRA-OMS Software Design Description (SDD). Cedar Rapids, Iowa. 2008 Tesis: 6. Murillo, L. Desarrollo de software para equipos de avinica, Proyecto de Graduacin, Instituto Tecnolgico de Costa Rica, 2006 7. Borras, D. Verificacin y validacin de software en sistemas de informacin de vuelo EFIS, Proyecto de Graduacin, Instituto Tecnolgico de Costa Rica, 2007. Internet: 8. DO-178B, http://en.wikipedia.org/wiki/DO-178B, 2 de abril, 2:30 pm. 9. Introduccin al lenguaje C, http://www.monografias.com/trabajos/introc/introc.shtml, 26 de mayo, 10:00 am. 10. Lenguaje de programacin C, http://es.wikipedia.org/wiki/ANSI_C, 26 de mayo, 10:30 am. 11. Composer Studio IDE, http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html, 26 de mayo, 11:00 am. 12. Composer Studio IDE, http://dspresearch.com/www/products/spm/ti%20software%20tools/code%20compo ser%20studio/Code%20Composer%20Studio.htm, 26 de mayo, 11:30 am.
82
Libros: 13. Gottfried, B. Programacin en C, 2nda edicion. MacGraw Hill, 2005, Mexico.
83
ANEXOS
Anexo 1: Tabla de casos de prueba completa
84
Anexo 2: Funcin Golabelo() y Golabele()

function Golabelo(lab){ myConn.clearBuffers(); var A429_Send = new Arinc429(lab,0x00,0x00,0x00,Arinc429.ODD); sent_TStamp = myConn.sendWord(A429_Send,CHANNEL_0,TimeOut); println("The Label "+lab+" was sent on McBSP1"); println ("<h3> The label that was sent over </h3>"); // printLabel(Label227.toWord());
println(A429_Send.toHex()); } function Golabele(labe){ myConn.clearBuffers(); var A429_Send = new Arinc429(labe,0x00,0x00,0x00,Arinc429.EVEN); sent_TStamp = myConn.sendWord(A429_Send,CHANNEL_0,TimeOut); println("The Label "+labe+" was sent on McBSP1"); println ("<h3> The label that was sent over </h3>"); // printLabel(Label227.toWord());
println(A429_Send.toHex()); }
85

Rad Alt.

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rad Alt.

Transféré par

Droits d'auteur :

Formats disponibles

Universidad de Costa Rica Facultad de Ingeniera Escuela de Ingeniera Elctrica

IE 0502 Proyecto Elctrico

Ciudad Universitaria Rodrigo Facio Julio del 2008

_________________________________ Ing. Luca Acua Avedao Profesor Gua

_________________________________ Ing. Jorge Romero Profesor lector

_________________________________ Ing. Gustavo Cubas Lector

CAPTULO 2: Marco Terico ............................................................... 7

Code Composer Studio .....................................................................................25 ASTAT..................................................................................................................26

CAPTULO 4: Casos de prueba........................................................... 35

CAPTULO 5: Procedimientos de prueba .......................................... 43

CAPTULO 6: Pruebas 6...................................................................... 53

CAPTULO 7: Anlisis de Cobertura Estructural............................. 74 CAPTULO 8: Conclusiones y recomendaciones ............................... 80

BIBLIOGRAFA.......................................................................................... 82 ANEXOS ....................................................................................................... 84

Software Considerations in Airborne Systems and Equipment

CAPTULO 2: Marco Terico

Tabla 2.1 Relacin entre niveles de certificacin, objetivos e independencia. [4]

Figura 2.1 Ciclo de vida del sistema SW [2] 9

integracin, requerimientos, diseo, codificacin y finalmente integracin.

Figura 2.2 Proceso de Revisin [2] 2.1.4.4.2 Anlisis

Figura 2.4 Concepto de Altmetro de radio bsico. [5]*

Modo Interactivo. El modo interactivo realiza la interaccin con el sistema de mantenimiento de

Equipo de prueba empotrado (BITE).

2.4 Code Composer Studio

Caractersticas de un requerimiento. [5]

ADC Value Array Location 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

CAPTULO 4: Casos de prueba

Tabla 4.1: Contenidos de un caso de prueba

Esta prueba verifica que

4.1 Casos de prueba para XX01

El sistema est corriendo

Bits [30-0] contienen un nmero par de unos

El sistema est corriendo

Bits [30-0] contienen un nmero impar de unos

4.2 Casos de prueba para XX02

Tabla 4.3: Caso de prueba para XX02

El sistema est corriendo

LoWord =0x8000 Manual HiWord =0xFFFF

4.3 Casos de prueba para XX03

Tabla 4.4: Casos de prueba para XX03

La Cola McBSP1 Rx est vaca

Nada se saca de la cola.

4.4 Casos de prueba para XX04

InitData fue ledo de la memoria no voltil (NVM)

InitData fue ledo de la memoria no voltil (NVM)

4.5 Casos de prueba para XX05

ADCValue = ((Label065 & 003FFF00)>>8)

La cola de etiqueta 065 de Primario est vaca

4.6 Casos de prueba para XX06

La cola de etiqueta 066 de Monitor no est vaca

ADCValue = ((Label066 & 003FFF00)>>8)

ADCValue = ((Label066 & 003FFF00)>>8)

La cola de etiqueta 066 de Monitor est vaca

4.7 Casos de prueba para XX07

Un valor de ADC fue calculado de la etiqueta 065

Un valor de ADC fue calculado de la etiqueta 065

Ningun valor en ADCValueArray es igual a 0100

Un valor de ADC fue calculado de la etiqueta 066

Un valor de ADC fue calculado de la etiqueta 066

Ningun valor en ADCValueArray es igual a 0100

CAPTULO 5: Procedimientos de prueba

Tabla 5.1: Estructura de un procedimiento de prueba

5.1 Procedimiento de prueba para el XX01 y el XX02

Figura 5.1 Funcin de transmisin alterada

El resultado obtenido es el esperado: S _ No _

esperado: S ___ No _ El resultado obtenido es el esperado: S _ No ___