Han pasado casi 40 años desde la introducción por parte de Hewlett-Packard del Hewlett-Packard Interface Bus (HP-IB), diseñado para controlar la instrumentación. HP-IB se convirtió en un estándar de facto del sector formalizado como IEEE-488 y también conocido habitualmente como General Purpose Interface Bus o GP-IB.

En los últimos 40 años se ha hecho mucho por mejorar el entorno de programación de software para la interfaz IEEE-488. Mejoras como la ampliación de IEEE-448.2 según el estándar definieron una serie de comandos de instrumento y bus de bajo nivel que un instrumento debía admitir para ser compatible. La industria también ha adoptado la estandarización de comandos de programación de nivel superior para instrumentos conocidos como Standard Commands for Programmable Instruments, o SCPI, lo cual ha llevado a una mejora considerable del tiempo de desarrollo de las pruebas, así como a una reducción del tiempo para el mantenimiento del software existente. Si bien la implementación de SCPI es ampliamente aceptada por los proveedores de instrumentos, un ingeniero que automatice instrumentos todavía es responsable de gran parte de la codificación de los instrumentos.

Los esfuerzos por crear un mayor nivel de abstracción para la automatización de instrumentos condujeron primero a controladores de instrumentos del entorno de programación propios y, más tarde, a controladores basados en estándares más interoperables. Los instrumentos de hoy en día realizan una amplia variedad de análisis y medidas complejos, y muchos se han diseñado para funcionar como una aplicación en un sistema operativo Microsoft. La infraestructura .NET de Microsoft permite a los proveedores de instrumentos habilitar el acceso a muchos más conocimientos sobre medidas del instrumento sin tener que abrir la guía del programador de SCPI ni aprender a utilizar un conjunto de controladores específico. La aparición de software controlador de instrumentos alojado en una tecnología .NET de Microsoft ha proporcionado al ingeniero de automatización un desarrollo más rápido de software de prueba y un acceso más sencillo a los conocimientos sobre medidas complejas desarrolladas por el instrumento.
En este artículo se pretende ilustrar cómo la tecnología .NET implementada por un proveedor de osciloscopios en su producto de prueba de cumplimiento del transmisor digital ofrece conocimientos sobre medidas de valor añadido fácilmente accesibles por el código de automatización de sus clientes. La tecnología .NET ha permitido la creación de un marco común utilizado para construir todas sus aplicaciones de cumplimiento de comunicación de datos compatibles diseñadas para hacer frente a las pruebas de los transmisores digitales según un estándar en concreto. La tecnología .NET no solo ha ayudado a los desarrolladores internos del proveedor de osciloscopios, sino que también ha proporcionado un nivel muy elevado de abstracción para que sus clientes puedan aprovechar la ejecución remota y la automatización del cliente. Las medidas del actual ecosistema de dispositivos digitales se han ido haciendo más complejas a medida que los dispositivos van más rápido y son más pequeños. Hasta hace poco, el ingeniero de automatización se encargaba de crear los algoritmos de medida necesarios para realizar pruebas de conformidad con un estándar determinado, como PCI Express, SAS y otros estándares de comunicación de datos. Los clientes de hoy en día sencillamente no disponen del personal de ingeniería de software para mantenerse al día de los continuos cambios en los estándares de comunicación de datos. Los clientes esperan ahora que los proveedores de osciloscopios proporcionen el software necesario para cualificar un dispositivo como compatible con un determinado estándar.
    

En las primeras versiones de osciloscopios, era habitual que los ingenieros crearan sus propios algoritmos para medir el tiempo de subida y el tiempo de bajada de una señal eléctrica. No fue hasta finales del siglo XX que estas medidas se incorporaron en el firmware de un osciloscopio. En la década de 1990, los ingenieros esperaban que sus osciloscopios ofrecieran funciones de medida básicas, como la medida del tiempo de subida. En el siglo XXI, un cliente espera de un proveedor de osciloscopios que asuma los retos de prueba para un estándar de comunicación de datos concreto y que proporcione la solución de medida completa, además de facilidad de acceso a través de su propio código de automatización. La oferta de productos de un proveedor de osciloscopios debe demostrar una inversión continuada en conocimientos sobre medidas destinada a hacer frente a los requisitos de los estándares de comunicación de datos actuales y futuros.
Un proveedor de osciloscopios que incorpore más conocimientos sobre medidas en su oferta de productos es, por lo general, un miembro activo de organismos de estandarización como PCI Express, SATA, JEDEC y USB-IF. La participación activa en estos estándares permite al proveedor ayudar a definir las especificaciones de prueba destinadas a garantizar la interoperabilidad de los dispositivos compatibles con un estándar en concreto. Una vez definidos los requisitos de prueba, el proveedor del osciloscopio puede implementar las diversas medidas definidas por el estándar e incorporarlas a la oferta de software de su osciloscopio. Entonces un cliente puede acceder a un conjunto de software de prueba conforme al estándar habilitado por la tecnología .NET del proveedor del osciloscopio para establecer el cumplimiento de su dispositivo con un estándar de comunicación de datos en concreto. Además de proporcionar una interfaz gráfica de usuario sencilla para que el cliente pueda utilizar el osciloscopio, la plataforma de software también debe permitir el pleno acceso por control remoto. Un proveedor de osciloscopios que proporcione paquetes de prueba para una gran variedad de estándares de comunicación de datos aumenta considerablemente la productividad del personal de ingeniería del cliente. El proveedor de osciloscopios asume la responsabilidad de interpretar las especificaciones de prueba de un estándar, y tiene la tarea de desarrollar el paquete de software de medida y proporcionar soporte técnico. Además, el hecho de que el proveedor del osciloscopio proporcione el paquete de software de medida permite una mejor correlación de los datos de prueba entre los propios equipos de ingeniería de un cliente y los equipos de su cliente, sabiendo que todas las partes utilizan pruebas y algoritmos comunes.
 
