Prueba de sistema operativo en tiempo real para dureza

Question

Tengo un dispositivo incrustado (Technologic TS-7800) que anuncia capacidades en tiempo real, pero no dice nada acerca de "duro" o "suave". Mientras espero una respuesta del fabricante, pensé que no estaría de más probar el sistema yo mismo.

¿Cuáles son algunos procedimientos establecidos para determinar la "dureza" de un dispositivo particular con respecto al comportamiento en tiempo real/determinista (latencia y jitter)?

Al estar en la universidad, tengo acceso a hardware bastante bueno (buenos osciloscopios y generadores de señales), así que no creo que tenga problemas en términos de pruebas de equipo, solo experiencia.

Answer 1

Tengo la misma placa aquí en el trabajo. Es un 2.6 kernel ligeramente modificado, creo ... no es la versión en tiempo real.

No sé si he leído algo en los documentos que indique que está diseñado para un trabajo estricto de RTOS.

Answer 2

Con este tipo de equipo, debería ser bastante fácil sincronizar el o-scope con un reloj estable, producir un pico cada vez que el sistema en tiempo real produce una salida, y ver cuánto varía el punto desde el centro . Cuanto menor es la variación, mayor es la dureza.

Answer 3

Para aclarar la respuesta de Bob quizá:

usar el generador de señal para generar un pulso a una frecuencia variable. La distribución aleatoria en algún rango sería la mejor.

utilice el generador de señal (señal de disparo) para iniciar el osciloscopio.

RTOS tiene que responder, hacerlo y enviar un pulso de salida.

alimenta la salida RTOS a la entrada 2 del osciloscopio.

obtener el alcance para persistir/modo de recopilación. obtenga el alcance para comenzar en A, pare en B. si puede.

en un trabajo ideal, hazlo para medir la distribución por ti. Un LeCroy lo haría. Comience con un seguimiento mucho más lento de lo que cabría esperar. Necesita poder ver valores atípicos lentos. Podrá ver la distribución.
Suponiendo una distribución normal, la SD de la variación del tiempo de respuesta es SUAVIDAD. (Esto realmente no sucederá en la práctica, pero si no se obtienen valores atípicos, es razonablemente útil.) Si hay valores atípicos de latencia grande, entonces el RTOS NO es muy difícil. No cumple bien los plazos. Inadecuado, entonces es para el trabajo duro en tiempo real. Muchas cosas de tipo RTOS tienen un buen borde izquierdo hacia la curva, inclinado hacia abajo como una curva 1/f. Eso es indicativo de nerviosismo combinado. Lo que hay que tener en cuenta son los picos de respuesta lenta en el extremo derecho del alcance. Siga repitiendo el experimento con trazas más rápidas si no hay valores atípicos para obtener una buena imagen de la pendiente. Debería ser bueno para algunas conclusiones especulativas en su artículo.

Si para su aplicación, digamos que un delta de 1uS está bien, y mide 0.5us, todo está bien.

De todos modos, puede publicar los resultados (y probablemente en el publicar sentido, pero sin duda en la web.)

Enlace de esta pregunta al papel cuando lo haya escrito.

Answer 4

Entiendo que soy geek, pero usar osciloscopio para probar una computadora con ethernet/usb/otros puertos digitales y ENORME estado interno (RAM) es ineficaz y poco confiable.

En lugar de ver formas de onda, puede conectar cualquier PC al puerto de salida y ejecutar un análisis estadístico adecuado. El procedimiento establecido (si la señal de entrada es analógica por naturaleza) es probar el sistema contra varias entradas características, tradicionalmente picos, funciones escalonadas y ondas sinusoidales de diferentes frecuencias, y medir el desplazamiento de fase y la varianza para cada tipo de entrada. El peor caso se usa luego en las especificaciones del sistema.

