ES2338829T3 - Metodo de prueba de un sistema electronico. - Google Patents
Metodo de prueba de un sistema electronico. Download PDFInfo
- Publication number
- ES2338829T3 ES2338829T3 ES08012391T ES08012391T ES2338829T3 ES 2338829 T3 ES2338829 T3 ES 2338829T3 ES 08012391 T ES08012391 T ES 08012391T ES 08012391 T ES08012391 T ES 08012391T ES 2338829 T3 ES2338829 T3 ES 2338829T3
- Authority
- ES
- Spain
- Prior art keywords
- test
- sequence
- file
- scenario
- text
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
- G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
- G01R31/005—Testing of electric installations on transport means
- G01R31/008—Testing of electric installations on transport means on air- or spacecraft, railway rolling stock or sea-going vessels
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
- Debugging And Monitoring (AREA)
Abstract
Método de preparación de una prueba de un sistema electrónico (SE) que comprende varios equipos (CALC1, CALC2, DISP1, DISP2, CALC3, CALC4) conectados por al menos una conexión de comunicación (LIA, BUS), en el que, para efectuar la prueba: - se utiliza un banco de prueba (BT) adaptado al sistema electrónico (SE) que va a someterse a prueba que se conecta al sistema que va a someterse a prueba, y - se controla el banco de prueba según una secuencia de órdenes (Scenario_text_file) establecida a partir de al menos una especificación funcional informal (Functionnal_chain), estando caracterizado el método de preparación de prueba porque: - se crea la secuencia de órdenes (Scenario_text_file) a partir de un procedimiento de prueba (ATP, Test_Pro- cedure) que contiene una secuencia de objetos dotados de atributos, estando dotado al menos uno de los objetos de un atributo de trama que determina un emisor y un receptor entre los equipos del sistema SE, y que permite determinar un formato de transferencia de datos entre el emisor y el receptor, y - se registra la especificación funcional informal (Functionnal_chain), la secuencia de órdenes (Scenario_ text_file), así como al menos un enlace (Link) que identifica una especificación funcional informal (Functionnal_chain) a partir de la cual se ha establecido al menos una parte de la secuencia de órdenes, de manera que después de la ejecución de la secuencia de orden y el registro de los resultados de la prueba, puede leerse el enlace (Link) e identificar de manera unívoca la o las especificaciones funcionales informales (Functionnal_chain) correspondientes a los resultados de prueba obtenidos.
Description
Método de prueba de un sistema electrónico.
La presente invención se refiere a un sistema y
a un método de prueba de un sistema electrónico.
El campo técnico de la invención es el de la
fabricación de helicópteros.
La presente invención se refiere en particular a
un sistema de prueba de un sistema electrónico que comprende varios
equipos electrónicos y una o varias estructura(s) de
interconexión que conectan estos equipos.
La invención se aplica concretamente al caso en
el que la interconexión se realiza mediante una o varias
conexiones/buses de comunicación que es (son) conforme(s) a
una o varias normas elegidas entre las normas
MIL-STD-1553 (A o B), STANAG 3350,
STANAG 3838, STANAG 3910, ARINC 429, ARINC 453, ARINC 629, ARINC
636, MIL-STD-1773, AFDX, ASCB,
CSDB, IEEE P1014, RS232, RS422, RS485.
Los sistemas electrónicos instalados a bordo de
aviones o autogiros que comprenden generalmente varios calculadores
conectados a sensores, a accionadores y a visualizadores
especialmente.
Las pruebas de funcionamiento correcto de tales
sistemas son complejas, largas y por consiguiente costosas.
La preparación y la realización de estas pruebas
resultan difíciles debido, especialmente, al gran número de señales
y datos intercambiados por los equipos durante su funcionamiento, y
debido al gran número de configuraciones posibles de los equipos
que constituyen este sistema electrónico según esté previsto, por
ejemplo, el sistema electrónico para equipar una aeronave
desprovista de sistema de armamento o por el contrario para equipar
una aeronave dotada de un sistema de armamento.
La patente EP-532017 describe un
sistema de prueba de un equipo electrónico que comprende un
controlador de ensayos genérico GTC así como una unidad de
interferencia funcional FIU, específica de un sistema de armamento
particular, que están cada uno conectado con un panel de interfaz
con los aparatos en prueba y que se comunican por medio de un bus
IEEE-488. El controlador genérico GTC y la unidad
específica FIU están cada uno conectados a tarjetas, o
instrumentos, de entrada/salida analógica y digital, por medio de un
bus IEEE-796. El controlador GTC comprende tarjetas
de interfaz con el bus 1553 que pueden funcionar como controlador de
bus, como terminal o como monitor de bus. Pueden modificarse y
compilarse programas de prueba mediante un ordenador central, por
medio de una conexión RS232 y registrarse en una unidad de
almacenamiento conectada, al igual que una interfaz de operador, a
la unidad de microprocesador del controlador GTC.
La patente EP-827608 describe un
método de prueba de circuitos eléctricos en el que el programa de
prueba se divide en un elemento relativo a la secuencia de prueba
que recurre a datos contenidos en un campo de datos textuales y un
elemento relativo al control del dispositivo de prueba.
La patente EP-985155 describe un
método de prueba en el que un operador introduce información para
definir una secuencia de órdenes que se aplicará a un dispositivo
de prueba conectado a un equipo que va a someterse a prueba. Para
cada orden de la secuencia de órdenes, el operador introduce un
número de orden, un tipo de orden, parámetros o variables de la
orden y un resultado esperado para la prueba correspondiente a esta
orden. Para realizar esto, el operador tiene la ayuda de un
diccionario de los diferentes tipos de orden aplicables al equipo
que va a someterse a prueba, así como una base de datos que agrupa
las variables contenidas en los argumentos de las órdenes así como
los valores que cada variable puede adoptar. El operador puede a
continuación hacer que el dispositivo de prueba ejecute la o las
órdenes introducidas y puede archivar los resultados de la prueba.
El dispositivo de prueba puede realizar un análisis para verificar
que un tipo de orden introducida pertenece al diccionario, que los
argumentos tienen una sintaxis correspondiente a la del diccionario
y que las variables introducidas pertenecen a la base de datos de
variables.
La patente EP-1583289 describe
un sistema de simulación y de prueba de una red AFDX que permite
simular uno o varios equipos a partir de "productos
comerciales".
Los métodos y sistemas de simulación y/o de
prueba conocidos generalmente están diseñados para someter a prueba
un número restringido de equipos.
La prueba de un sistema electrónico de a bordo
(aviónica) tiene por objeto verificar que las funciones asignadas
al sistema efectivamente se cumplen. Estas funciones se definen
generalmente de manera informal. A partir de una definición de este
tipo, una persona, operador de prueba, puede elaborar una secuencia
de órdenes de un dispositivo (o "banco") de prueba, por
ejemplo como se describe en la patente
EP-985155.
Teniendo en cuenta la complejidad de un sistema
que va a someterse a prueba, una secuencia completa de órdenes
suficiente para someter a prueba una función determinada del sistema
puede comprender uno o varios millares de órdenes.
\newpage
La elaboración de las secuencias de órdenes que
van a aplicarse al aparato de prueba necesita recurrir a un
operador altamente cualificado. Debido a la diversidad de los
equipos que forman parte del sistema de aviónica, es difícil, si no
imposible, disponer de un operador perfectamente cualificado para
todos los equipos del sistema y para todas las funciones que debe
cumplir el sistema en su conjunto. Por tanto, generalmente es
necesario recurrir a varios operadores elegidos en función de su
alta cualificación para una parte solamente de los equipos y/o de
las funciones que van a someterse a prueba.
La puesta a punto de un sistema electrónico de a
bordo necesita a menudo someter a prueba sucesivamente, repetidas
veces, la adecuación del sistema con una función determinada que
debe cumplir.
Debido especialmente al carácter informal de la
definición de una función que tal sistema electrónico debe cumplir,
dos operadores distintos pueden elaborar dos secuencias de órdenes
diferentes, y la ejecución de estas dos secuencias de órdenes
producirá dos informes de prueba diferentes.
Además, para una orden determinada, dos
operadores distintos pueden elegir dos valores distintos para un
parámetro o una variable de esta orden, lo que también desembocará
en dos informes de prueba diferentes. La comparación de estos dos
informes puede carecer de sentido o puede desembocar en una
conclusión errónea.
Un objetivo de la invención es proponer un
método y/o un sistema de prueba y de simulación de un sistema
electrónico complejo mejorado(s) y/o que remedie(n),
al menos en parte, las carencias o inconvenientes de los métodos y
sistemas de prueba conocidos.
Según un aspecto de la invención, se propone un
método de preparación de una prueba de un sistema electrónico que
comprende varios equipos conectados por al menos una conexión de
comunicación, en el que, para efectuar la prueba:
- -
- se utiliza un banco de prueba adaptado al sistema electrónico que va a someterse a prueba que se conecta al sistema que va a someterse a prueba, y
- -
- se controla el banco de prueba según una secuencia de órdenes (Scenario_text_file) establecida a partir de al menos una especificación informal de función (Functionnal_chain) que el sistema que va a someterse a prueba debe cumplir;
durante la preparación de la prueba:
- -
- se crea la secuencia de órdenes (Scenario_text_file) a partir de un procedimiento de prueba (ATP, Test_Pro- cedure) que contiene una secuencia de objetos dotados de atributos, estando dotado al menos uno de los objetos de un atributo de trama que determina un emisor y un receptor entre los equipos del sistema SE, y que permite determinar un formato de transferencia de datos entre el emisor y el receptor, y
- -
- se registra la especificación funcional informal (Functionnal_chain), la secuencia de órdenes (Scenario_ text_file), así como al menos un enlace (Link) que identifica una especificación funcional informal (Functionnal_chain) a partir de la cual se ha establecido al menos una parte de la secuencia de órdenes, de manera que después de la ejecución de la secuencia de órdenes y el registro de los resultados de la prueba, puede leerse el enlace (Link) e identificar de manera unívoca la o las especificaciones informales funcionales (Functionnal_chain) correspondientes a los resultados de prueba obtenidos.
Según características preferidas de un método
según la invención:
- -
- la especificación funcional informal (Functionnal_chain) puede registrarse en forma de un archivo de texto;
- -
- la secuencia de órdenes (Scenario_test_file) puede registrarse en forma de un archivo de texto;
- -
- el enlace (Link) puede comprender la dirección de una parte al menos de la secuencia de órdenes (Scenario_text_file), o la dirección de un archivo que contiene una parte al menos de esta secuencia, así como la dirección de la especificación funcional informal (Functionnal_chain), o la dirección de un archivo que contiene esta especificación;
- -
- se crea la secuencia de órdenes (Scenario_text_file) a partir de un procedimiento de prueba (ATP, Test_Pro- cedure) que contiene una secuencia de objetos dotados de atributos;
- -
- el procedimiento de prueba (ATP, Test_Procedure) puede contener objetos de simulación (TestSimu), objetos de observación (TestSpy), objetos de control (TestCheck), objetos de función que va a someterse a prueba (TestFunct);
- -
- el procedimiento de prueba (ATP, Test_Procedure) contiene datos de organización jerárquica de los objetos, en particular datos de organización jerárquica de los objetos de función que va a someterse a prueba (TestFunct);
- -
- durante la creación de una secuencia de órdenes (Scenario_text_file) a partir de un procedimiento de prueba (ATP, Test_Procedure) que contiene objetos de simulación (TestSimu), objetos de observación (TestSpy) y/u objetos de control (TestCheck), se eligen estos objetos entre objetos (POIL_BAR) registrados en una base de datos (Interf_DB) de configuración de los equipos, y de intercambios de datos entre los equipos, del sistema que va a someterse a prueba.
En esta base de datos, un objeto se define
mediante un nombre único; entre estos objetos, los objetos que
implican una transferencia de datos mediante una de las
conexiones/buses del sistema que va a someterse a prueba presentan
un atributo de trama que determina un único equipo emisor y un único
equipo receptor. Esta base contiene, además, la información
necesaria para la definición de la señal física intercambiada entre
este emisor y este receptor del sistema que va a someterse a prueba,
especialmente el periodo y el formato de trama.
Según otro aspecto de la invención, se propone
un método de realización de una prueba de un sistema electrónico
que comprende varios equipos conectados por al menos una conexión de
comunicación, en el que se prepara la prueba mediante un método
según la invención, a continuación;
- -
- se conecta un banco de prueba al sistema electrónico que va a someterse a prueba,
- -
- se lee una secuencia de órdenes (Scenario_text_file) y se controla el banco de prueba según la secuencia de órdenes (Scenario_text_file),
- -
- se registran los resultados de la prueba en un archivo (Res_File), y
- -
- se asocia a los resultados de la prueba al menos una especificación funcional informal (Functionnal_chain) enlazada a la secuencia de órdenes (Scenario_text_file) mediante un enlace (Link) previamente registrado.
Según otro aspecto de la invención, se propone
un método de prueba de un sistema electrónico que comprende varios
equipos conectados por al menos una conexión de comunicación, en el
que,
se prepara la prueba:
- -
- preparando un procedimiento de prueba formal (ATP, Test_Procedure) que se conecta mediante uno o varios enlaces (Link) a una o varias definiciones funcionales (Functionnal_chain) de requisitos para el sistema, y
- -
- produciendo automáticamente un escenario de prueba (Scenario_text_file), que permite controlar un banco de prueba adaptado y conectado al sistema que va a someterse a prueba, utilizando una base de datos (Interf_DB) que contiene una definición de todas las señales susceptibles de intercambiarse por los equipos del sistema que va a someterse a prueba,
a continuación, tras la preparación, se ejecuta
el escenario de prueba (Scenario_text_file) en el banco de prueba
controlando y registrando en un informe de ejecución (Res_File) el
estado del sistema que va a someterse a prueba con respecto a la
descripción proporcionada en el escenario de prueba, y
- -
- se informa automáticamente de los resultados del informe de ejecución en el procedimiento de prueba (ATP, Test_Procedure, ATR),
permitiendo el (los) enlace(s)
identificar de manera unívoca el conjunto de los requisitos del
sistema que va a someterse a prueba que se han sometido a prueba
mediante la ejecución del escenario de prueba y que corresponden a
los resultados obtenidos.
La invención permite producir informes de
trazabilidad automática entre los resultados de prueba (Res_File,
ATR) y los requisitos funcionales del sistema, y permite garantizar
la adecuación perfecta entre la descripción de las pruebas,
mediante el procedimiento ATP, Test_Procedure, y su ejecución sobre
el sistema que va a someterse a prueba.
Al menos algunas de las operaciones de la fase
preparatoria y/o de la fase de prueba como tal, pueden ponerse en
práctica métodos según la invención mediante una unidad electrónica
de tratamiento de datos, tal como un calculador, que funciona bajo
el control de un programa.
Así, según otro aspecto de la invención, se
propone un programa que comprende un código fijado sobre un soporte,
tal como una memoria, o materializado mediante una señal, siendo el
código legible y/o ejecutable mediante al menos una unidad de
tratamiento de datos, tal como un procesador, para estimular y
someter a prueba el funcionamiento (correcto o incorrecto) de un
sistema electrónico complejo, comprendiendo el código segmentos de
código para efectuar operaciones de un método según la
invención.
Según otro aspecto de la invención, se propone
un sistema de prueba de un sistema electrónico complejo, que está
programado para ejecutar operaciones de un método según la
invención.
\newpage
Otros aspectos, características y ventajas de la
invención aparecen en la descripción siguiente, que se refiere a
los dibujos adjuntos y que ilustra, sin carácter limitativo en
absoluto, modos preferidos de realización de la invención.
La figura 1 ilustra esquemáticamente un sistema
de prueba conectado a los buses de un sistema electrónico de un
autogiro que comprende calculadores redundantes interconectados
mediante un bus redundante.
La figura 2 ilustra esquemáticamente el
encadenamiento de etapas de un método de preparación de prueba y de
un método de prueba según la invención.
La figura 3 ilustra esquemáticamente el
encadenamiento de etapas para el establecimiento de un procedimiento
de prueba en un método de prueba según la invención.
La figura 4 ilustra esquemáticamente el
encadenamiento de etapas para el establecimiento de una secuencia
de órdenes de prueba a partir de un procedimiento de prueba en un
método de preparación de prueba según la invención.
La figura 5 ilustra esquemáticamente el
encadenamiento de etapas para la ejecución de un procedimiento de
prueba en un método de prueba según la invención.
La figura 6 ilustra esquemáticamente módulos de
un sistema de prueba según la invención.
La figura 7 ilustra un ejemplo de estructura de
un procedimiento de prueba de un método según la invención y su
enlace con una especificación funcional informal.
La figura 8 ilustra la utilización del
procedimiento de prueba de la figura 7 para elaborar automáticamente
una secuencia de órdenes de prueba según un aspecto de la
invención.
La figura 9 es un gráfico que ilustra
esquemáticamente un ejemplo de interfaz gráfica que se presenta a un
operador que ejecuta una prueba preparada según la invención.
La figura 10 ilustra esquemáticamente la
elaboración de un informe de prueba en función de los resultados de
la prueba y del procedimiento de prueba correspondiente.
En referencia a la figura 1 en particular, la
invención se aplica a un sistema electrónico SE de un autogiro, que
comprende dos calculadores redundantes CALC1 y CALC2 cuya función es
gestionar el sistema SE.
El sistema SE comprende además dos calculadores
redundantes CALC3 y CALC4 cuya función es la de gestionar el
funcionamiento de o de los motores del autogiro.
Para no perjudicar a la claridad de la figura,
otros calculadores y equipos electrónicos que forman habitualmente
parte de la aviónica SE de un autogiro, tales como los equipos de
navegación y de comunicación, no se representan en esta figura.
El sistema SE también comprende dos
visualizadores de múltiples funciones DISP1 y DISP2.
Los calculadores del sistema SE están conectados
a un bus redundante BUS, por ejemplo, un bus
MIL-STD- 1553. Los calculadores están conectados
además entre sí mediante una o varias conexiones punto a punto LIA,
tales como las conexiones RS485 o ARINC 429. Cada calculador
también está conectado mediante una conexión LIA a cada uno de los
dos visualizadores.
Como se ilustra en las figuras 1 y 6, para la
prueba del sistema SE y/o la simulación del funcionamiento de uno o
varios de sus equipos, se conecta un banco de prueba BT a los buses
BUS del sistema SE.
En referencia a la figura 6, el banco BT puede
comprender un ordenador BT1 que puede utilizarse por un operador
que realiza una prueba, y un módulo de prueba BT2 dirigido por el
ordenador BT1.
El módulo BT2 está conectado al bus del sistema
SE que va a someterse a prueba para simular un equipo del sistema
SE tal como el calculador CALCX ilustrado con línea de puntos en la
figura 6, y para supervisar/registrar las señales/datos
intercambiados por los equipos del sistema SE durante una
prueba.
El módulo BT2 puede comprender una unidad de
control con microprocesador, unidades de entrada/salida analógicas
y digitales, y comprende interfaces apropiadas para su conexión a
los buses BUS, por un lado, y a las conexiones LIA, por otro lado.
Los componentes del módulo BT2 pueden interconectarse entre sí
mediante un bus VME, por ejemplo.
Para la prueba y/o la simulación del sistema SE,
el banco de prueba BT se conecta a, y se dirige por, un sistema de
prueba SYST según la invención que suministra para ello al banco BT
señales y/o datos correspondientes a las secuencias de órdenes de
prueba, y que a continuación recibe desde el banco BT señales y/o
datos correspondientes a los resultados de la ejecución de estas
órdenes.
El sistema de prueba SYST incluye (véase la
figura 6) una base de datos documental B3D que comprende
procedimientos de prueba ATP, procedimientos de prueba ATR con los
resultados de la prueba correspondiente asignados, especificaciones
funcionales Functionnal_chain que contienen requisitos funcionales
de todo o parte del sistema que va a someterse a prueba, así como
una base de datos Interf_DB que contiene las especificaciones de los
intercambios de señales/datos, mediante el bus y las conexiones
BUS, LIA, entre los equipos CALCA, CALCB, CALCC, CALCX del sistema
SE.
Según un aspecto de la invención, un
procedimiento de prueba formalizado se define en forma de un
conjunto de objetos de una base de datos y se enlaza con los
documentos de especificaciones de los requisitos del sistema que va
a someterse a prueba. Un escenario de prueba, o secuencia de órdenes
de prueba, se genera automáticamente a partir del procedimiento de
prueba y a continuación se ejecuta sobre el banco de prueba un
tiempo real con el registro automático de los resultados; la
invención permite garantizar una trazabilidad completa, de la
especificación del sistema hasta los resultados de la prueba.
Se crean clases de objeto en la base de datos
con el fin de formalizar la descripción integral de todas las
operaciones que deben efectuarse durante la ejecución de una prueba.
Estas operaciones pueden ser de tipo manual (verificación por el
ingeniero de prueba del comportamiento de un equipo del sistema) o
automático (simulación o espionaje de un valor de datos que circula
en la gran cantidad de datos del sistema). Las pruebas se separan
en pruebas "elementales" (parte más pequeña del procedimiento
que puede ejecutarse individualmente).
La preparación y la ejecución de una secuencia
de órdenes de prueba, bajo el control del sistema SYST, pueden
comprender las etapas sucesivas siguientes cuyo encadenamiento se
representa esquemáticamente en las figuras 2 a 5;
- -
- en una base de datos de objetos dotados de atributos, se crea un procedimiento de prueba mediante introducción de información (etapa 13) y/o mediante importación (etapa 11) de datos informales de especificación de funciones que el sistema SE debe cumplir, contenidas en un texto o una tabla por ejemplo, seguido de una conversión (etapa 12) de los datos informales al formato de la base de datos de objetos;
- -
- a continuación se define (etapa 14), para el procedimiento de prueba o para al menos un objeto de este procedimiento, un enlace entre el objeto (respectivamente el procedimiento) y una especificación informal de función;
- -
- para la ejecución de la prueba (etapa 16), se genera al menos una secuencia de órdenes a partir del procedimiento de prueba, se suministran las órdenes al banco de prueba, se registran los resultados de prueba transmitidos al sistema SYST por el banco BT, y se modifican automáticamente los atributos de los objetos TestCheck en función de estos resultados;
- -
- se establece (etapa 18) un informe de síntesis de las pruebas efectuadas que se exporta (etapa 19) dado el caso hacia una aplicación diferente.+
En referencia a las figuras 3 y 7 a 10
concretamente, un procedimiento de prueba comprende al menos una
secuencia jerarquizada de objetos que pertenecen a diferentes
clases de objeto tales como, por ejemplo;
- -
- una clase de objetos TestFunct que contiene cada uno un título relativo a una parte del procedimiento, tal como "1.1 engine t 700 status monitoring" o "1.1.1 engine ½ oil pressure bar-chart";
- -
- una clase de objetos TestIdent que contiene, cada uno, un identificativo de prueba elemental tal como "[eng1_oil_pressure_bar_chart]" que se presenta (en la ventana SELECT de la figura 9) a un operador que ejecuta el procedimiento;
- -
- una clase de objetos TestDesc que contienen, cada uno, una descripción de la parte pertinente del procedimiento tal como "simulate oil pressure from 0 to 25 bar and then going below 3 bar for checking displayed warnings and cautions"; esta descripción también se presenta en la ventana SELECT de la figura 9;
- -
- una clase de objetos TestProc que contienen, cada uno, un mensaje de instrucción tal como "power on PMC and check MFD oil pressure display according to simulated value", destinado a indicar a un operador que ejecuta el procedimiento, la acción que debe efectuar en el sistema SE que va a someterse a prueba; este mensaje puede presentarse al operador en una ventana similar a la ventana EXEC de la figura 9;
- -
- una clase de objetos TestSimu que contienen, cada uno, una orden del banco de prueba, tal como "POIL_ BAR=LIST (0,0.1,1.2,1.3,1.4,2.1,1.2,6.8,6.9,8.2, 8.3,25)", destinada a provocar el envío por el banco de prueba, a al menos un equipo del sistema SE sometido a prueba, a través del bus BUS o una de las conexiones LIA, de datos que simulan, por ejemplo, una señal suministrada por un sensor, para simular este último;
- -
- una clase de objetos TestSpy que contienen, cada uno, una orden del banco de prueba, tal como "POIL_ BAR", destinada a provocar el envío al banco de prueba, mediante al menos un equipo del sistema SE sometido a prueba, a través del bus BUS o una de las conexiones LIA, de datos suministrados por este equipo, para supervisar a este último; este dato se presenta al operador en el momento de la prueba en la ventana SPY de la figura 9;
- -
- una clase de objetos TestCheck que contienen, cada uno, una instrucción de verificación del estado del sistema SE sometido a prueba que debe efectuar el operador, tal como "Check VMD main... of digital value at 3 bar.", destinada a provocar el registro de un dato de constatación de éxito "passed" o de fracaso "failed" que puede introducirse por el operador durante la prueba, en la ventana EXEC de la figura 9.
En el modo de realización correspondiente a la
figura 3, se importan, dado el caso, datos de definición de objetos
a partir de una tabla (operaciones 110, 120) o de un archivo de
texto (operaciones 11, 121); se procede a la introducción,
selección, extracción o conversión de objetos TestFunc, TestIdent,
TestDesc y/o TestProc (operación 130).
Se procede la misma operación de
introducción/importación para los objetos TestSimu y TestSpy
(operaciones 131 y 133, respectivamente), de los que se verifica el
formato y el contenido (operaciones 132 y 134, respectivamente)
mediante comparación con datos de la base Interf_DB.
Se introduce también el contenido de los objetos
TestCheck (operación 135) y se modifican o se añaden atributos
(operación 136) a todo o parte de estos objetos.
A continuación puede crearse y registrarse un
enlace (operación 137) entre el procedimiento definido por una
secuencia de estos objetos y una o varias especificaciones
funcionales en lenguaje natural correspondientes a estos objetos, y
registrarse (operación 138) el procedimiento así definido ATP,
Test_Procedure.
Pueden preverse otras clases de objetos, por
ejemplo, una clase de objetos que contienen, cada uno, una
descripción o identificación de un medio de prueba determinado que
debe incluirse en el banco de prueba para realizar una prueba
determinada.
Las figuras 7, 8 y 10 ofrecen una vista de
conjunto del contenido de la base de datos documental de definición
de pruebas, en forma de una tabla en la que los datos
correspondientes a un objeto forman una línea. La clase del objeto
aparece en una primera columna (columna de la izquierda, figuras 7 y
8), el contenido del objeto aparece en una segunda columna y los
atributos del objeto aparecen en otras columnas.
Entre estos atributos, está previsto
especialmente un atributo de trama para los objetos de la clase de
objeto TestSimu y TestSpy especialmente. Durante la generación
automática de una secuencia de órdenes de prueba a partir de un
procedimiento que incluye un objeto que presenta este atributo, este
atributo se utiliza para adaptar la orden de prueba a un protocolo,
o formato de intercambio de datos, adaptado al protocolo utilizado
por los equipos del sistema SE para comunicarse. El atributo de
trama se utiliza para especificar la ruta física definida en el
banco de prueba.
A modo de ejemplo, como se ilustra en la figura
8, un atributo de trama de este tipo asociado al objeto TestSimu
que contiene la orden "POIL_BAR=LIST (0,0.1,1.2,1.3,1.4,2.1,
1.2,6.8,6.9,8.2,8.3,25)", provoca, durante la creación de un
archivo de orden en el formato de texto ilustrado en el cuadro
inferior de esta figura, la modificación del contenido de esta
orden, que se convierte en "POIL_BAR.O_T7_1_PMC_N=/LIST
(0,0.1,1.2,1.3,1.4,2.1,1.2,6.8,6.9, 8.2,8 .3,25)".
Entre estos atributos, también está previsto un
atributo de resultado para los objetos de la clase de objetos
TestCheck especialmente. Este atributo puede modificarse, durante la
generación automática de un informe de prueba, para incluir el
resultado, tal como el resultado "failed" de la figura 10, de
una verificación efectuada por el operador durante la prueba.
En referencia a las figuras 4 y 8, se genera un
archivo de texto con una sintaxis particular mediante extracción en
el texto del procedimiento del conjunto de las instrucciones que van
a utilizarse en el banco de prueba en tiempo real.
Para ello, puede procederse sucesivamente a una
lectura (etapa 40) de un procedimiento de prueba ATP,
Test_Pro-
cedure, a una lectura (etapa 41) de una configuración del banco de prueba, a una lectura (etapa 42) de una configuración del sistema que va a someterse a prueba, para la creación (etapa 43) y el registro de una secuencia de órdenes correspondiente a este procedimiento y a estas configuraciones.
cedure, a una lectura (etapa 41) de una configuración del banco de prueba, a una lectura (etapa 42) de una configuración del sistema que va a someterse a prueba, para la creación (etapa 43) y el registro de una secuencia de órdenes correspondiente a este procedimiento y a estas configuraciones.
Para la ejecución de la prueba ilustrada en la
figura 5, un escenario genérico puede leer/interpretar (etapa 50)
el archivo de texto de las instrucciones de la prueba. Permite
ejecutar (etapa 51), de manera secuencial o no, el conjunto de las
pruebas elementales descritas en el procedimiento asociado y efectúa
(etapa 52) el registro de los resultados durante la prueba en otro
fichero de texto.
En referencia a las figuras 6 y 10
especialmente, el archivo de texto Res_File (figura 6) que contiene
los resultados de la prueba se utiliza a continuación para
actualizar automáticamente el informe de prueba en la base de datos
documental. Éste se utiliza a continuación para producir un
documento final de aceptación ATR ("Acceptance Test Report")
que combina el procedimiento de prueba ATP utilizado y los
resultados obtenidos durante la ejecución de la secuencia de
órdenes correspondiente a este procedimiento ATP.
En referencia a la figura 9, durante la
ejecución de una prueba, se presentan al operador las ventanas de
diálogo y de introducción SELECT, SPY y EXEC, en la pantalla del
ordenador BT1 del banco BT, cuya existencia y contenido son
resultado respectivamente de la existencia y del contenido de los
objetos de clase TestIdent, TestDesc y TestProc descritos
anteriormente.
La gestión de estas ventanas se dirige mediante
la secuencia de órdenes, y los resultados de prueba se registran en
el archivo Results, Res_File (figura 6).
La invención permite garantizar que los ensayos
se efectúan estrictamente como se define en el procedimiento. Se
facilita la ejecución de las pruebas de no regresión.
La ejecución de las pruebas puede efectuarse por
un operador que no tenga conocimientos profundos del sistema SE que
va a someterse a prueba.
La invención permite una trazabilidad completa
del proceso desde la aplicación del procedimiento: se garantiza
entre las especificaciones de sistema y los resultados de los
procedimientos de validación por medio de la base de datos
documental y de los escenarios de prueba automáticos.
Claims (12)
1. Método de preparación de una prueba de un
sistema electrónico (SE) que comprende varios equipos (CALC1, CALC2,
DISP1, DISP2, CALC3, CALC4) conectados por al menos una conexión de
comunicación (LIA, BUS), en el que, para efectuar la prueba:
- -
- se utiliza un banco de prueba (BT) adaptado al sistema electrónico (SE) que va a someterse a prueba que se conecta al sistema que va a someterse a prueba, y
- -
- se controla el banco de prueba según una secuencia de órdenes (Scenario_text_file) establecida a partir de al menos una especificación funcional informal (Functionnal_chain),
estando caracterizado el método de
preparación de prueba porque:
- -
- se crea la secuencia de órdenes (Scenario_text_file) a partir de un procedimiento de prueba (ATP, Test_Pro- cedure) que contiene una secuencia de objetos dotados de atributos, estando dotado al menos uno de los objetos de un atributo de trama que determina un emisor y un receptor entre los equipos del sistema SE, y que permite determinar un formato de transferencia de datos entre el emisor y el receptor, y
- -
- se registra la especificación funcional informal (Functionnal_chain), la secuencia de órdenes (Scenario_ text_file), así como al menos un enlace (Link) que identifica una especificación funcional informal (Functionnal_chain) a partir de la cual se ha establecido al menos una parte de la secuencia de órdenes, de manera que después de la ejecución de la secuencia de orden y el registro de los resultados de la prueba, puede leerse el enlace (Link) e identificar de manera unívoca la o las especificaciones funcionales informales (Functionnal_chain) correspondientes a los resultados de prueba obtenidos.
\vskip1.000000\baselineskip
2. Método según la reivindicación 1, en el que
la especificación funcional informal (Functionnal_chain) se registra
en forma de un archivo de texto.
3. Método según la reivindicación 1 ó 2, en el
que la secuencia de órdenes (Scenario_text_file) se registra en
forma de un archivo de texto.
4. Método según una cualquiera de las
reivindicaciones 1 a 3, en el que el enlace (Link) comprende la
dirección de una secuencia de órdenes (Scenario_text_file) y la
dirección de una especificación funcional informal
(Functionnal_chain).
5. Método según una cualquiera de las
reivindicaciones 1 a 4, en el que el procedimiento de prueba (ATP,
Test_Pro-
cedure) contiene objetos de simulación (TestSimu), objetos de observación (TestSpy) y objetos de control (TestCheck).
cedure) contiene objetos de simulación (TestSimu), objetos de observación (TestSpy) y objetos de control (TestCheck).
6. Método según una cualquiera de las
reivindicaciones 1 a 5, en el que el procedimiento de prueba (ATP,
Test_Pro-
cedure) contiene objetos de función que va a someterse a prueba (TestFunct).
cedure) contiene objetos de función que va a someterse a prueba (TestFunct).
7. Método según una cualquiera de las
reivindicaciones 1 a 6, en el que el procedimiento de prueba (ATP,
Test_Pro-
cedure) contiene datos de organización jerárquica de los objetos de función que va a someterse a prueba (TestFunct).
cedure) contiene datos de organización jerárquica de los objetos de función que va a someterse a prueba (TestFunct).
8. Método según una cualquiera de las
reivindicaciones 1 a 7, en el que, para crear la secuencia de
órdenes (Scenario_text_file) a partir de un procedimiento de prueba
(ATP, Test_Procedure) que contiene objetos de simulación (TestSimu),
objetos de observación (TestSpy) y/u objetos de control
(TestCheck), se eligen estos objetos entre objetos registrados en
una base de datos (Interf_DB) de configuración de los equipos, e
intercambios de datos entre los equipos, del sistema que va a
someterse a prueba.
\vskip1.000000\baselineskip
9. Método de realización de una prueba de un
sistema electrónico (SE) que comprende varios equipos (CALC1, CALC2,
DISP1, DISP2, CALC3, CALC4) conectados por al menos una conexión de
comunicación (LIA, BUS), en el que se prepara la prueba mediante un
método según una cualquiera de las reivindicaciones 1 a 8 y a
continuación:
- -
- se conecta un banco de prueba (BT) al sistema electrónico (SE) que va a someterse a prueba,
- -
- se lee una secuencia de órdenes (Scenario_text_file) y se controla el banco de prueba según la secuencia de órdenes (Scenario_text_file),
- -
- se registran los resultados de la prueba, y
- -
- se asocia a los resultados de la prueba al menos una especificación funcional (Functionnal_chain) enlazada a la secuencia de órdenes (Scenario_ text_file) mediante un enlace (Link) previamente registrado.
10. Método de realización de una prueba de un
sistema electrónico (SE) según la reivindicación 9 que comprende
varios equipos (CALC1, CALC2, DISP1, DISP2, CALC3, CALC4) conectados
por al menos una conexión de comunicación (LIA, BUS), en el que se
prepara la prueba:
- -
- preparando un procedimiento de prueba formal (ATP, Test_Procedure) que se conecta mediante uno o varios enlaces (Link) a una o varias especificaciones funcionales (Functionnal_chain) de requisitos para el sistema (SE),
- -
- produciendo automáticamente una secuencia de órdenes (Scenario_text_file), a partir de dicho procedimiento de prueba (ATP, Test_Procedure), que permite controlar un banco de prueba (BT) adaptado y conectado al sistema (SE) que va a someterse a prueba, utilizando una base de datos (Interf_DB) que contiene una definición de todas las señales susceptibles de intercambiarse por los equipos del sistema (SE), y
- -
- registrando dicha especificación funcional (Functionnal_chain), dicha secuencia de órdenes (Scenario_ text_file), así como dicho uno o varios enlaces (Link); a continuación:
- -
- se ejecuta el escenario de prueba (Scenario_text_file) en el banco de prueba controlando y registrando en un informe de ejecución (Res_File) el estado del sistema (SE) con respecto a la descripción proporcionada en el escenario de prueba, y
- -
- se informa automáticamente de los resultados del informe de ejecución en el procedimiento de prueba (ATP, Test_Procedure, ATR), permitiendo el (los) enlace(s) identificar de manera unívoca el conjunto de los requisitos del sistema (SE) que se han sometido a prueba mediante la ejecución del escenario de prueba y que corresponden a los resultados obtenidos.
11. Programa que comprende un código fijado
sobre un soporte o materializado mediante una señal, siendo el
código legible y/o ejecutable mediante al menos una unidad de
tratamiento de datos para estimular y someter a prueba el
funcionamiento de un sistema electrónico (SE), comprendiendo el
código segmentos de código para efectuar operaciones de un método
según una cualquiera de las reivindicaciones 1 a 8.
12. Sistema (SYST, BT) de prueba de un sistema
electrónico (SE), que se programa para ejecutar operaciones de un
método según una cualquiera de las reivindicaciones 1 a 8.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0705084 | 2007-07-13 | ||
| FR0705084A FR2918759B1 (fr) | 2007-07-13 | 2007-07-13 | Procede de test d'un systeme electronique |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2338829T3 true ES2338829T3 (es) | 2010-05-12 |
Family
ID=39284197
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES08012391T Active ES2338829T3 (es) | 2007-07-13 | 2008-07-09 | Metodo de prueba de un sistema electronico. |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US8606538B2 (es) |
| EP (1) | EP2015085B1 (es) |
| AU (1) | AU2008203256B2 (es) |
| ES (1) | ES2338829T3 (es) |
| FR (1) | FR2918759B1 (es) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8204711B2 (en) * | 2009-03-25 | 2012-06-19 | GM Global Technology Operations LLC | System and apparatus for managing test procedures within a hardware-in-the-loop simulation system |
| DE102009034242A1 (de) * | 2009-07-22 | 2011-01-27 | Volkswagen Ag | Verfahren und Vorrichtung zum Prüfen eines Steuergeräts eines Fahrzeugs |
| EP2375335A1 (en) | 2010-04-09 | 2011-10-12 | Eurocopter Deutschland GmbH | Method for automated testing of a system and automated testing system for such a method |
| US20110271252A1 (en) * | 2010-04-28 | 2011-11-03 | International Business Machines Corporation | Determining functional design/requirements coverage of a computer code |
| US8756571B2 (en) * | 2010-05-07 | 2014-06-17 | Hewlett-Packard Development Company, L.P. | Natural language text instructions |
| US8930908B2 (en) * | 2010-12-20 | 2015-01-06 | Sap Se | Aspect and system landscape capability-driven automatic testing of software applications |
| FR3018118B1 (fr) * | 2014-02-28 | 2016-04-29 | Airbus Helicopters | Procede de test d'un systeme electronique |
| EP3032270A1 (en) * | 2014-12-12 | 2016-06-15 | Airbus Defence and Space, S.A. | Method and system for performing electrical tests to complex devices |
| FR3035290B1 (fr) * | 2015-04-16 | 2018-11-30 | Airbus Operations | Carte electronique et systeme d'acquisition et de generation de signaux correspondant, comprenant un ou des commutateurs matriciels numeriques programmables |
| RU2617631C2 (ru) * | 2015-09-30 | 2017-04-25 | Акционерное общество "Лаборатория Касперского" | Способ обнаружения работы вредоносной программы, запущенной с клиента, на сервере |
| US10635998B2 (en) * | 2016-01-04 | 2020-04-28 | Caterpillar Inc. | Task assignment system and method for operating a test cell |
| US11142345B2 (en) | 2017-06-22 | 2021-10-12 | Textron Innovations Inc. | System and method for performing a test procedure |
| KR101901525B1 (ko) | 2017-09-11 | 2018-09-21 | 국방과학연구소 | 계층구조로 설계된 항공전자시스템용 다중모드 통합시험 장치 및 그 방법 |
| FR3101165B1 (fr) * | 2019-09-23 | 2021-10-15 | Ponant Tech | Procédé d’enregistrement de séquences de commande et de contrôle d’un robot de test, logiciel pour mise en œuvre de ce procédé |
| DE102019218904A1 (de) * | 2019-12-04 | 2021-06-10 | Volkswagen Aktiengesellschaft | Robustheitstestverfahren, Robustheitstestschaltung, Robustheitstestvorrichtung |
| FR3124257B1 (fr) * | 2021-06-22 | 2023-05-12 | Airbus Operations Sas | Procédé et système de test d’un calculateur avionique. |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE4100899A1 (de) | 1990-01-17 | 1991-07-18 | Schlumberger Technologies Inc | System fuer die steuerung des ablaufs von testsequenzen in einer informationsverarbeitungsvorrichtung |
| US5223788A (en) | 1991-09-12 | 1993-06-29 | Grumman Aerospace Corporation | Functional avionic core tester |
| EP0827608B1 (de) * | 1995-05-23 | 1998-11-11 | Daimler-Benz Aktiengesellschaft | Verfahren zur rechnergestützten messung und prüfung von elektrischen schaltungen, insbesondere von elektronischen baugruppen, und prüfplatz zur durchführung des verfahrens |
| FR2764072B1 (fr) * | 1997-05-30 | 1999-09-17 | Sextant Avionique | Procede et dispositif de test pour equipements electroniques |
| US5910895A (en) * | 1997-06-13 | 1999-06-08 | Teradyne, Inc. | Low cost, easy to use automatic test system software |
| JP2001101255A (ja) * | 1999-10-01 | 2001-04-13 | Toshiba Corp | 機能テスト支援システム、機能テスト支援方法およびハードウエア記述モデル |
| US7240303B1 (en) * | 1999-11-30 | 2007-07-03 | Synplicity, Inc. | Hardware/software co-debugging in a hardware description language |
| JP3670932B2 (ja) * | 2000-05-02 | 2005-07-13 | ペンタックス株式会社 | 回路基板検査システム及び回路基板 |
| FR2868567B1 (fr) | 2004-04-02 | 2008-03-14 | Airbus France Sas | Systeme de simulation et de test d'au moins un equipement sur un reseau afdx |
| US7392509B2 (en) * | 2004-04-13 | 2008-06-24 | University Of Maryland | Method for domain specific test design automation |
| US7979848B2 (en) * | 2005-04-29 | 2011-07-12 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Systems, methods and apparatus for pattern matching in procedure development and verification |
-
2007
- 2007-07-13 FR FR0705084A patent/FR2918759B1/fr not_active Expired - Fee Related
-
2008
- 2008-07-09 ES ES08012391T patent/ES2338829T3/es active Active
- 2008-07-09 EP EP08012391A patent/EP2015085B1/fr active Active
- 2008-07-11 US US12/171,311 patent/US8606538B2/en active Active
- 2008-07-22 AU AU2008203256A patent/AU2008203256B2/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| EP2015085B1 (fr) | 2010-01-06 |
| EP2015085A1 (fr) | 2009-01-14 |
| AU2008203256A1 (en) | 2009-01-29 |
| FR2918759A1 (fr) | 2009-01-16 |
| US20090019311A1 (en) | 2009-01-15 |
| FR2918759B1 (fr) | 2009-09-18 |
| AU2008203256B2 (en) | 2010-10-07 |
| US8606538B2 (en) | 2013-12-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2338829T3 (es) | Metodo de prueba de un sistema electronico. | |
| US8812284B2 (en) | Highly representative real-time simulation of an avionics system | |
| CN103530216B (zh) | 一种基于uvm验证方法学的pcie验证*** | |
| CN105404268B (zh) | 交通工具审核和交通工具***的维护和诊断控制 | |
| CN105446847B (zh) | 一种arinc659总线的自动化测试***及其方法 | |
| BR102013002439A2 (pt) | Sistema de manutenção de aeronave, método para prover manutenção para uma aeronave e método para operação de uma aeronave | |
| CN103439961B (zh) | 汽车电子控制单元诊断功能测试方法和*** | |
| CN109923518A (zh) | 用于安全关键***的软件更新机制 | |
| CN104216746B (zh) | 一种星上设备dsp程序地面在线烧写的实时监控和校验方法 | |
| CN108628265B (zh) | 用于运行自动化装置的方法和自动化装置 | |
| CN109634600A (zh) | 一种基于安全扩展SysML和AADL模型的代码生成方法 | |
| JP4413209B2 (ja) | シミュレーション装置 | |
| CN111813661A (zh) | 一种全局业务数据驱动自动测试方法、装置、设备和介质 | |
| CN108959678A (zh) | 用于测试卫星线束和信号处理单元的设计的方法和装置 | |
| CN109842534A (zh) | 一种基于交换式fc仿真卡的设备测试验证方法 | |
| US8819646B2 (en) | Control architecture and process for porting application software for equipment on board an aircraft to a consumer standard computer hardware unit | |
| CN102999663B (zh) | 一种soc芯片中的mmu的验证方法 | |
| KR102411945B1 (ko) | 철도차량의 실시간 현차 디버깅 및 시뮬레이션 시스템 | |
| US10055363B2 (en) | Method for configuring an interface unit of a computer system | |
| CA3155163A1 (en) | Development of a product using a process control plan digital twin | |
| CN110673592A (zh) | 一种微小卫星多个分***通用化的故障检测测试*** | |
| US10528689B1 (en) | Verification process for IJTAG based test pattern migration | |
| CN102662843B (zh) | 一种模拟航天器设备异常的软件测试方法 | |
| CN104296999B (zh) | 一种二乘二取二车载二线维护及测试平台 | |
| US20160224456A1 (en) | Method for verifying generated software, and verifying device for carrying out such a method |