En la figura 1 se muestra un ejemplo de un paquete de software que expone las pruebas disponibles definidas en el estándar relativo a la memoria de un ordenador DDR4. El cliente selecciona las pruebas de interés y las medidas, y los algoritmos apropiados son implementados por el software automatizado del proveedor del osciloscopio. Es importante buscar un proveedor de osciloscopios que ofrezca coherencia en todo su software de medida basado en estándares. Un paquete de prueba de software de DDR4 debe mantener la coherencia con uno para PCI Express, lo cual incrementa la eficiencia y productividad del usuario final.
 
Un paquete de software completo para la realización de pruebas conforme a un estándar de comunicación de datos debería producir datos de una forma fácilmente legible, como se muestra en el ejemplo siguiente de la figura 2. Un informe HTML que incluya capturas de pantalla, si procede, de todas las pruebas ejecutadas con información de margen/aprobado/suspenso genera un gran valor para el cliente a la hora de compartirla con sus propios equipos de ingeniería, así como con sus clientes.
 
    Los actuales osciloscopios del siglo XXI se consideran hoy en día sistemas de medida que incluyen un sondeo innovador para el acceso a señales no accesibles mediante un cable de RF directo. Son necesarios motores algorítmicos basados en FPGA impulsados por el acceso a lenguajes de cifrado externos junto con bibliotecas matemáticas para analizar y producir muchos de los valores de medida exigidos por los dispositivos digitales modernos. No solo es importante acceder a las pruebas deseadas a través de una interfaz gráfica de usuario interactiva, como se muestra en la figura 1, sino que es igualmente importante poder ejecutar las pruebas desde el código de automatización del cliente. Puede que el ingeniero de automatización también necesite controlar fuentes de alimentación o cámaras ambientales antes de ejecutar una prueba prescrita, además de integrar los datos medidos en una base de datos corporativa. Un proveedor de osciloscopios que pueda proporcionar una interfaz de automatización perfecta para las mismas funciones expuestas en la interfaz gráfica de usuario interactiva no solo proporciona un gran valor al ingeniero de automatización sino que, y lo que es más importante, una mejor utilización de los recursos de ingeniería de las compañías. Un marco de software basado en la tecnología .NET permite al ingeniero de automatización acceder a todas las funciones del software de medida del proveedor del osciloscopio diseñado para un estándar de comunicaciones de datos. Además, permite a los ingenieros adentrarse en eventos de tiempo de ejecución asíncronos con el fin de integrar la automatización de instrumentos de apoyo, por ejemplo, respondiendo mediante programación al indicador de mensaje "Cambie la salida de la fuente de alimentación a 1 V y haga clic en 'Aceptar' para continuar". Estos eventos ya no necesitan la intervención manual que siempre es tan lenta.
    El siguiente ejemplo en Python de cómo utilizar un conjunto .NET puede proporcionar un nivel perfecto de abstracción al ingeniero de automatización sin sobrecargarlo con los detalles de la configuración de las condiciones de prueba, la gestión del flujo de prueba y, en última instancia, la gestión de los datos medidos. El motor Common Language Runtime de Microsoft permite una carga fácil de un conjunto .NET desde diversos lenguajes de programación como Visual Basic, C#, C++ así como lenguajes de programación gráfica como VeePro de Keysight y LabWindows y LabView de NI. Además, la tecnología .NET se puede ampliar para dar cobertura a una amplia variedad de tareas de automatización, incluido el control de cámaras ambientales, la comunicación con el dispositivo sometido a prueba, matrices de conmutación y, por supuesto, otros instrumentos además de un osciloscopio.
