Este post describe cómo funciona WITS en Eclipse Touch. Cubriremos algunos de los principios de diseño que entraron en el desarrollo, las características que surgieron de esos principios, y algunos ejemplos anotados de mensajes WITS que viajan a través del ecosistema Eclipse Touch.

Diseño

En un escenario de configuración punto a punto, WITS es de lo más sencillo: ambas partes acuerdan un conjunto de ID y sus significados y, a continuación, se procede al intercambio de datos utilizando la definición acordada a través de una simple conexión serie. En las primeras versiones de Eclipse Touch esto era básicamente todo lo que se soportaba. Cada instancia tenía un canal de entrada y otro de salida con valores codificados en cuanto a las claves que aceptaba y las que emitía. Si había un nuevo requisito, por ejemplo, un EDR particular estaba configurado para enviar información de profundidad con un UD no estándar, esto podría requerir una construcción especial o una nueva configuración que se añade a apoyar ese escenario. Además, si alguien quisiera enviar información a varios programas de registro, por ejemplo, tendría que ejecutar una copia adicional de Eclipse Touch para conseguirlo.

En general, cuando te encuentras haciendo muchos cambios para soportar escenarios específicos, es un buen indicador de que deberías dar un paso atrás y rediseñar para el caso más general. Debido a todas las combinaciones posibles de productores y consumidores de WITS y a los requisitos de los escenarios de configuración del cliente, no habría sido sensato crear algo que funcionara específicamente para cada configuración. Decidimos entonces reconstruir el marco WITS dentro de Eclipse Touch con los siguientes principios de diseño en mente.

Principios de diseño

• Flexibilidad: WITS debe ser compatible con cualquier configuración, dentro de lo razonable, que el cliente decida utilizar.
• Compatibilidad: La entrada y la salida de WITS deben ser completamente configurables para admitir cualquier consumidor o productor de WITS nuevo, antiguo o diferente.
• Facilidad de uso: Potencialmente en contraste con el principio de compatibilidad, WITS no debe ser tan difícil de configurar como para que sea inutilizable para alguien sin una amplia formación

Canales múltiples

Para satisfacer el principio de flexibilidad, se han añadido múltiples canales genéricos. Esto significa que ahora en cualquier instancia de Eclipse Touch se puede configurar con cualquier número de canales WTIS que se desee. Lógicamente, un canal WITS no es más que un puerto serie de la máquina en la que se ejecuta Eclipse Touch, junto con un mapa de entrada, un mapa de salida y otros ajustes. La idea de un canal WITS explícito de entrada o salida se descartó para hacer las cosas más genéricas y flexibles.

Figura 1. Configuración de WITS En la imagen se muestra la ventana de configuración de WITS dentro de Eclipse Touch. En este ejemplo, hay un canal configurado para hablar con un EDR, uno configurado para hablar con un Gamma Logger, y otro que no está configurado. Puedes añadir tantos como puertos COM tengas en tu máquina. Cada canal es configurable independientemente.

Mapas de entrada/salida

Cada instancia de Eclipse Touch puede configurar cualquier número de canales WITS y cada canal WITS tiene su propio mapa de entrada y salida configurable. Estos mapas determinan lo que cada canal WITS específico puede aceptar y lo que emitirá. Esto es lo que se requiere para ser compatible con cualquier sistema. El usuario puede ahora seleccionar específicamente lo que quiere aceptar y lo que quiere emitir y qué IDs deben utilizarse o esperarse.

Figura 2. Aquí se muestra la pantalla de configuración de mapeo de canal WITS individual. A la izquierda se define qué aceptará el canal y a qué etiqueta se asignará ese ID. A la derecha se define lo que el canal emitirá y qué IDs utilizar para cada etiqueta.

Disponibilidad en todas partes

Los datos WITS consumidos en cualquier canal WITS concreto de cualquier instancia de Eclipse Touch están disponibles para su salida en cualquier canal de cualquier instancia de la red LocalSync/RemoteSync. Esto contribuye enormemente a la facilidad de uso del sistema. Puede conectar cualquier consumidor o productor a la instancia de Eclipse Touch más cercana o más convenientemente disponible.

Origen de NetWITS

Curiosamente, la implementación de WITS en Eclipse Touch nació de las ideas y lecciones aprendidas del desarrollo y uso de NetWITS. NetWITS tomaría una entrada serial de WITS y la difundiría a cualquier número de otras instancias que funcionaran en la misma LAN sin hacer ninguna clase de traducción, cualquier valor que fuera entrado sería hecho salir directamente mientras que fue leído. La puesta en práctica del tacto de Eclipse de WITS tuvo que construir sobre esto e introducir una capa de la traducción, para ir de pares del valor de la identificación en los pares genéricos del valor de la etiqueta, que serían configurables por el canal.

Ejemplos prácticos

En términos generales, el flujo de trabajo es algo parecido a esto: Se lee un mensaje WITS en algún canal, se analiza su ID y se comprueba su presencia en el mapa de entrada. Si ese ID no existe en el mapa de entrada para ese canal, no ocurre nada más. Si se encuentra el ID, entonces el valor que se acaba de leer se asocia con la etiqueta traducida. Ese nuevo par de valores de etiqueta se transmite dentro de la red Eclipse Touch y no se vuelve a traducir a un par de valores de ID hasta que se encuentra con otro mapeo de canal WITS que contenga la etiqueta. Es decir, si otro canal está configurado para emitir esa etiqueta, es decir, tiene esa etiqueta asociada a algún ID, entonces se produce la traducción y ese nuevo par de valores ID que se acaba de construir se transmite a través del puerto serie configurado para ese canal.

A continuación se muestran algunos ejemplos de las diferentes configuraciones WITS que se pueden conseguir con Eclipse Touch.