Nuevamente, si está utilizando puertos estándar, puede generarlos fácilmente en la PC. Si la entrada es verdaderamente analógica, se necesitaría un DAC separado o simplemente una buena tarjeta de sonido.

Ahora, eso no dice nada acerca de que el SO sea en tiempo real: podría estar ejecutando Linux vainilla o incluso Win CE y aún así producir resultados buenos y estables en esas pruebas si el hardware es lo suficientemente rápido.

Por lo tanto, debe simular cargas pesadas y variables en el procesador, la memoria y todos los puertos, dejar que se caliente y comer memoria durante unas horas, y luego repetir las pruebas. Si la latencia se mantiene constante, es difícil en tiempo real. Si no lo hace, bajo cualquier carga y tipo de señal de entrada, aumente por encima del límite aceptable, es suave. De lo contrario, es publicidad.

P.S .: La implicancia es que, incluso para sistemas críticos, en realidad no se necesita una gran cantidad de hardware en tiempo real.

Answer 5

El hardware en tiempo real tiene más que ver con la forma en que funciona su software que con el hardware en sí mismo. Al preguntar si algo es difícil en tiempo real, debe aplicarse al sistema completo (Hardware, RTOS y aplicación). Esto significa problemas de diseño de sistemas en tiempo real o blandos.

Bajo carga que excede la especificación, incluso un sistema en tiempo real difícil fallará (con la debida indicación de falla) mientras que un sistema blando en tiempo real con poca carga daría resultados duros en tiempo real. La cantidad de procesamiento que debe pasar en el tiempo y la cantidad de procesamiento previo/posterior que se puede realizar es la verdadera clave para el hard/soft en tiempo real.

En algunas aplicaciones en tiempo real, la pérdida de algunos datos no es una falla, solo debería estar por debajo de un cierto nivel, de nuevo un criterio del sistema.

Puede generar entradas en la placa y tener una pequeña aplicación contarlas y verificar a qué nivel se van a perder los datos. Pero eso le da una calificación específica para ese sistema que ejecuta esa aplicación. Tan pronto como comienza a hacer más procesamiento aumenta su carga de cómputo y ahora tiene un límite diferente de tiempo real.

Esta placa ejecutará un planificador bare bones dará un gran rendimiento predecible en tiempo real para la mayoría de las tareas. Al ejecutar un RTOS completo con una gran carga computacional, es probable que solo obtenga blando en tiempo real.

Edit after comment
La forma más eficiente y más fácil que he utilizado para medir el rendimiento de mi software (suponiendo que se utiliza un cedular) es mediante el uso de un temporizador de hardware de funcionamiento libre en el tablero y en cuando estampar mi inicio y el final de mi ciclo . O si ejecuta un sello de tiempo RTOS completo, adquiere y transmite. Ahorre su tiempo máximo y ejecute un promedio de los valores en un segundo. Si su promedio es de alrededor del 50% y su máximo está dentro del 20% de su promedio, está bien. Si no, es hora de refactorizar su aplicación. A medida que su aplicación crezca, el tiempo de ciclo crecerá. Puede controlar el efecto de todos los cambios de software en su tiempo de ciclo.

Otra forma es utilizar un temporizador de hardware generar una interrupción cíclica. Si está a tiempo, reinicie la interrupción. Si pierde la fecha límite, significa que la señal del controlador de interrupción es un error.Sin embargo, esto solo le dará una advertencia una vez que la aplicación demore demasiado, pero depende del hardware y las interrupciones, por lo que no puede perderse.

Estas soluciones también eliminan el requisito de conectar un endoscopio para controlar la salida, ya que la información de tiempo puede mostrarse en cualquier tipo de terminal mediante una tarea en segundo plano. Si es fácil de controlar, lo controlará regularmente evitando resolver los problemas de sincronización al final, pero tan pronto como se introduzcan.

Espero que esto ayude

Answer 6

Creo que este no es un dispositivo duro en tiempo real, ya que no ejecuta RTOS.