import clr
clr.AddReference("Keysight.Infiniium.AppFW.Remote")
from Keysight.Infiniium.AppFW.Remote import *
Necesario para conectar el osciloscopio a través de una conexión Ethernet para el acceso a los métodos y las propiedades expuestos en los conjuntos .NET.
remoteObj = RemoteAteUtilities.GetRemoteAte("192.168.1.107")
remoteApp = IRemoteAte(remoteObj)
    El objeto denominado remoteApp puede acceder ahora a todas las funciones del paquete de software de medida específico para el estándar de comunicación de datos seleccionado como si se hiciera de manera interactiva desde la interfaz gráfica de usuario del paquete de prueba. A continuación se muestra el código que el ingeniero de automatización necesita para crear un nuevo proyecto similar a realizar Archivo->Nuevo proyecto desde la interfaz gráfica de usuario del paquete de software de medida.
remoteApp.NewProject(True)

    El siguiente recupera la misma información que se presentaba en la figura 1 al ejecutar el paquete de software de medida de forma interactiva. Una vez que el ingeniero de automatización conoce las pruebas disponibles, se pueden seleccionar mediante programación de forma similar a marcar una casilla de verificación junto a los nombres de las pruebas de la figura 1. De hecho, la interfaz gráfica de usuario reflejará lo que el ingeniero programó de forma remota, lo cual ayuda en gran medida a la depuración del código.
myAvailableTests = remoteApp.GetCurrentOptions("TestsInfo")
para obtener información en myAvailableTests:  // Lo siguiente para el bucle extrae los nombres e id de las pruebas disponibles
  myTestName = info.Name  
  myTestId = info.ID
testToSelect = myAvailableTests[0].ID // La primera prueba de las pruebas disponibles se selecciona para su ejecución
remoteApp.SelectedTests = [testToSelect]
Lo siguiente ejecuta la prueba seleccionada y crea el informe HTML, como se muestra en la figura 2. El archivo MY_HTML se crea en la carpeta C:\data.
remoteApp.Run()
descriptionHtmlString = 'MY_HTML'
saveResultHtmlOptions = ExportHtmlOptions()
saveResultHtmlOptions.ReportName = descriptionHtmlString
saveResultHtmlOptions.OverwriteExisting = True
saveResultHtmlOptions.BasePath = "C:\data"
remoteApp.ExportResultsHtmlCustom(saveResultHtmlOptions);
Una pieza fundamental de la documentación para un uso eficiente del conjunto .NET es un archivo de ayuda completo y actualizado del proveedor del osciloscopio. Un extracto de un archivo de ayuda mostrado a continuación define qué opciones están disponibles cuando se crea un informe HTML. Las opciones se implementan en el ejemplo de Python anterior.
Propiedades de ExportHtmlOptions    Interfaz remota de Keysight DigitalTestApps para .NET
Interfaz remota versión 3.40
El tipo ExportHtmlOptions expone los siguientes miembros.

Propiedades
Nombre  y  Descripción
BasePath: Ruta para guardar el informe. Se creará un subdirectorio con el nombre ReportName.

OverwriteExisting: Defina esta propiedad como verdadera para sobrescribir un informe existente con el mismo nombre en la ubicación especificada.
ReportName: Nombre del informe que se desea generar.

Mejores todavía son las indicaciones integradas en la interfaz gráfica de usuario, que responden a preguntas como "¿qué comando de automatización selecciona esta casilla de verificación?".
Las compañías ya no pueden permitirse destinar valiosos recursos de ingeniería para comprender todos los requisitos de prueba de un estándar de comunicación de datos en concreto, y posteriormente financiar el desarrollo del software necesario para realizar las medidas exigidas por el estándar de comunicación de datos. Una vez que el proveedor del osciloscopio se convierte en el proveedor del paquete de software de medida para un estándar de comunicación de datos en concreto, los ingenieros del cliente pueden centrarse más rápidamente en obtener valiosa información acerca de su producto a partir de los datos de medida generados por el paquete de software de medida. La posibilidad de correlacionar los datos obtenidos de diferentes osciloscopios que utilicen una misma versión del paquete de software de medida mejora la productividad del personal de ingeniería del cliente. Los clientes seguirán acudiendo a los proveedores de osciloscopios para que les proporcionen un osciloscopio como sistema de medida que incluya soluciones de conectividad con su dispositivo, como sondas, paquetes de software de medida que aborden los diferentes estándares de comunicación de datos y un alto nivel de abstracción del paquete de software de medida, lo cual permite a los ingenieros de automatización controlar fácilmente la ejecución del paquete de software de medida desde su software de automatización interno.

Más información