ES2908320T3

ES2908320T3 - Método de comunicación de dispositivos médicos

Info

Publication number: ES2908320T3
Application number: ES14760652T
Authority: ES
Inventors: Prakash Jha; James Cudney; Benjamin Herr; Mark Lee; Matteo Picinich
Original assignee: ICU Medical Inc
Current assignee: ICU Medical Inc
Priority date: 2013-03-06
Filing date: 2014-03-06
Publication date: 2022-04-28
Anticipated expiration: 2034-03-06
Also published as: EP2964079A4; CA2904053A1; EP2964079B1; US20140254598A1; AU2014225658A1; US20230188465A1; CA2904053C; US20200145332A1; US10333843B2; US20210105206A1; US11470000B2; WO2014138446A1; US20170331735A1; EP2964079A1; US9641432B2; AU2014225658B2; US10812380B2

Abstract

Un método de comunicación de dispositivos médicos para un sistema de bomba de infusión, comprendiendo el método: un control de motor de bomba, PMC, que acepta una solicitud de conexión de un controlador de interfaz de usuario, UIC, comprendiendo la solicitud: un identificador de dispositivo del UIC, un número de dispositivo receptor del PMC al que transmitir un mensaje de datos de infusión, en donde el PMC acepta dicha solicitud y genera un identificador de comunicación, CID, introducir el CID en un mensaje de aceptación de conexión, transmitir el mensaje de aceptación de conexión al UIC, en donde el UIC extrae y almacena el CID del mensaje de aceptación de conexión, comprendiendo además el método aceptar, por el UIC, una solicitud de infusión asociada con una función médica relacionada con la infusión, introducir el CID y dicha función médica en el mensaje de datos de infusión, y transmitir el mensaje de datos de infusión al PMC.

Description

DESCRIPCIÓN

Método de comunicación de dispositivos médicos

Antecedentes de la invención

Campo de la invención

Una o más realizaciones de la invención están relacionadas con el campo de los protocolos de comunicación de multiplexación para dispositivos médicos tales como, pero sin limitarse a, bombas de infusión. Más particularmente, pero sin limitarse a ello, las realizaciones de la invención permiten un método de comunicación de dispositivos médicos para la comunicación entre periféricos y subsistemas conectados que incluye intercambio de datos orientados a conexión, sin conexión, de difusión y de multidifusión, con tratamiento prioritario de datos, fragmentación y reensamblaje de datos, asignación de direcciones estáticas y dinámicas únicas y capacidades de intercambio en caliente.

Descripción de la técnica relacionada

Los dispositivos que intercambian datos generalmente lo hacen mediante un protocolo de comunicación. Los protocolos de comunicación permiten que se transmitan y reciban datos de forma controlada. Los dispositivos médicos son dispositivos de ejemplo que pueden utilizar un protocolo de comunicación, por ejemplo, para intercambiar datos entre periféricos o subsistemas que generan o utilizan datos. Hay muchos tipos de protocolos de comunicación que varían en complejidad, eficiencia y utilización de hardware. Los protocolos de comunicación actuales utilizados en los dispositivos médicos utilizan el sistema operativo y la arquitectura de bus particular dentro del dispositivo médico. Un problema con este tipo de arquitectura es que algunas implementaciones pueden impedir el acceso multiplexado en el tiempo del enlace de comunicación, con ello imposibilitando o impidiendo de otro modo que múltiples aplicaciones se comuniquen simultáneamente. Además, las aplicaciones que transfieren datos utilizando el sistema operativo y llamadas de software específicas de bus tienen que ser modificadas cuando cambia el sistema operativo o la arquitectura de bus, específicamente para tener en cuenta las diferencias en las llamadas del sistema operativo o con respecto a la arquitectura de bus, diferentes formatos de datos, secuenciación y cualquier otro matiz específico del protocolo. Además, los dispositivos médicos en general deben someterse a pruebas exhaustivas para garantizar que no fallen. Por lo tanto, cambiar las arquitecturas de bus aumenta los costos asociados con las aplicaciones que hacen uso de la arquitectura de bus, ya que la aplicación debe volver a probarse si se modifica el código fuente de la aplicación.

Los protocolos de comunicación conocidos generalmente están dirigidos a un tipo específico de arquitectura de bus de comunicación, por ejemplo, Ethernet, WiFi, Bluetooth, CAN, Serial, I2C, SPI, etc. Los protocolos de comunicación conocidos en general no se pueden usar con más de un tipo de bus de comunicación dado que intentan dar solución a un problema de comunicación concreto de forma coherente. Debido a los requisitos de baja potencia, las capacidades limitadas del procesador y la capacidad de memoria limitada de los dispositivos médicos con procesadores integrados que realizan funciones o tareas específicas, tales como bombas de infusión, los protocolos de comunicación sofisticados existentes generalmente no se utilizan en dichos dispositivos médicos.

En resumen, las soluciones conocidas utilizan protocolos de comunicación que están vinculados a un sistema operativo y/o bus de comunicaciones específico. Desafortunadamente, estos protocolos de comunicación no son independientes de todos los tipos de bus de comunicación y no proporcionan una pila de protocolos eficiente y ligera para la comunicación dentro del dispositivo que incluye intercambio de datos orientados a conexión, sin conexión, de difusión y de multidifusión con tratamiento prioritario de datos, fragmentación y reensamblaje de datos, asignación de direcciones estáticas y dinámicas únicas para subsistemas conectados y capacidades de intercambio en caliente. La patente del estado de la técnica US 5432777 describe una transferencia de datos ATM sin conexión, la patente US 7171492 describe la asignación de múltiples direcciones de red, y la patente US 2007/258395 describe un sistema de comunicación de datos inalámbrico para una red de dispositivos médicos.

Para al menos las limitaciones descritas anteriormente, existe la necesidad de un método de comunicación de dispositivos médicos que proporcione estas características, tal como se describe y reivindica en este documento. Breve compendio de la invención

La invención se lleva a cabo tal como se describe en las reivindicaciones adjuntas.

Las realizaciones de la invención permiten un método de comunicación de dispositivos médicos para comunicación entre periféricos médicos y subsistemas que incluye intercambio de datos orientados a conexión, sin conexión, de difusión y de multidifusión, con tratamiento prioritario de datos, fragmentación y reensamblaje de datos, asignación de direcciones estáticas y dinámicas únicas y capacidades de intercambio en caliente.

Las realizaciones del protocolo de comunicación proporcionan una interfaz que se separa o se abstrae del sistema operativo y la arquitectura de bus subyacente dentro del dispositivo médico, lo que hace que el comportamiento y la interfaz del protocolo de comunicación sean coherentes en las arquitecturas de bus y los sistemas operativos, lo que se desconoce en la técnica de bombas de infusión. Por lo tanto, la misma aplicación se puede utilizar en múltiples plataformas de hardware, por ejemplo, sin alterar la propia aplicación. Por lo tanto, las realizaciones permiten un código de aplicación simplificado, la portabilidad del mismo y minimizar los requisitos de mantenimiento y prueba. Las realizaciones pueden utilizar cualquier tipo de ruta de comunicación física, por ejemplo, inalámbrica o cableada, incluyendo, entre otros, un bus de datos. Las realizaciones para comunicaciones entre dispositivos sobre un bus de datos generalmente emplean controladores de bus de datos específicos para cada tipo de bus de datos para controlar la lectura y escritura de datos sobre el bus junto con una interfaz estándar para estos controladores de bus de datos.

Las realizaciones pueden implementarse en capas separadas de software configuradas para ejecutarse en uno o más elementos informáticos, donde cada capa realiza operaciones para proporcionar un intercambio de datos que generalmente es independiente de las otras capas. Cada capa, por ejemplo, puede crear, leer o actualizar cabeceras asociadas con datos a intercambiar, donde las cabeceras contienen información para soportar las características mencionadas anteriormente. Las capas forman lo que se conoce como pila de protocolos. Las realizaciones de la pila de protocolos pueden incluir una capa de administrador, una capa de sesión, una capa de transporte y una capa de enlace de datos o cualquier otra arquitectura siempre que la implementación resultante proporcione la funcionalidad descrita en este documento.

Según el periférico o subsistema, el tipo de datos, la prioridad y la fiabilidad deseada de los datos que se van a intercambiar, las aplicaciones pueden transmitir datos utilizando intercambio de datos orientados a conexión, para garantizar la entrega de datos, o intercambio de datos sin conexión, para datos menos confidenciales. Las realizaciones también admiten modos de intercambio de datos de difusión y multidifusión uno a uno, así como uno a muchos y muchos a uno, entre periféricos conectados y subsistemas. Al menos una realización también admite el intercambio de datos basado en prioridad y da preferencia a los datos de alta prioridad sobre los datos de baja prioridad para garantizar que los mensajes de alta prioridad se entreguen primero. Además, al menos una realización soporta fragmentación de datos y el reensamblaje de datos para cumplir con demandas de la tecnología de comunicación física particular. Las realizaciones también proporcionan una asignación de dirección estática y dinámica única para subsistemas conectados y capacidades de intercambio en caliente, que son desconocidas, por ejemplo, en las bombas de infusión actuales.

Específicamente, en el caso de la comunicación orientada a conexión, al menos una realización utiliza un ID de comunicación o "CID" como testigo para identificar de forma única todas las conexiones activas dentro de un subsistema y enrutar los datos entre las respectivas aplicaciones. En el caso de comunicaciones sin conexión, al menos una realización utiliza números de puerto, por ejemplo, números de puerto de origen y de destino, para identificar la aplicación de destino. Al menos una realización soporta servicios de suscripción para aplicaciones receptoras, lo que permite la multidifusión de datos a todas las aplicaciones suscritas. La multidifusión puede ser tanto orientada a conexión como sin conexión. En las sesiones de comunicación orientadas a conexión, al menos una realización garantiza la entrega de datos, por ejemplo, mediante acuses de recibo. Alternativamente, las sesiones de comunicación sin conexión no garantizan la entrega de datos, pero son muy eficientes. Al menos una realización soporta difusión de datos/mensajes, donde los mensajes de difusión se envían a todos los subsistemas conectados al subsistema de difusión.

Es posible que las aplicaciones necesiten intercambiar datos de mayor tamaño que el que puede soportar una tecnología de comunicación subyacente o un bus de datos. En tales casos, al menos una realización rompe o fragmenta los datos en un tamaño menor, por ejemplo, del que el bus de datos realmente puede transferir. Al menos una realización vuelve a ensamblar datos en el tamaño de datos original en el extremo receptor. Al menos una realización se ejecuta en sistemas integrados que pueden tener recursos limitados, incluyendo la memoria, la potencia de procesamiento, la utilización del bus y la potencia. Por lo tanto, las realizaciones utilizan eficientemente los recursos disponibles. Los intercambios de datos de ejemplo que son lo suficientemente grandes como para garantizar la fragmentación de los mensajes incluyen descargas de bibliotecas de medicamentos y actualizaciones de software inalterable.

Con respecto a la fragmentación, al menos una realización utiliza una ventana que representa un cómputo de fragmentos que pueden enviarse antes de recibir un acuse de recibo del receptor. En al menos una realización, el transmisor solicita el tamaño de la ventana al receptor antes de enviar el primer fragmento. El receptor determina el espacio de memoria disponible para acomodar los paquetes recibidos y responde con el tamaño de la ventana, por ejemplo, como un múltiplo entero del tamaño máximo de tramas que cabe en la memoria disponible. El transmisor numera los fragmentos en secuencia y los envía al receptor. Después de que se hayan enviado mensajes del tamaño de una ventana, el transmisor espera un acuse de recibo del último fragmento. El receptor acumula todos los fragmentos recibidos y verifica que todos los fragmentos recibidos estén en secuencia. Si no falta ningún fragmento, el receptor envía el número de fragmento del último fragmento como acuse de recibo o, de lo contrario, envía los números de fragmento de los fragmentos faltantes como parte de un acuse de recibo negativo o NAK.

Dado que los dispositivos médicos, tales como las bombas de infusión, en el futuro pueden incluir periféricos o subsistemas intercambiables en caliente, al menos una realización soporta asignaciones de direcciones únicas a dispositivos conectados para proporcionar un intercambio de datos sin conflicto, reduciendo así la complejidad en las aplicaciones. Al menos una realización soporta comunicación sobre múltiples tecnologías de transferencia de datos subyacentes, como serie, CAN, SPI, SDIO, USB o cualquier otro tipo de medio físico o bus de datos. Al menos una realización también realiza un seguimiento de los dispositivos conectados en cada bus y enruta los datos al bus respectivo.

Breve descripción de los dibujos

Los anteriores y otros aspectos, características y ventajas de la invención serán más evidentes a partir de la siguiente descripción más particular de la misma, presentada junto con los siguientes dibujos en los que:

La figura 1 ilustra una vista arquitectónica de un sistema que tiene un controlador de interfaz de usuario, y múltiples periféricos que se comunican entre sí usando una realización de la invención.

La figura 2 ilustra una realización en capas jerárquicas de la invención implementada como una pila de protocolos. La figura 3 ilustra una realización de un método de solicitud de dirección implementado dentro de la capa de administrador.

La figura 4 ilustra una realización de una secuencia de infusión simple que utiliza varios mensajes proporcionados por las realizaciones del método.

La figura 5 ilustra una realización de un método de conexión implementado dentro de la capa de sesión.

La figura 6 ilustra una realización de un método de intercambio de datos implementado dentro de la capa de sesión. La figura 7 ilustra una realización de un método de solicitud de desconexión implementado dentro de la capa de sesión.

La figura 8 ilustra un diagrama de flujo de capas que muestra el flujo de datos dentro de las diversas capas implementadas en al menos una realización de la invención.

La figura 9 ilustra un diagrama de actividad que muestra el enrutamiento entre varios dispositivos.

Las figuras 10A-D ilustran la estructura de los mensajes de la capa de sesión.

Las figuras 11A-B ilustran la estructura de los mensajes de la capa de transporte.

Las figuras 12A-B ilustran la estructura de los mensajes de la capa de enlace de datos/física.

Las figuras 13A-B ilustran una transferencia de mensaje de ejemplo de una función médica utilizando valores de ejemplo dentro de los mensajes para demostrar el sistema y el método según al menos una realización de la invención.

Descripción detallada de la invención

A continuación se describirá un método de comunicación de dispositivos médicos. En la siguiente descripción ejemplar se exponen numerosos detalles específicos para proporcionar una comprensión más completa de las realizaciones de la invención. Será evidente, sin embargo, para un experto en la materia que la presente invención se puede poner en práctica sin incorporar todos los aspectos de los detalles específicos descritos en este documento. En otros casos, las características, cantidades o medidas específicas bien conocidas por los expertos en la técnica no se han descrito en detalle para no oscurecer la invención. Los lectores deben tener en cuenta que, aunque en este documento se exponen ejemplos de la invención, las reivindicaciones son las que definen las medidas y los límites de la invención.

La figura 1 ilustra una vista arquitectónica de un sistema que tiene un controlador de interfaz de usuario o "UIC" y múltiples periféricos que se comunican entre sí usando una realización de la invención. Tal como se muestra, un controlador de interfaz de usuario UIC comunica con los periféricos control de motor de bomba o "PMC", PMC 1 y PMC 2, así como con el motor de comunicación o "CE" para diversas aplicaciones, incluyendo, entre otros, la biblioteca de medicamentos, el estado y el tratamiento de mensajes de diagnóstico. A modo de ejemplo, UIC tiene un ID de dispositivo/destino, por ejemplo, una dirección de 5 y los mensajes de UIC a los otros dispositivos viajan a través de rutas definidas de forma única por las tuplas definidas en la tabla, por ejemplo, en un canal definido por ID de comunicación y dispositivo. Estos canales se muestran en la tabla anterior UIC, es decir, entre UIC y PMC 1, en los puertos 10 y 20, es decir, los puertos terapéuticos y de estado, a través del ID de comunicación o "CID" 100 y CID 250 respectivamente, seguidos de un canal utilizado entre UIC y PMC 2 en el puerto 10, el puerto terapéutico, a través del ID de comunicación 100, junto con un canal entre UIC y CE en el puerto 40, a través del ID de comunicación 175. El CE, cuya dirección es 7, muestra los canales en la tabla anterior CE a PMC 2 y el UIC, es decir, los dispositivos 2 y 5 a través de los ID de comunicación 250 y 175, respectivamente. Se ilustra que el PMC 1 tiene canales hacia el UIC, a través de los ID de comunicación 100 y 250. El PMC 2 se ilustra con canales hacia el UIC y el CE a través de los puertos 10 y 20, a través de los ID de comunicación 100 y 250. El PMC 3 y 4 se pueden intercambiar en caliente en el sistema o de otro modo ordenado o consultado sobre la marcha. Las realizaciones de la invención están configuradas, en general, para utilizar memoria y procesamiento mínimos para permitir la ejecución en dispositivos que tienen memoria limitada y potencia de procesamiento limitada, lo que generalmente se desconoce en la técnica con respecto a los protocolos de comunicaciones sofisticados, por ejemplo. En una o más realizaciones, la pila utiliza un hilo del núcleo para ejecutar la capa de enlace de datos y la capa inferior de transporte, mientras que las capas restantes son parte del proceso de aplicación y se ejecutan en el contexto de la aplicación. La implementación mínima de hilos soporta bloqueo de acceso, por ejemplo, las operaciones de lectura y escritura se bloquean hasta que se completa la operación. Las realizaciones también pueden soportar devoluciones de llamadas asíncronas y, en tales casos, la pila puede utilizar dos hilos, uno para operaciones de escritura y otro para operaciones de lectura, por lo que el número total de hilos utilizados es 2*N 1, donde N es el número de aplicaciones que utilizan la pila.

La figura 2 ilustra una realización en capas jerárquicas de la invención implementada como una pila de protocolos. Tal como se muestra, un mensaje de datos en la capa de aplicación tiene una longitud de N bytes. La capa de aplicación puede incluir cualquier funcionalidad independiente de la pila de protocolos que se implementa en las capas por debajo de la capa de aplicación, tal como se muestra. Cuando el mensaje se transmite de una aplicación a otra, por ejemplo, a una aplicación que se ejecuta en un periférico o subsistema, la información de control o las cabeceras se agregan al mensaje a medida que el mensaje desciende por capas. Las diversas cabeceras u otra información añadida se eliminan a medida que el mensaje sube a través de la pila de protocolos hasta la aplicación receptora respectiva.

En una o más realizaciones, se puede utilizar una capa de administrador para implementar la primera capa en la pila de protocolos bajo de la aplicación. La capa de administrador puede proporcionar interfaces estándar para aplicaciones en cualquier sistema operativo deseado. La capa proporciona interfaces de programador de aplicaciones o API que permiten comunicaciones basadas en sockets entre aplicaciones. La capa de administrador también administra descriptores de archivo y facilita la apertura de puertos. En al menos una realización, la capa de administrador crea y si no utiliza una cabecera de mensaje que tiene un número de puerto y un descriptor de archivo.

Una capa de sesión es otra capa en la pila de protocolos y proporciona o incluye API para intercambiar datos y controlar entre la capa de administrador y la capa de sesión. La capa de sesión puede proporcionar una entrega de datos de aplicación a aplicación garantizada y permite modos de comunicación orientados a conexión y sin conexión. Esta capa también permite un modo de comunicación de difusión y multidifusión uno a uno, uno a muchos, muchos a uno. La capa mantiene la traducción entre CID y un socket o puerto virtual asociado. Para la comunicación orientada a conexión, el protocolo utiliza el CID y, de lo contrario, genera y utiliza los CID. Como el intercambio de datos orientado a conexión utiliza un establecimiento de comunicación entre aplicaciones para intercambio de datos, la capa de sesión gestiona el establecimiento de comunicación y genera un CID para la comunicación e informa a las otras capas de sesión participantes de la aplicación o aplicaciones sobre el CID. Después del establecimiento de comunicación, los paquetes de datos utilizan el CID para la comunicación. En el caso de comunicación sin conexión, no se utiliza CID y, por lo tanto, las direcciones de los puertos de origen y de destino se intercambian en cada paquete de comunicación o carga útil. En al menos una realización, la capa de administrador crea y utiliza una cabecera de mensaje que tiene indicadores de control y un tipo de mensaje junto con un identificador de comunicación. Esta estructura junto con una tabla de conexión ejemplar se muestra en la figura 10A, junto con tipos de mensajes ejemplares en las figuras 10B-D. Los indicadores de control pueden implementarse con un indicador de capa de 1 bit, un tipo de conexión de 2 bits y una fuente CID de 1 bit, por ejemplo. La capa de sesión utiliza algunos mensajes que están asociados con las comunicaciones sesión-sesión y nunca se pasan por la pila a la capa de administrador en una o más realizaciones. Estos mensajes generalmente se usan para establecer o cerrar conexiones, acuses de recibo, etc. Si el indicador de capa está activado, por ejemplo, ajustado a verdadero o 1, el mensaje se consumirá en la capa de sesión y no se reenviará a la pila. El indicador de tipo de conexión indica el tipo de conexión, por ejemplo, si está orientado a conexión, ajustado a 01 o si no es sin conexión ajustado a 00. Un ejemplo de protocolo sin conexión es el protocolo de datagramas de usuario o UDP, mientras que un ejemplo de protocolo orientado a conexión es el protocolo de control de transmisión o TCP. El bit de origen de CID se utiliza para identificar si los datos se envían desde la entidad que generó el CID para la conexión en uso o desde submódulos que utilizan este CID para comunicación. La entidad que genera el CID para comunicación establece este bit para todos los mensajes generados por esta para la conexión activa respectiva, mientras que otras entidades involucradas en la comunicación restablecen este indicador para los mensajes mientras usan este CID. Como el CID es único dentro de la entidad que genera el CID, puede haber CID duplicados en otras entidades. Por lo tanto, esta capa ayuda a resolver la fuente de CID (local o remota) a través de este indicador. El campo de tipo de mensaje asocia mensajes con categorías y permite que la capa de sesión sepa qué esperar en los siguientes campos. El campo de tipo de mensaje es un campo de 4 bits de ancho en una o más realizaciones. El campo de tipo de mensaje se utiliza para determinar el tipo de mensaje. Los valores ejemplares incluyen 0000 para datos, 0001 para conexión, 0010 para CID, 0011 para socket, 0100 para servicio y 0101 para información del dispositivo. Cualquier módulo que proporcione un servicio genera un CID único para comunicar con los consumidores del servicio. El I^dde comunicación '0' está reservado para el tipo de comunicación sin conexión en una o más realizaciones. El campo de ID de comunicación tiene 1 byte de ancho y se utiliza para los datos que se pasan a la pila de protocolos. CID puede contener cualquier número entre 0-255. Tal como se indicó anteriormente, CID '0' es para comunicación de tipo sin conexión y, por lo tanto, no es un ID válido para comunicación orientada a conexión. Las comunicaciones de tipo orientadas a conexión tendrán un CID en el intervalo de 1-255. Por lo tanto, CID '0' es una indicación implícita de comunicación sin conexión, cualquier otro número entre 1-255 sugiere orientado a conexión. Las aplicaciones pueden establecer uno o más filtros de notificación para seleccionar el mensaje a recibir y procesar utilizando una función deseada. El mecanismo de filtrado puede utilizar una o más expresiones regulares que especifican la ubicación, la longitud y el contenido de los datos correspondientes en la porción de datos del paquete. Esta funcionalidad se implementa en la capa de gestión en una realización de la invención. Antes de que la capa de gestión envíe los datos a la aplicación, puede comprobar si se han definido filtros en los datos. Según el filtro, la capa de administrador filtra los datos y los reenvía a los respectivos manejadores de devolución de llamada.

Las realizaciones de la invención permiten que una sola aplicación mantenga conexiones con más de un dispositivo sobre una o más capas de comunicación física o implementaciones de bus. Esto se logra mediante el uso de puertos virtuales. Una sola aplicación, tal como el Administrador Terapéutico (“Therapeutic Manager”) en el UIC puede, por ejemplo, mantener conexiones abiertas con más de un PMC de bomba de medicamentos u otro dispositivo, tal como sucedería durante una infusión multicanal. De manera similar, muchas aplicaciones pueden mantener una conexión con una aplicación o dispositivo, por ejemplo, UIC, CE y otras aplicaciones pueden conectarse a un PMC en particular para recopilar información sobre el estado de la infusión.

La relación de comunicación de uno a muchos y/o de muchos a uno se puede clasificar además en tres tipos, unidifusión, multidifusión y difusión. Por ejemplo, diferentes aplicaciones pueden recopilar el estado de infusión de un PMC mediante solicitud, por ejemplo, mediante multidifusión, o el PMC puede difundir su estado en un puerto conocido y las aplicaciones interesadas pueden escuchar el puerto. Escuchar un puerto conocido puede ser anónimo o estar basado en suscripción. En modo anónimo, la aplicación de difusión transmite continuamente en un puerto conocido y cualquier aplicación puede escuchar el puerto. En el modo basado en suscripción, la aplicación de difusión no transmitirá hasta que haya al menos un destinatario, la aplicación interesada, que tendrá que solicitar el servicio y desconectarse cuando termine de usar el servicio.

Los puertos virtuales se pueden implementar habilitando un establecimiento de comunicación entre los módulos/aplicaciones participantes. Las aplicaciones que proporcionan el servicio generalmente abren un puerto y se conectan al puerto. Para cada solicitud de conexión aceptada, el proveedor de servicios genera un CID y lo devuelve a la entidad solicitante en un acuse de recibo. La comunicación posterior se realiza utilizando este CID. En general, el CID es único para la entidad que lo generó. Se usa un mensaje de desconexión para detener la comunicación y a continuación el CID se devuelve al fondo, por ejemplo, para reutilizarlo más tarde. Si el proveedor de servicios se queda sin CID, puede devolver un NAK a las solicitudes de conexión entrantes con el ID de NAK adecuado. En caso de fallo de comunicación, por ejemplo, apagado del módulo, demasiado tiempo de espera, demasiados reintentos, etc., después de esperar suficientes reintentos para enviar un mensaje, una o más realizaciones pueden asumir que la comunicación se ha detenido y a continuación se devuelve CID al fondo. Como los CID son generados por el proveedor de servicios y son únicos dentro de la entidad, puede haber CID duplicados en otras subentidades. Para evitar el conflicto debido a CID duplicados, se pueden mantener dos tablas de CID, una para el CID generado por el sistema y la otra para los CID generados por otros sistemas involucrados en la comunicación. El creador de CID establece el indicador "fuente de CID", por lo que cuando otras aplicaciones involucradas consultan este indicador, realizan una búsqueda en la tabla CID adecuada. Cada entidad puede, por tanto, mantener una tabla compartida por las aplicaciones que se ejecutan en la misma. Esta tabla se mantiene en la capa de sesión y sirve como tabla de referencia para enrutar los paquetes de datos entrantes a los respectivos puertos/sockets.

Un escenario de ejemplo se ilustra en la siguiente tabla, y también se muestra en la parte inferior de la figura 10A con fines ilustrativos y no pretende limitar la invención reivindicada. Tal como se muestra, el tipo de conexión se puede ajustar a un valor indicativo de un tipo de comunicación orientada a conexión, como TCP, tal como se muestra, o un tipo de comunicación sin conexión, como UDP, tal como se muestra, o un "servicio", por ejemplo, una aplicación que existe para registrar datos para otras aplicaciones. La dirección de destino, el puerto de destino y el ID de comunicación generalmente identifican de forma única una fila en la tabla mencionada anteriormente. La dirección de destino es la dirección lógica de un dispositivo involucrado en una comunicación. Las realizaciones pueden soportar entradas repetidas con la misma dirección de destino, lo que indica múltiples conexiones activas con el mismo dispositivo de destino. El campo de puerto de origen almacena el número de puerto local responsable de manejar la(s) comunicación/comunicaciones con el CID asociado a las mismas. En función del CID, los mensajes recibidos se enrutan al puerto respectivo. Varias entradas repetidas en la columna del puerto de origen sugieren que varias aplicaciones comunican a través del mismo puerto, lo que puede ser indicativo de una comunicación de uno a muchos, por ejemplo. En una o más realizaciones, las aplicaciones pueden registrar o proporcionar de otro modo una solicitud a un proveedor de servicios para recibir mensajes. El puerto de destino es el número de puerto en el dispositivo de destino involucrado en una comunicación. La comunicación entre un puerto de destino y el puerto local asociado al mismo tiene lugar a sobre el CID respectivo. Por lo tanto, el CID se comporta como una clave para esta comunicación. Dado que el CID es un número único asignado a distintas solicitudes de comunicación, y que puede implementarse con un tipo de datos particular de cierto tamaño, puede haber un límite superior al número de conexiones activas que puede manejar el sistema/la aplicación. El límite superior es, por lo tanto, un límite numérico superior del CID. Una vez que el cómputo de CID únicos excede el límite superior, una o más realizaciones envían un NAK a nuevas solicitudes de conexión entrantes. El descriptor de archivo (FD) funciona de manera similar al manejador de archivo o al descriptor de archivo en los sistemas operativos estándar, como reconocerá un experto en la materia. Las operaciones relacionadas con la comunicación se realizan utilizando este descriptor. La repetición de entradas de FD sugiere que múltiples conexiones están siendo servidas por una comunicación de aplicación, de tipo muchos a uno. Véanse también las figuras 10B-D para las estructuras de mensaje específicas utilizadas en una o más realizaciones de la invención.

La capa de transporte es otra capa en la pila de protocolos y es responsable de la entrega de datos de capa de transporte a capa de transporte. Esta capa maneja el control de flujo, los tiempos de espera, los acuses de recibo y la fragmentación y reensamblaje de datos y también resuelve la prioridad de los datos. Al menos una realización de la pila de protocolos soporta dos o más niveles de prioridad, por ejemplo, tres niveles de prioridad, prioridad alta, prioridad media y prioridad baja y, dependiendo de la prioridad de los datos, la capa de transporte coloca los datos en una cola de prioridad respectiva. La capa de transporte puede implementarse con dos subcapas, a saber, las capas superior e inferior de transporte. La capa superior de transporte, junto con las capas de administrador y de sesión, reside en el espacio de la aplicación, mientras que la capa inferior de transporte, junto con la capa de enlace de datos, reside en el espacio del núcleo. La capa superior de transporte maneja la lectura y escritura en colas de prioridad, la fragmentación y el reensamblaje de datos y los acuses de recibo de capa de transporte a transporte, mientras que la capa inferior de transporte puede implementarse como una capa muy delgada y maneja la lectura de colas de prioridad y la comunicación con otra u otras capas de pila, por ejemplo, una capa de pila inferior. Esta estructura junto con un tipo de mensaje de ejemplo en las figuras 11A-B.

La capa de transporte generalmente asegura que los datagramas de tamaño manejable se envíen a través del bus subyacente. Por lo tanto, esta capa analiza los datos que proceden de las capas superiores y si el tamaño de los datos supera el tamaño de la unidad máxima de transmisión (MTU), la capa fragmenta los datos entrantes para que quepan dentro de los límites de la MTU. Por lo tanto, las realizaciones de la invención pueden utilizar cualquier tipo de bus de cualquier tamaño, por ejemplo, un bit para un bus en serie, o múltiples bits para un bus en paralelo de cualquier anchura. La capa añade información adecuada a los datos para que se puedan volver a ensamblar fielmente en el extremo receptor. Si los datos entrantes se pueden enviar en tres fragmentos, el campo 'ID de fragmento' se usa para numerar los fragmentos a partir de '1' y el bit 'indicador extendido' no se usa. Todos los ceros en el campo 'ID de fragmento' indican un mensaje no fragmentado y, por lo tanto, se trata como un mensaje independiente. Si un mensaje requiere que se transmitan más de tres fragmentos, se establece 'indicador extendido', lo que permite usar 8 bits adicionales (el campo ID de fragmento extendido es de 8 bits) para numerar los fragmentos. Con este indicador activado, hay un total de 10 bits disponibles para la numeración que pueden soportar 1023 (2A10 - 1) fragmentos. En el extremo receptor, se inspecciona el 'indicador extendido' para determinar si se usa o no el 'ID de fragmento extendido'. Si el indicador está activado, el receptor asume que los fragmentos llegan en secuencia, comenzando desde el número de secuencia 1. Pero, si el indicador no está activado, el receptor inspecciona el campo ID de fragmento'. Si el campo 'ID de fragmento' tiene cero, esto indica un mensaje independiente, pero si es un valor distinto de cero, el receptor trata el mensaje recibido como datos fragmentados (espera un máximo de tres paquetes). Una vez se reciben todos los fragmentos, el receptor volverá a ensamblar todos los fragmentos en un solo mensaje. Para ello, el receptor alinea todos los mensajes recibidos en orden ascendente de su ID de fragmento. A continuación, el receptor verifica que no se haya perdido ningún fragmento en la secuencia. Si todos los fragmentos se reciben correctamente, el receptor elimina la información de la cabecera de la "capa de transporte" de todos los fragmentos relacionados y los concatena en un solo mensaje. Si la capa de transporte tiene memoria limitada para volver a ensamblar todos los fragmentos, reenvía los fragmentos a la pila, a medida que llegan, que se vuelve a ensamblar en la memoria intermedia de aplicación.

El control de congestión es proporcionado asimismo por la capa de transporte, que puede implementar mensajes dedicados específicamente por la capa de transporte a la capa de comunicación. Estos mensajes específicos se consumen en la capa de transporte y no se pasan a la pila. Uno de estos mensajes es el mensaje de ventana, que se intercambia para determinar el tamaño de la ventana para el intercambio de datos.

Antes de enviar el primer fragmento de los datos fragmentados, el transmisor solicita un tamaño de ventana del receptor. El receptor observa el espacio de memoria intermedia disponible en la memoria intermedia de aplicación y calcula la cantidad de fragmentos que puede organizar antes de quedarse sin memoria disponible. Este responde a la solicitud de los transmisores con este número calculado, como tamaño de ventana. A continuación, el transmisor envía fragmentos del tamaño de una ventana antes de esperar un acuse de recibo. Una vez que el receptor recibe todos los mensajes transmitidos en una ventana, verifica que todos los fragmentos estén en la secuencia deseada y envía un acuse de recibo por el último fragmento recibido en la secuencia. Si el receptor determina que faltan uno(s) fragmento(s), envía un NAK para el fragmento faltante y el transmisor retransmite el/los fragmento(s) respectivo(s). El transmisor puede verificar el tamaño de la ventana en medio de la comunicación para mantener optimizado el intercambio de datos; además, si al receptor le quedan pocos recursos, puede enviar explícitamente una respuesta de ventana y actualizar el transmisor acerca del tamaño de la ventana.

La capa de transporte también es responsable de la entrega fiable de datos. La capa de transporte tiene la capacidad de garantizar la entrega de datos al extremo receptor. La capa de transporte tiene un campo para acuse de recibo. El receptor puede enviar un acuse de recibo para cada paquete de datos recibido con el indicador de acuse de recibo activado. En el caso de mensajes fragmentados, se envía un acuse de recibo cuando se ha recibido el último fragmento en una ventana o se ha recibido la última trama en el mensaje, o el temporizador expira antes de que se hayan recibido todos los mensajes.

Las realizaciones de la capa de transporte también pueden implementar un "tiempo de vida". Por ejemplo, después de transmitir un mensaje, el transmisor inicia un temporizador y espera un acuse de recibo. Si se recibe un acuse de recibo, el temporizador se restablece y se transmiten los siguientes paquetes. Pero si no se recibe un acuse de recibo, la capa de transporte vuelve a transmitir el mensaje y nuevamente espera un acuse de recibo. El transmisor volverá a intentar enviar el mensaje un cierto número de veces y, si no obtiene un acuse de recibo, asumirá que el receptor no está disponible e informará a las capas superiores. En caso de fragmentación, el transmisor envía mensajes del tamaño de una ventana y a continuación espera un acuse de recibo del último fragmento enviado. Si el temporizador expira, el transmisor reenviará de nuevo los mensajes.

La capa de transporte también puede implementar detección y recuperación de fallos. Por ejemplo, la capa de transporte en el receptor puede solicitar al transmisor que retransmita tramas seleccionadas a través de mensajes de capa a capa.

La capa de transporte también puede implementar prioridad para los mensajes. Por ejemplo, las capas superiores pueden pasar la prioridad del mensaje a esta capa y esta capa añade la prioridad a la cabecera del mensaje. La cabecera tiene campos de dos bits para la prioridad del mensaje y, por lo tanto, hay cuatro niveles de prioridad posibles en una o más realizaciones, aunque se puede usar cualquier número de bits para la prioridad para implementar más niveles, y esto aplica a todas las particiones de mensajes y números de bits descritos en este documento. Cada nivel de prioridad tiene su propia cola y, según la prioridad del mensaje, la capa de transporte los coloca en las respectivas colas para que sean procesador por otras capas. Como hay cuatro niveles de prioridad en una realización de 2 bits, puede haber un máximo de cuatro colas de prioridad y un mínimo de una cola, pero el número de colas de prioridad depende del número de niveles de prioridad utilizados.

La capa de enlace de datos es otra capa, a modo de ejemplo y no de limitación, la capa más baja, en la pila de comunicación y es responsable de la entrega de datos de subsistema a subsistema. Esta capa reside completamente en el espacio del núcleo. La capa de enlace de datos también se puede implementar con dos subcapas, por ejemplo, una capa de enlace y una capa de acceso a medios (MAC). La capa de enlace verifica la integridad de los datos calculando/verificando el CRC para cada trama de datos saliente/entrante y también maneja cualesquiera acuses de recibo de hardware, por ejemplo. La capa también maneja solicitudes de direcciones lógicas únicas y genera y asigna direcciones únicas. La capa MAC utiliza uno(s) controlador(es) que maneja(n) el/los bus(es) o los canales de comunicación físicos subyacentes. A medida que las tramas de datos llegan a los buses, la capa MAC copia los datos recibidos a un fondo de memoria y pasa el puntero a los datos copiados a la capa de enlace. Al menos una realización soporta comunicación sobre múltiples tecnologías de transferencia de datos subyacentes o implementaciones de hardware tales como serie, CAN, SPI, SDIO, USB o cualquier otro tipo de medio de comunicación o bus de datos. Esta estructura junto con un tipo de mensaje de ejemplo en las figuras 12A-B.

En una o más realizaciones, la capa de enlace de datos es responsable de la integridad de los datos, por ejemplo mediante el uso de verificación CRC o cualquier otro tipo de formato o codificación de integridad de datos deseado. Las realizaciones de la capa de enlace de datos también son responsables de la asignación de direcciones lógicas. Por ejemplo, esta capa es responsable de asignar y administrar las direcciones lógicas de los módulos en un dispositivo. Todos los módulos, como el controlador del motor de la bomba, el controlador de la fuente de alimentación, el motor de comunicación, el controlador de la interfaz de usuario, etc., tienen un ID único para que puedan identificarse de manera única en una bomba. La pila de protocolos puede soportar 254 módulos, dado que el campo de dirección es de 1 byte y las direcciones lógicas 00, 01 y FF son direcciones reservadas. Si los módulos se identifican según su dirección de hardware única (direcciones MAC), y dado que las direcciones de hardware tienen más de un byte de tamaño, esto añadiría una sobrecarga al protocolo. Para evitar esto, a cada módulo se puede asignar una dirección lógica entre 1 y 255 y a continuación esta capa mantiene las direcciones asignadas. La capa de aplicación no necesita saber cuál es la dirección del hardware o cuál es la dirección lógica en general, lo que simplifica las llamadas lógicas y de API.

A uno de los módulos generalmente se le asigna la tarea de generar direcciones lógicas únicas para otros módulos en el dispositivo, sin importar si esos módulos están conectados directamente a este módulo especial o no. Cuando el dispositivo se enciende, todos los módulos se encienden según lo programado. El módulo responsable de generar la dirección de los dispositivos se denomina dispositivo "raíz". El dispositivo raíz es consciente de su rol especial y se asigna a sí mismo una dirección lógica de 01. A medida que otros módulos se despiertan, asumen su dirección lógica como 00. Estos saben que 00 no es una dirección válida pero también saben que existe un módulo con dirección 01 que puede proporcionarles una dirección única.

Por lo tanto, estos módulos envían solicitudes de dirección a un destino con la dirección 01. Al recibir este mensaje, el módulo raíz verifica su tabla interna para verificar si el hardware solicitante ya tiene una dirección lógica asignada. Si se asigna una dirección lógica, el módulo raíz envía esa misma dirección lógica en respuesta; de lo contrario, genera una dirección lógica única, actualiza esta dirección en su tabla interna con la dirección MAC del solicitante y envía esta dirección en respuesta. Al recibir una respuesta de dirección, el módulo solicitante comienza a comunicar con esta dirección lógica.

Un módulo en una o más realizaciones puede no comunicar sin una dirección lógica válida. Si varios módulos intentan solicitar una dirección lógica, habrá colisiones. Debido a las colisiones, ninguna solicitud llega nunca al módulo raíz y, por lo tanto, ninguno de los módulos recibe una dirección lógica. En este escenario, otros módulos volverán a intentarlo después de un período de tiempo aleatorio. Dependiendo de la criticidad del dispositivo, la cantidad de tiempo aleatorio puede variar, es decir, los dispositivos críticos pueden esperar un período de tiempo menor antes de volver a intentarlo. La cantidad de tiempo de espera puede ser parte de la configuración y los dispositivos pueden esperar haciendo referencia a su reloj interno, por ejemplo.

Si un dispositivo no desea utilizar el mecanismo de direccionamiento dinámico, cada módulo puede programarse con una dirección única, por ejemplo, para implementar un esquema de asignación de direcciones estáticas versus dinámicas. Las realizaciones pueden seguir utilizando un módulo raíz que mantiene las direcciones de los módulos conectados.

Las realizaciones de la capa de enlace de datos también pueden implementar enrutamiento. Tal como se ha mencionado, un módulo puede tener múltiples tipos de bus o topologías y puede haber diferentes tipos de dispositivos conectados en varios buses. Si una capa de enlace de datos recibe un paquete que no está dirigido a la misma, primero verifica si tiene varias arquitecturas de bus y, si es cierto, reenvía el mensaje a otros buses; de lo contrario, simplemente descarta el paquete. Este tipo de mecanismo de direccionamiento es muy adecuado para la topología en estrella, por ejemplo. Por lo tanto, si PMC1 quiere enviar datos a PMC2 pero no hay una ruta de datos directa, entonces los redirigirá a través del módulo raíz. En este caso, el módulo raíz puede difundir el mensaje en la red o realizar una búsqueda en su tabla interna y simplemente reenviar el paquete en una línea específica. Por lo tanto, en una o más realizaciones que implementan enrutamiento, cada módulo que soporta múltiples buses de comunicación puede mantener una lista de todos los dispositivos conectados directamente al módulo para que puedan enrutar los paquetes de manera eficiente. Como la pila soporta el enrutamiento de datos, une sin problemas varios buses de datos heterogéneos, lo que hace que la comunicación y la topología del bus sean independientes. Algunos ejemplos de posibles topologías de bus incluyen topologías de anillo, estrella, malla y árbol o cualquier otra topología que pueda utilizarse para transferir datos.

La figura 3 ilustra una realización de un método de solicitud de dirección implementado dentro de la capa de administrador. Tal como se muestra, cuando se añade un dispositivo al sistema, por ejemplo, se intercambia en caliente, el dispositivo se inicia y solicita una dirección del dispositivo raíz. El nuevo dispositivo espera una respuesta y, si se agota el tiempo de espera, vuelve a solicitar una dirección. Una vez que el dispositivo raíz recibe el mensaje de solicitud de dirección, busca un número de dispositivo disponible y genera una dirección lógica para el nuevo dispositivo y actualiza la tabla. Alternativamente, si no quedan números disponibles, se puede devolver un NAK con el mensaje de error apropiado al nuevo dispositivo. El dispositivo raíz devuelve la dirección lógica del nuevo dispositivo al nuevo dispositivo en un mensaje de respuesta de dirección. Cualesquiera solicitudes adicionales de la dirección se gestionan mediante búsqueda a través del dispositivo raíz. El nuevo dispositivo almacena la dirección lógica en una tabla local para su uso posterior. Esta capacidad generalmente no existe en dispositivos médicos o bombas de infusión, dado que generalmente se supone que las configuraciones son fijas, utilizando un sistema operativo fijo y un bus fijo sin tener en cuenta potenciales nuevos dispositivos y nuevos tipos de dispositivos que puedan comunicar con un dispositivo raíz.

La figura 4 ilustra una realización de una secuencia de infusión simple que utiliza varios mensajes proporcionados por realizaciones del método. Una vez que se obtiene la dirección de un nuevo dispositivo, este puede comunicar con los otros componentes dentro del sistema. La figura muestra el controlador de interfaz de usuario UIC que tiene el número de dispositivo 1, inicialmente conectado a una bomba de infusión de medicamentos que tiene el número de dispositivo 3, donde las direcciones lógicas de los dispositivos o los números de dispositivo se obtienen tal como se muestra en la figura 3. El UIC acepta la entrada de un cuidador que indica que se va a realizar una infusión. La aplicación UIC calcula los pasos necesarios para lograr la infusión y envía una cabecera de infusión y un mensaje de datos a la bomba de infusión de medicamentos, que acusa recibo del mensaje. A continuación, el UIC envía un mensaje de datos de seguridad de la infusión, que se acusa y, una vez completada la infusión, el UIC envía un mensaje de datos de parada de la infusión, que se acusa. Este escenario es un escenario típico que permite añadir cualquier tipo de bomba de infusión de medicamentos a un sistema y utilizarla, por ejemplo, en un escenario de intercambio en caliente donde una bomba de infusión puede devolver un error, o se va a añadir al sistema, y a utilizar un tipo diferente de bomba de infusión de medicamentos, por ejemplo.

La figura 5 ilustra una realización de un método de conexión implementado dentro de la capa de sesión. En el escenario mostrado, el UIC solicita una conexión para comunicarse con el PMC para dirigir el PMC y/o por ejemplo obtener actualizaciones de estado. En este caso, el PMC actúa como un proveedor de servicios dado que el PMC proporciona actualizaciones de estado en un puerto conocido. El UIC envía una solicitud de conexión al PMC en ese puerto, por ejemplo, el puerto 10, que se muestra como un mensaje que pasa de izquierda a derecha. Después de recibir la solicitud de conexión, el PMC acepta la solicitud, genera un CID único, por ejemplo, 26 para esta comunicación y actualiza su tabla interna. El PMC envía el CID generado de retorno al UIC como parte del mensaje de aceptación de conexión, que se muestra viajando de derecha a izquierda. Al recibir el mensaje de aceptación de conexión del PMC, el UIC extrae el CID del mensaje y actualiza su tabla CID interna tal como se muestra en la parte inferior izquierda. A continuación, el UIC envía un mensaje de acuse de recibo al PMC para confirmar la recepción satisfactoria de CID. Si el PMC no puede procesar la solicitud de UIC y, por lo tanto, no puede establecer comunicación, el PMC envía un mensaje de rechazo de conexión al UIC. Al recibir el mensaje de rechazo de conexión, el UIC puede volver a intentar obtener una conexión. Véanse también las figuras 10A-D, 11A-B y 12A-B para ver una realización de las estructuras de mensajes de ejemplo que se pueden utilizar para formar una implementación de varias capas, que se describen con más detalle a continuación.

La figura 6 ilustra una realización de un método de intercambio de datos implementado dentro de la capa de sesión. Una vez que el PMC recibe el acuse de recibo del UIC, el proceso de conexión se completa. En este momento, ambos dispositivos pueden intercambiar datos utilizando el CID acordado. Cuando la capa de sesión de PMC recibe cualesquiera datos del UIC con un CID válido, realiza una búsqueda en su tabla interna contra el 'ID de destino' y el 'CID' para resolver el número de puerto donde se reenviará el paquete.

La figura 7 ilustra una realización de un método de solicitud de desconexión implementado dentro de la capa de sesión. Una vez completada la transmisión de datos, cualquiera de las partes comunicantes puede solicitar la finalización de la conexión. Tal como se muestra, el UIC inicia el proceso de finalización de la conexión. Este envía una solicitud de desconexión a PMC con el CID respectivo. El PMC procesa la solicitud y, si no hay comunicación activa, el PMC enviará un acuse de recibo al UIC y eliminará la entrada del CID de su tabla. Al recibir el acuse de recibo de desconexión de PMC, el UIC también elimina las entradas de CID de su tabla.

Aunque el protocolo general de comunicación de la capa de sesión se ha descrito anteriormente, sigue una descripción más detallada de los mensajes de la capa de sesión, según una o más realizaciones de la invención. Las estructuras de mensaje utilizadas en una o más realizaciones de la invención, como se describe a continuación, se muestran en las figuras 10B-D.

Mensaje de solicitud de conexión

Para una sesión de comunicación orientada a conexión, cuando una aplicación abre un socket para comunicar a través de un puerto en algún otro dispositivo, se realiza un establecimiento de comunicación antes de que comience la comunicación. El establecimiento de comunicación comienza con un mensaje de tipo solicitud de conexión al proveedor de servicios. El "indicador de capa" se activa para este tipo de mensaje. Por lo tanto, el paquete de solicitud es consumido por la capa de sesión. El tipo de conexión puede configurarse inicialmente como "desconocido", lo que sugiere que el paquete de datos no es orientado a conexión ni sin conexión. El tipo de mensaje se ajusta a "Conexión" ya que el comando se utiliza para establecer una nueva conexión. El mensaje es una solicitud para establecer una nueva conexión; por lo tanto, el campo "Comando" contiene "Solicitud de conexión". La aplicación que solicita una conexión especifica la dirección de puerto del destino y también proporciona su propia dirección de puerto, por lo tanto, el paquete de solicitud de conexión tiene una dirección de puerto de origen y una de destino.

Mensaje de aceptación de conexión

Al recibir un mensaje de solicitud de conexión, si el proveedor de servicios tiene suficientes recursos, responde con un tipo de mensaje de aceptación de conexión. El proveedor de servicios genera un CID para la comunicación y lo envía al solicitante como parte de este mensaje. Como la entidad que solicita la conexión no tiene información del CID generado, el proveedor de servicios envía la dirección de los puertos de origen y de destino como parte de este mensaje para informar al otro extremo sobre el CID generado.

Mensaje de acuse de recibo de conexión

Al recibir un mensaje de aceptación de conexión, el extremo solicitante actualiza su tabla interna con el CID recibido. En respuesta al mensaje de aceptación de conexión, el extremo solicitante envía un mensaje de acuse de recibo para indicar al proveedor de servicios la recepción de CID y completar el establecimiento de comunicación. Es posible que múltiples aplicaciones en un módulo soliciten comunicar con una aplicación en otro módulo en el mismo número de puerto, por ejemplo, muchos a uno. Para informar al proveedor de servicios sobre la aplicación particular que está enviando un acuse de recibo, se añade "puerto de origen" al mensaje de acuse de recibo.

Mensaje de desconectar conexión

Una vez completada la comunicación, cualquiera de las entidades participantes podrá solicitar la desconexión de la conexión para una finalización ordenada de la misma.

Mensaje de acuse de recibo de desconexión de conexión

Este mensaje se envía como acuse de recibo al recibir un mensaje de desconexión. El mensaje está destinado a garantizar que una comunicación no finalice si todavía existe una conexión activa. Si no se recibe un acuse de recibo de desconexión dentro de un cierto período de tiempo, se puede realizar un nuevo intento de desconexión. Mensaje de rechazo de conexión

Si el proveedor de servicios no puede aceptar nuevas conexiones, envía un rechazo de conexión en respuesta a un mensaje de solicitud de conexión. En el mensaje de rechazo de conexión, envía el motivo del rechazo de la solicitud. Al recibir un mensaje de rechazo de conexión, el solicitante puede volver a intentarlo después de algún tiempo, por ejemplo.

Mensaje de solicitud de información de CID

Cualquier participante involucrado en la comunicación puede solicitar el estado de CID. Este mensaje actúa como un mensaje de ping para verificar si el puerto de destino está abierto y si el CID es un CID activo.

Mensaje de respuesta de información de CID

Al recibir una solicitud de información de CID, se transmite una respuesta de información de CID. Este mensaje contiene las direcciones de los puertos de origen y de destino involucradas en la comunicación, el tamaño de la ventana para la transmisión, etc., y también indica si el CID está activo o no.

Mensaje de solicitud de estado de socket

Este mensaje se utiliza para solicitar información relacionada con el socket, tal como el tipo de socket, el propósito de abrir este socket, etc.

Mensaje de respuesta de estado de socket

Este mensaje se envía en respuesta al mensaje de solicitud de estado de socket. El mensaje contiene información relacionada con el socket, tal como el tipo de socket, el propósito de abrir este socket, etc.

Mensaje de suscripción al servicio

El protocolo de comunicación permite que las aplicaciones proporcionen un servicio, por ejemplo un servicio de difusión. Por ejemplo, el PMC puede tener un servicio en ejecución que difunde periódicamente el estado del PMC en un puerto conocido. Si el UIC solicita el estado de PMC, simplemente puede suscribirse a este servicio con el PMC y recibir los mensajes. Por lo general, estos servicios son de comunicación unidireccional.

Mensaje de acuse de recibo de suscripción al servicio

Una vez que el proveedor de servicios recibe una solicitud de suscripción, tienen que proporcionar un CID al solicitante. El CID se entrega por medio de un mensaje de acuse de recibo.

Mensaje de cancelación de la suscripción al servicio

Si una aplicación suscrita ya no desea estar suscrita a un servicio, puede solicitar cancelar la suscripción. Al recibir un mensaje de cancelación de suscripción al servicio, el proveedor de servicios elimina las entradas de su tabla CID interna y envía un acuse de recibo al solicitante. Si el proveedor de servicios descubre que no hay nadie suscrito a un servicio, puede decidir detener el servicio de difusión hasta que tenga al menos una aplicación suscrita.

Mensaje de acuse de recibo de cancelación de la suscripción al servicio

Al recibir este mensaje, la aplicación que solicita la cancelación de la suscripción elimina las entradas de CID de su tabla interna y libera los sockets y puertos involucrados.

Mensaje de solicitud de dirección del dispositivo

Una aplicación puede solicitar una dirección lógica para un dispositivo utilizando este mensaje.

Mensaje de respuesta de dirección del dispositivo

Al recibir un mensaje de "Solicitud de dirección", un dispositivo envía su dirección como parte del mensaje de respuesta. Alternativamente, un mensaje de respuesta de dirección de dispositivo se puede enviar de forma independiente en cualquier momento y no necesariamente estar vinculado a un mensaje de solicitud.

Mensaje de solicitud de tipo de dispositivo

Este mensaje se utiliza para solicitar el nombre de un dispositivo. Cada dispositivo conectado tiene una dirección única, pero puede tener nombres no únicos o no tener nombres. Los tipos de dispositivos pueden ser PMC, CE, UIC, etc.

Respuesta del tipo de dispositivo

Este mensaje generalmente se envía en respuesta al mensaje de "Solicitud de tipo de dispositivo" y contiene el tipo de dispositivo que envía este mensaje. Alternativamente, un mensaje de respuesta de tipo de dispositivo se puede enviar de forma independiente en cualquier momento y no necesariamente estar vinculado a un mensaje de solicitud.

Mensaje de datos orientado a conexión

Al menos una realización de la capa de sesión añade solo dos bytes de información de cabecera cuando se envían datos entre dispositivos. El CID se genera e intercambia durante el proceso de establecimiento de comunicación previo a la transferencia de datos.

Mensaje de datos sin conexión

La transferencia de datos sin conexión se usa cuando no se requiere un establecimiento de comunicación para transferir datos. Como no hay establecimiento de comunicación, no se genera un CID para la comunicación y, por lo tanto, se utilizan los números de puerto de origen y de destino para garantizar la entrega de datos.

Las figuras 11A-B y 12A-B ilustran estructuras de mensajes correspondientes para realizaciones ejemplares de la capa de transporte y la capa de enlace de datos respectivamente, y se describen más adelante.

La figura 8 ilustra un diagrama de flujo de capas que muestra el flujo de datos dentro de las diversas capas implementadas en al menos una realización de la invención. Específicamente, se muestra el flujo de datos ascendente en la pila de protocolos para los datos entrantes. La ubicación de la memoria intermedia de aplicación de destino no se conoce hasta que la trama de datos sube a la capa de administrador. Por lo tanto, el fragmento se almacena en un fondo de memoria hasta que llega a la capa de administrador y, una vez que se resuelve la aplicación de destino, los datos se copian del fondo de memoria a la memoria intermedia de aplicación. En una o más realizaciones, la utilización de memoria puede minimizarse devolviendo una memoria intermedia a la memoria si la memoria intermedia está por encima de un umbral de antigüedad predefinido.

Capa de enlace de datos

La capa de enlace de datos controla uno o más enlaces físicos de comunicaciones, buses de datos. La capa filtra los mensajes dirigidos al dispositivo específico e ignora otros mensajes. La capa puede calcular un CRC en el paquete recibido y verificarlo con el CRC recibido. Las tramas de datos válidos se copian en un fondo de memoria y el puntero a estos mensajes se reenvía a la capa de transporte.

La capa inferior de transporte y la capa de enlace de datos se ejecutan como un servicio independiente y almacenan datos en la cola de prioridad designada, P1, P2, P3 o P4. La capa superior de transporte, y las capas de sesión y de administrador se ejecutan en el espacio de la aplicación, y la capa superior de transporte mantiene punteros a las colas de prioridad y las tablas de ID de comunicación. En una o más realizaciones, el fondo de memoria, las colas de prioridad y las tablas de CID están en el espacio de memoria compartida.

En una o más realizaciones, la capa de enlace de datos se divide además en dos subcapas, una capa de enlace y una capa MAC. La capa MAC puede interactuar con los controladores de bus y tiene una memoria intermedia para cada bus subyacente. A medida que los datos llegan a estos buses, los datos se copian en estas memorias intermedias y a continuación se envían a la capa de enlace. La memoria intermedia puede implementarse como un par de memorias intermedias, mientras que una memoria intermedia se usa para recibir nuevos datos, la otra memoria intermedia se usa para transferir datos recibidos previamente.

La capa de enlace copia los datos de las memorias intermedias en el fondo de memoria. El fondo de memoria es un bloque de memoria contiguo y cada bloque de memoria puede implementarse como un factor de longitud de trama. A medida que la aplicación consume datos, los datos se eliminan del fondo de memoria para dejar espacio para nuevos paquetes de datos. Como la aplicación consume datos aleatoriamente, puede haber huecos de memoria en el fondo de memoria. Por lo tanto, la capa de enlace generalmente mantiene una lista de ubicaciones de memoria disponibles en el fondo de memoria. Cuando se libera memoria del fondo de memoria, el puntero a la ubicación disponible se añade al final de esta lista. Cuando llega un nuevo paquete, se coloca en la memoria a la que apunta el primer elemento de esta lista. Si no hay ningún elemento en la lista, el fondo de memoria se considerará lleno y los paquetes se descartarán. En una o más realizaciones de la invención, se puede utilizar un administrador de memoria para controlar el acceso a la memoria desde las diversas capas, incluido el control de acceso simultáneo a la memoria desde las diversas capas. Las realizaciones de la invención pueden minimizar o evitar por completo múltiples operaciones de copia manteniendo una copia de datos en el fondo de memoria mientras se pasan punteros a la memoria a medida que los datos se mueven hacia arriba y hacia abajo en la pila. Al controlar el acceso a la memoria durante el acceso, se pueden utilizar semáforos para garantizar la integridad de los datos al tiempo que se permite que múltiples procesos utilicen eficazmente los datos de manera simultánea. Evitar múltiples operaciones de copia permite una utilización mínima de la memoria en entornos integrados y también minimiza la utilización del procesador.

Como el transmisor tiene tendencia a enviar datos a los buses, estos pueden rápidamente utilizar en exceso el bus transmitiendo demasiados datos. El controlador de bus en la capa MAC en una o más realizaciones puede implementarse para manejar tales escenarios.

Capa de transporte

En una o más realizaciones, la capa de transporte se puede dividir en dos subcapas, una capa superior de transporte y una capa inferior de transporte. La capa superior de transporte reside en el espacio de la aplicación, mientras que la capa inferior de transporte reside en el espacio del núcleo. Estas dos capas juntas manejan las funcionalidades de la capa de transporte.

La capa de transporte se implementa en una o más realizaciones para volver a ensamblar datos fragmentados y también para resolver la prioridad de los datos. Cuando la capa inferior de transporte recibe un nuevo paquete de datos, se puede iniciar un temporizador para los datos. Si los datos no se consumen antes de que expire el temporizador, los datos se pueden descartar y la memoria se puede liberar del fondo de memoria. Esto evita el agotamiento de la memoria si no existe ninguna aplicación para consumir los datos recibidos. Si se activó el campo de acuse de recibo, la capa de transporte envía un NAK, código de error "tiempo agotado en la cola de prioridad", por ejemplo.

La cabecera de la capa de transporte tiene un indicador de acuse de recibo y, si el indicador está activado, la capa de transporte receptora tendrá que enviar algún tipo de acuse de recibo para el fragmento de datos recibido. Si se reciben datos fragmentados, el acuse de recibo se envía después de recibir una cantidad de datos del tamaño de la ventana o un mensaje completo. Este indicador se activa para una transferencia de datos orientada a conexión, para garantizar la entrega de datos. Este indicador también se puede activar en una transferencia de datos sin conexión solo si se utiliza fragmentación de datos.

Tratamiento de paquetes de datos fragmentados

En el caso de datos fragmentados, antes de que el transmisor comience a enviar fragmentos de datos, la capa superior de transporte en el transmisor solicita primero un tamaño de ventana al receptor. El tamaño de la ventana se puede cambiar una vez durante la primera transferencia de datos o se puede obtener antes de cada transferencia de datos. El tamaño de la ventana es la cantidad de fragmentos de datos que se pueden enviar antes de que se espere un acuse de recibo. Cuando el receptor recibe una solicitud de tamaño de ventana, la capa superior de transporte en el extremo del receptor calcula la cantidad de memoria libre en la memoria intermedia de aplicación y envía la respuesta como tamaño de ventana en el mensaje de "respuesta de tamaño de ventana".

En una o más realizaciones, la capa superior de transporte en el lado del transmisor inicializa una estructura de datos para el CID que solicitó un tamaño de ventana. En esta estructura, la capa de transporte almacena el CID, el último tamaño de ventana notificado, el último número de fragmento recibido con éxito y el período de tiempo máximo permitido entre dos fragmentos, etc. Además, la capa superior de transporte en el receptor mantiene la misma estructura. La capa de transporte espera que los fragmentos se numeren secuencialmente a partir de 1 en una o más realizaciones.

A medida que el transmisor recibe un mensaje de ventana, calcula el número de fragmentos que se transmitirán antes de esperar un acuse de recibo. El transmisor comienza a enviar fragmentos de datos en secuencia a partir del fragmento número 1, por ejemplo.

Cuando el receptor recibe el primer fragmento, la capa inferior de transporte inicia un temporizador en la trama de datos recibida y coloca el fragmento en la cola de prioridad respectiva. La capa superior de transporte actualiza la estructura y almacena el número de secuencia del fragmento. Si las capas superiores entregan el fragmento a la memoria intermedia de aplicación, las capas superiores informan del éxito a la capa superior de transporte. La capa superior de transporte actualiza su estructura con el primer fragmento que se entrega. Las capas superiores no informan a la aplicación sobre el fragmento disponible hasta que se reciben todos los fragmentos que constituyen un mensaje. Se utiliza una memoria intermedia de aplicación para volver a ensamblar fragmentos para minimizar el consumo de memoria.

Si la capa superior de transporte recibe correctamente todos los fragmentos de una ventana, espera a que todos los fragmentos se entreguen correctamente a la memoria intermedia de aplicación. Una vez que todos los fragmentos se envían a la memoria intermedia de aplicación, el número de fragmento recibido y el número de fragmento entregado se corresponden y la capa superior de transporte envía un acuse de recibo para el último fragmento de la secuencia. El transmisor recibe el acuse de recibo en la capa superior de transporte.

Idealmente, la capa de transporte acumula todos los fragmentos, verifica que estén en secuencia y los fusiona en un mensaje completo antes de enviarlo a la pila. Sin embargo, en una o más realizaciones, la capa superior de transporte reenvía las tramas a la capa de sesión a medida que se reciben, pero asegura que los fragmentos se entreguen en secuencia. Esta implementación opcional se puede utilizar para reducir la utilización de la memoria. Este es el caso ya que el mensaje no tiene que ser reconstruido en su totalidad dentro de la pila hasta que se reciba el mensaje completo en la aplicación. Como el número de fragmento en la cabecera de transporte tiene 10 bits de anchura en una o más realizaciones, la capa puede soportar un máximo de 1023 fragmentos (el número de fragmento 0 está reservado y representa una trama de datos no de fragmento) antes de que se desborde la numeración de fragmentos. Como cada fragmento tiene una carga útil máxima de 248 Bytes, se requiere un total de 253.704 Bytes en el extremo del receptor para que cada conexión activa acomode todos los fragmentos. Se puede utilizar cualquier otro tamaño del campo de número de fragmentos para aumentar el tamaño total, tal como reconocerá un experto en la técnica.

En el receptor, a medida que se reciben fragmentos, la capa superior de transporte actualiza el último número de fragmento en su estructura. Antes de actualizar, verifica que el fragmento recibido esté en secuencia con el fragmento recibido anteriormente. Si detecta un fragmento faltante, la capa sigue reenviando los fragmentos a la pila, pero en su testigo respectivo pone un valor de compensación. Los metadatos junto con un puntero al fragmento de datos recibido se denominan un testigo. La capa de administrador utiliza este valor de compensación para proporcionar un espacio mientras acomoda otros fragmentos alrededor del que falta, de modo que el espacio se pueda llenar una vez se reciba el fragmento faltante. Por ejemplo, para crear un espacio vacío en la memoria para que cuando finalmente se reciba la trama que falta, esta se acomode en este espacio vacío para completar el mensaje final. Mientras tanto, la capa superior de transporte espera a que lleguen los fragmentos y a continuación busca cualquier fragmento faltante en la secuencia. Una vez que la capa genera una lista de todos los fragmentos faltantes, solicita la retransmisión de fragmentos desde el transmisor. Una vez se reciben los fragmentos faltantes, estos se envían a las capas superiores para que puedan usarse para llenar los espacios vacíos en el mensaje final.

Cuando se requiere retransmisión, la capa superior de transporte en el extremo del receptor envía un mensaje de solicitud de retransmisión con el número de fragmento deseado. El extremo receptor mantiene una lista de fragmentos faltantes y, a medida que se reciben los fragmentos faltantes, su entrada se elimina de esta lista.

Si el transmisor retransmite un fragmento ya transmitido, el receptor compara el número de fragmento con el último número de fragmento recibido y detectará que ha habido una retransmisión. La capa comprueba si la retransmisión fue solicitada por el receptor de forma explícita o no. Si la retransmisión fue intencional, el fragmento se consume; de lo contrario, el fragmento se descarta suponiendo una retransmisión de datos falsa.

Una vez que el transmisor envía fragmentos del tamaño de una ventana, inicia un temporizador y espera un acuse de recibo sobre el último fragmento de la secuencia. El transmisor puede enviar más fragmentos solo cuando recibe un acuse de recibo. Si el acuse de recibo se retrasa y el temporizador expira, el transmisor puede enviar un mensaje de solicitud de "tamaño de ventana" antes de retransmitir los fragmentos. Un receptor puede fallar en el envío de un acuse de recibo si el receptor está demasiado ocupado o sus memorias intermedias están llenos. Por lo tanto, se envía un mensaje de "tamaño de ventana" porque tiene dos propósitos, el primero es que una respuesta a este mensaje implica que el receptor está listo para aceptar mensajes, y el segundo es que la nueva memoria intermedia de tamaño de ventana respondida está disponible en el receptor, de modo que aumentan las posibilidades de obtener un acuse de recibo.

En caso de que falten fragmentos, el receptor envía una solicitud de retransmisión en lugar de un acuse de recibo. Solo se puede enviar una solicitud de retransmisión si el último fragmento de la secuencia se recibió con éxito o se descubrió que faltaba. Por lo tanto, el transmisor considera un mensaje de solicitud de retransmisión como un acuse de recibo implícito y ya no espera un acuse de recibo explícito, sino que puede esperar el acuse de recibo del fragmento retransmitido.

Los fragmentos faltantes pueden ser de tres tipos: falta el primer fragmento, falta cualquier fragmento(s) entre el primer y el último fragmentos de un mensaje completo, y falta el último fragmento. Si falta el primer fragmento y el receptor comienza a recibir desde el fragmento número 2, acumula todos los mensajes hasta que recibe mensajes de tamaño de ventana y solicita explícitamente el 1er fragmento. Se utiliza la misma técnica para solicitar cualquier fragmento faltante entre el 1er y el último fragmento.

Que falte el último fragmento de un mensaje completo puede ser un escenario complicado porque el transmisor nunca informa al receptor sobre el número total de fragmentos necesarios para enviar un mensaje y, por lo tanto, no hay forma de que el receptor sepa cuándo se completa el mensaje. Los "últimos" fragmentos faltantes pueden ser de dos tipos, que falte el último fragmento de una ventana y que falte el último fragmento de un mensaje. En el caso de que falte el último fragmento de una ventana, esto es fácil de detectar. Cada vez que se recibe un fragmento, el receptor inicia un temporizador y espera a que se reciba el siguiente fragmento antes de que expire el temporizador.

El transmisor envía el último mensaje para la ventana y espera un acuse de recibo. Si este mensaje se pierde, el receptor espera a que llegue este último fragmento. El temporizador del receptor expira antes que el temporizador del transmisor. A medida que el receptor realiza un seguimiento de las secuencias de fragmentos y del tamaño de la ventana, se da cuenta de que el último fragmento no se recibió a tiempo y, por lo tanto, envía una solicitud de retransmisión del último fragmento.

Un problema más difícil ocurre cuando se pierde el último fragmento de un mensaje. Como el receptor no tiene idea de cuántos fragmentos constituirán un mensaje, busca el fragmento con el indicador 'último fragmento' activado. Este fragmento indica al receptor que fue el último fragmento del mensaje. Si este fragmento se pierde, el receptor no tiene idea de cuándo dejar de volver a ensamblar fragmentos. Para asegurar la entrega de este último fragmento, el transmisor puede utilizar los siguientes dos enfoques.

En el primer enfoque, el transmisor sabe que se acerca el último fragmento. Este reduce explícitamente el tamaño de la ventana para asegurarse de que el último fragmento del mensaje también se convierta en el último fragmento de la ventana. Como el receptor puede detectar el último fragmento de una ventana, si se pierde el último fragmento de un mensaje, el receptor puede solicitar la retransmisión.

En el segundo enfoque, el transmisor enviará el último fragmento con el indicador de 'último fragmento' activado, seguido de algunos fragmentos con carga útil aleatoria pero con un número de fragmento incremental. Si falta el último fragmento del mensaje, el receptor detectará el fragmento faltante ya que habrá un vacío en los números de secuencia y solicitará una retransmisión. Cuando el receptor intenta organizar los fragmentos en secuencia, detecta el fragmento con el indicador de "último fragmento" activado y, por lo tanto, descarta todos los fragmentos que siguen a este fragmento.

Tratamiento de paquetes de datos no fragmentados

Para una trama de datos no fragmentada, esta es recibida primero por la capa inferior de transporte, que inicia un temporizador de tiempo de vida en esta trama y pone la trama en la cola de prioridad adecuada. La trama es seleccionada de la cola de prioridad por la capa superior de transporte, que la reenvía a otras capas, por ejemplo, la capa de sesión.

Capa de sesión

Las principales responsabilidades de la capa de sesión son garantizar la entrega de datos de aplicación a aplicación y generar CID únicos dentro de un sistema. La pila funciona según el principio de proveedor de servicios y consumidor de servicios. La aplicación que proporciona el servicio genera CID únicos para los participantes involucrados. El CID es único dentro del sistema que ejecuta la aplicación del proveedor de servicios, en una o más realizaciones. El CID puede considerarse como una clave utilizada para ocultar la información sobre los puertos de origen y de destino que participan en la comunicación.

La capa de sesión se puede implementar en una capa ligera o muy delgada para comunicación sin conexión, porque un paquete de datos sin conexión contendrá las direcciones de los puertos de origen y de destino como parte de sus cabeceras y, por lo tanto, no utiliza un CID.

Los paquetes que llegan a la capa de sesión se pueden dividir en dos categorías, a saber, de datos y de control. Además, los datos entrantes pueden estar orientados a conexión o sin conexión, y fragmentados o no fragmentados. Transferencia de datos orientados a conexión

La transferencia de datos orientados a conexión utiliza una conexión a través de un proceso de establecimiento de comunicación. Después de que se completa un proceso de establecimiento de comunicación inicial como se describe más adelante, se produce el intercambio de datos. En la transferencia de datos orientados a conexión, las realizaciones de la invención utilizan una cabecera de datos con un indicador de acuse de recibo activado y un tipo de conexión ajustado a 01, por ejemplo. Los datos que se intercambian pueden estar fragmentados o no fragmentados según el tamaño de los datos y el tamaño del paquete subyacente soportado por el medio físico. Datos fragmentados

Cuando una aplicación escribe en un puerto virtual, la capa de sesión añade una cabecera de capa de sesión a los datos y los reenvía a la pila. En una o más realizaciones, la cabecera de la capa de sesión tiene 2 bytes de anchura. Por lo tanto, si se necesita fragmentación en la capa de transporte, el primer fragmento se configura para contener el CID de la capa de sesión, mientras que el resto de los fragmentos pueden contener solo datos de aplicación. La capa de sesión en el extremo receptor reenvía el primer fragmento que contiene la cabecera de la capa de sesión, pero no está segura de dónde reenviar otros fragmentos de la secuencia, ya que no hay información de CID en las cabeceras posteriores. Además, si dos o más aplicaciones en un dispositivo desean enviar datos a un dispositivo, no es posible sin más información en general en el extremo receptor añadir datos fragmentados porque no hay forma de identificar de manera única qué aplicación está enviando qué fragmento de datos. Para resolver este problema, la capa de transporte copia la cabecera de la capa de sesión en todos los fragmentos relacionados. Como todos los fragmentos contendrán ahora CID, estos se pueden identificar de forma única en el extremo receptor.

La cabecera de la capa de sesión contiene un indicador de acuse de recibo que se utiliza en el caso de mensajes completos. Como la capa de sesión garantiza la entrega de datos de aplicación a aplicación, activa el indicador de acuse de recibo para que el receptor acuse la entrega satisfactoria de datos. Dado que la cabecera se copia en cada fragmento, la capa de sesión mirará el indicador y acusará recibo al transmisor cada vez que se entregue un fragmento, que no es para lo que generalmente son los acuses de recibo, es decir, un acuse de recibo de mensaje completo.

Para evitar este problema, la capa superior de transporte en el extremo del receptor añade metadatos a los paquetes a medida que se envían a la pila. Los metadatos junto con el puntero al fragmento de datos recibido se denominan testigo y, en lugar de pasar datos, la capa de transporte pasa un testigo a la capa de sesión. En el caso de excepciones en el comportamiento de la capa de sesión, los metadatos proporcionan pautas a seguir por la capa de sesión. Por ejemplo, la capa de sesión no enviará ninguna acuse de recibo de los fragmentos de datos, y cuando la capa superior de transporte recibe un fragmento con un indicador de "último fragmento" activado, actualiza los metadatos para que la capa de sesión sepa que tiene que enviar una acuse de recibo a el transmisor respecto a la recepción de un mensaje completo.

Flujo de control

A medida que los fragmentos se mueven a través de la capa de sesión, la capa de sesión extrae el CID de los fragmentos, realiza una búsqueda en la tabla de ID de comunicación según el CID y la dirección lógica de origen obtenida de los metadatos. La capa de sesión determina los puertos de origen y de destino del descriptor de archivo asociados para el CID. Una vez se conoce el descriptor de archivo, elimina todas las cabeceras y modifica los metadatos para comunicar el detalle del descriptor de archivo a la capa de administrador.

Una vez que el fragmento llega a la capa de administrador, la capa de administrador extrae la información del descriptor de archivo de los metadatos y reenvía el fragmento a la aplicación respectiva. Antes de que la capa de administrador reenvíe el mensaje a la aplicación, determina si el descriptor de archivo todavía está en uso y en el estado de aceptación de datos. Si las condiciones son favorables, el mensaje se copia en la memoria intermedia de aplicación y se activa un indicador de "mensaje recibido" en el descriptor de archivo. Si la operación actual en el descriptor de archivo es una lectura de bloqueo, la llamada a la función de lectura retorna con el número de bytes disponibles en la memoria intermedia de aplicación. Si la operación actual es una llamada sin bloqueo, la aplicación verifica el indicador y, si está activado, lee los datos de la memoria intermedia, o la capa de administrador puede realizar una llamada de función asíncrona al recibir los datos.

Después de entregar los datos a la aplicación, la capa de administrador devuelve el testigo a la capa de sesión. Este testigo contiene información sobre el estado del mensaje pasado anteriormente. Según el estado del testigo, la capa de sesión realiza actividades tales como enviar un acuse de recibo de capa de sesión a sesión.

Si los datos están fragmentados, la capa de sesión modifica adicionalmente este testigo y lo envía a la capa de transporte; de lo contrario, la capa de sesión consume el testigo. La capa de transporte determina si los fragmentos se entregaron en la secuencia en que se enviaron y, en consecuencia, controla los acuses de recibo y los tamaños de ventana.

Datos no fragmentados

Si el tamaño de un mensaje es menor que la unidad máxima de transmisión (MTU), no se requiere fragmentación y el mensaje completo se envía en una trama. A medida que la trama sube en la pila, la capa superior de transporte añade muy poca información a los metadatos, ya que la información completa para la capa de sesión ya está disponible en la cabecera de las tramas. La capa de sesión lee la cabecera y extrae el tipo de datos. Si el tipo de datos es de datos orientados a conexión, la capa de sesión extrae el CID y realiza una búsqueda en la tabla de CID para determinar los puertos de origen y de destino. La capa de sesión elimina todas las cabeceras del datagrama, actualiza los metadatos con el descriptor de archivo de destino y los reenvía a la capa de administrador.

Transferencia de datos sin conexión

Tal como se ha mencionado anteriormente, en una transferencia de datos sin conexión, la capa de sesión puede implementarse en una capa ligera o muy delgada. Como la transferencia de datos sin conexión no utiliza un establecimiento de comunicación, no se genera ningún CID. Debido a la ausencia del CID, la cabecera del protocolo utiliza direcciones de puertos de origen y de destino. La capa de sesión lee la dirección del puerto de destino y determina el descriptor de archivo asociado y reenvía el mensaje a ese puerto. Como la transmisión de datos sin conexión no garantiza la entrega de datos, el indicador de acuse de recibo de las tramas se ajusta en falso.

Si una trama de datos sin conexión es más grande que la MTU, la capa superior de transporte fragmenta los datos en tamaños manejables sin activar el indicador de acuse de recibo de la capa de transporte, tal como se haría en comunicaciones basadas en conexión. Durante el reensamblado, si la capa de transporte ve algún fragmento faltante, descarta el mensaje completo. Por medio de un testigo, la capa de transporte informa a las capas superiores que descarten los fragmentos acumulados previamente en la memoria intermedia de aplicación.

Capa de administrador

La capa de administrador maneja los descriptores de archivo y reenvía los paquetes desde las capas inferiores a los manejadores de archivos apropiados. La capa de administrador también realiza la copia de datos del fondo de memoria a la memoria intermedia de aplicación. La capa de administrador conoce el tamaño de la memoria intermedia de aplicación, y el tamaño de la memoria intermedia de aplicación puede ser menor que la longitud de una trama.

Si la memoria intermedia de aplicación es lo suficientemente grande, la capa de administrador copia el mensaje completo en la memoria intermedia de aplicación. Si la memoria intermedia de aplicación no es lo suficientemente grande, la capa de administrador copia los datos de forma secuencial. La capa de administrador llena la memoria intermedia de aplicación con datos y espera a que la aplicación lea los datos antes de copiar la siguiente porción de datos. Una vez que los datos se entregan con éxito a la aplicación, según el testigo, la capa de administrador informa del éxito a la capa de sesión.

Flujo de control hacia arriba de la pila

A continuación se describe el flujo de control se describe a medida que los datos ascienden en la pila desde la capa más baja hasta la capa de aplicación.

Capa de enlace de datos

El control de la capa de enlace de datos se describe con respecto a las dos subcapas que componen la capa de enlace de datos, a saber, la capa de enlace y la capa MAC. La capa MAC controla los controladores de bus físicos. Capa MAC

Cuando el datagrama llega al bus físico, el controlador del bus copia el datagrama en una memoria intermedia. Una vez que el datagrama completo está disponible en la memoria intermedia, la capa MAC llama a una API en la capa de enlace para copiar los datos disponibles en el fondo de memoria.

La API de la capa de enlace devuelve un valor para indicar el resultado de la operación de copia. La operación puede tener éxito o fallar. El código de error devuelto proporciona el motivo de cualquier fallo. La capa MAC espera a que la API finalice la operación antes de almacenar los nuevos datos disponibles en la memoria intermedia.

Capa de enlace

Tal como se ha explicado en las secciones anteriores, el fondo de memoria puede estar fragmentado debido a que las aplicaciones consumen datos a velocidades aleatorias, lo que genera agujeros en el fondo de memoria. En una o más realizaciones, la capa de enlace mantiene una lista de enlaces, o una lista de enlaces duplicada, o un mapa de bits o cualquier otra estructura de datos capaz de almacenar en el fondo de memoria ubicaciones de memoria disponibles. Cuando una ubicación de memoria está disponible, se añade un puntero a la ubicación de memoria al final de la lista. Cuando un nuevo datagrama está disponible, se copia en la memoria señalada por el puntero en el encabezado de la lista. Aunque el mensaje recibido puede ser de cualquier tamaño y existe un tamaño máximo, por ejemplo 256 bytes, el tamaño del fondo de memoria se selecciona para que sea un múltiplo entero del tamaño máximo del datagrama. Esto simplifica la gestión de la memoria, dado que la pila conoce el tamaño de la memoria asignada dado el puntero a esa memoria. Puede haber casos en que un datagrama esté disponible en el momento en que la memoria está disponible en el fondo de memoria. En este caso, tanto el proceso de copia como el de eliminación intentarán acceder a la lista simultáneamente, lo que generará problemas de concurrencia. En una o más realizaciones, el fondo de memoria puede incluir memorias intermedias de tamaño no uniforme para una implementación de memoria intermedia más flexible a costa de la complejidad de la gestión de la memoria, tal como reconocerá un experto en la materia.

Cuando la capa MAC llama a una API para copiar los datos de la memoria intermedia de hardware al fondo de memoria, la API primero verifica la lista en busca de cualquier ubicación de memoria disponible en el fondo. Si hay memoria disponible, la API copia el datagrama en la ubicación de memoria señalada por el encabezado de la lista y elimina el puntero de la lista. Si no hay espacio disponible, por ejemplo, la lista de enlaces está vacía o se produce un error durante la copia en el fondo de memoria, la API devuelve el código de error correspondiente.

Después de copiar con éxito el datagrama, la API añade el puntero al datagrama en una lista con una cantidad de ciclos del temporizador restantes antes de que los datos se entreguen a la aplicación. Esta API puede ser reentrante ya que la capa MAC puede estar viajando sobre múltiples arquitecturas de bus y los datos pueden estar disponibles en múltiples memorias intermedias al mismo tiempo, con el resultado de llamar a esta API mientras la capa aún está dando servicio a la llamada anterior.

La pila de protocolos puede implementarse con un límite de tiempo dentro del cual un datagrama va a ser utilizado por una aplicación, o bien, el datagrama se elimina del fondo de memoria. Para habilitar esta función, las realizaciones pueden implementar una lista global que contiene punteros a cada datagrama con el contador del temporizador en cada puntero. A medida que llegan nuevos paquetes, una API añade el puntero a este paquete al final de esta lista. La API añade el valor de "tiempo de vida" al cómputo del temporizador actual y genera un cómputo del temporizador que representa el tiempo de caducidad de los paquetes. Cuando cambia el cómputo del temporizador, una API mira el cómputo del temporizador a partir del elemento más alto de la lista y comienza a eliminar el datagrama si sus cómputos de temporizador son menores o iguales que el cómputo del temporizador actual.

Una vez la aplicación consume los datos o se agota el tiempo de espera de los datos, se llama a una API para eliminar del fondo de memoria el datagrama y añadir el puntero a la lista de memoria disponible. Esta API puede ser reentrante, ya que los datos pueden caducar en el mismo momento en que la aplicación los consumió. Ambos procesos pueden intentar eliminar el mismo datagrama, por lo tanto, se pueden utilizar semáforos/bloqueos para serializar el control de manera efectiva.

Cuando los datos se copian en el fondo de memoria, la capa de enlace genera un testigo para el paquete. El testigo contiene el puntero al datagrama y la longitud del datagrama. Este testigo se reenvía a la capa de transporte a través de una API de capa de transporte para su posterior procesamiento.

Capa de transporte

Después de que la capa inferior de transporte recibe un testigo, la capa inferior de transporte determina si la trama es un mensaje de capa de transporte a capa de transporte. Si el 'indicador de capa' está activado, estos tipos de mensajes son mensajes de capa a capa y, por lo tanto, no se reenvían a capas superiores. Si el indicador no está activado, la capa inferior de transporte observa la prioridad del mensaje y coloca el testigo en la cola de prioridad adecuada.

En una o más realizaciones, la capa superior de transporte recibe el testigo de la cola de prioridad y determina si el "indicador extendido" está activado o no. Si el indicador está activado, esto indica que se espera un gran volumen de datos e informa a la API de que se ha utilizado un byte adicional en la cabecera para secuenciar un gran número de fragmentos.

La capa también lee el indicador "Último fragmento". Un indicador de 'último fragmento' activado indica a la capa que el fragmento de datagrama actual es el último fragmento en la secuencia de fragmentos y, por lo tanto, el final de un mensaje. Si hay alguna fragmentación, al menos un fragmento tendrá este indicador activado.

La capa lee además el indicador de acuse de recibo. Si el transmisor solicita, o bien se le va a enviar un acuse de recibo para la entrega del datagrama a la capa de transporte del receptor, la capa activará este indicador y el receptor acusará recibo del paquete. Si los dispositivos involucrados en la comunicación acordaron un tamaño de ventana para acuses de recibo, entonces la capa de transporte acusa recibo después de recibir mensajes de tamaño de ventana; de lo contrario, la capa acusa recibo de cada datagrama.

La capa superior de transporte añade más información al testigo de datos y lo reenvía a la capa de sesión. La capa superior de transporte informa a la capa de sesión de si el mensaje es un mensaje completo o no. En el caso de un mensaje fragmentado, la capa de transporte informa a la capa de sesión sobre la recepción del último fragmento, de modo que la capa de sesión puede enviar un acuse de recibo si es necesario.

Capa de sesión

A partir del puntero de datos en el testigo, la capa de sesión accede a la trama y extrae la cabecera de la capa de sesión. A partir de la cabecera, la capa de sesión primero determina si el mensaje es un mensaje de capa a capa o tiene que reenviarse a la pila. Si el mensaje es un mensaje de tipo capa a capa, entonces el mensaje es consumido por la capa de sesión.

Si el indicador de capa no está activado, la trama se reenvía a la pila. La capa de sesión lee el campo 'tipo de conexión' y determina si el mensaje es de un tipo de conexión desconocido, u es orientado a conexión o sin conexión. Un tipo de conexión desconocido es generalmente para los mensajes intercambiados durante el proceso de establecimiento de comunicación, mientras que un mensaje sin conexión no necesita un acuse de recibo para la entrega, y los mensajes orientados a conexión son los que utilizan un acuse de recibo en la entrega satisfactoria. La capa de sesión examina más a fondo el campo de tipo de mensaje para determinar el tipo de trama. El tipo de trama se usa para determinar el propósito de la trama, y solo las tramas de tipo 'datos' se reenvían a la pila y las tramas de tipo de control se consumen en la capa de sesión.

El CID es generado por la aplicación que proporciona un servicio. Cualquier aplicación que quiera utilizar el servicio solicitará un ID de comunicación. El CID es único dentro de un módulo, por ejemplo, todos los CID generados por el UIC son únicos dentro de un UIC en particular. El CID se genera a través de un proceso de establecimiento de comunicación, donde la aplicación que utiliza el servicio envía los detalles necesarios para identificar de forma única una conexión activa y recibe el CID en respuesta.

Los pormenores y detalles de CID pueden almacenarse en una tabla de CID ubicada en una región de memoria compartida, en una o más realizaciones, de modo que las capas de sesión de todas las aplicaciones pueden acceder al CID. En una trama de datos sin conexión, no hay información de CID ya que no se utiliza un establecimiento de comunicación para establecer una conexión. Por lo tanto, las tramas sin conexión contienen las direcciones de los puertos de origen y de destino en la cabecera.

En una transferencia de datos orientada a conexión, existe un CID en la cabecera de la capa de sesión. Una vez que la capa de sesión determina el CID a partir de la cabecera, la capa combina la información con la dirección lógica de origen disponible en el testigo de datos para identificar de manera única una entrada en la tabla CID. A partir de esta tabla, la capa de sesión determina la dirección de los puertos de origen y de destino y los descriptores de archivo que gestionan el puerto. La dirección lógica de origen de la trama recibida es ajustada por la capa de enlace de datos junto con la información del manejador de archivos y se reenvía en el testigo de datos a la capa de administrador.

Si la trama recibida está orientada a conexión y es un mensaje completo, la capa de sesión mantiene un registro del mensaje y reenvía el testigo de datos a la capa de administrador. Una vez que la capa de administrador copia la trama del fondo de memoria en la memoria intermedia de aplicación, la capa de administrador notifica a la capa de sesión la entrega satisfactoria de datos. Al recibir la notificación, la capa de sesión envía un acuse de recibo a la capa de sesión del transmisor con respecto a la entrega satisfactoria de datos. Si la entrega no tuvo éxito, como parte del acuse de recibo, la capa de sesión reenvía el mensaje de error devuelto por la capa de administrador al transmisor.

Capa de administrador

La capa de sesión llama a una API en la capa de administrador y pasa el testigo de datos a la capa de administrador. La capa de administrador copia los datos del fondo de memoria en la memoria intermedia de aplicación y notifica a la capa de sesión sobre la copia. La capa de administrador notifica a la capa inferior la entrega del mensaje modificando el testigo de datos y enviando el testigo de datos nuevamente a la capa de sesión. Una vez que los datos se copian con éxito, la capa de administrador elimina el puntero de la trama de la lista de tramas monitorizadas por el temporizador y elimina la trama del fondo de memoria para dejar espacio para nuevos paquetes.

Puede suceder que la memoria intermedia de aplicación sea más pequeña que la trama de datos recibida, en tales casos, la capa de administrador llenará la memoria intermedia de aplicación con lo que esta puede contener y esperará a que la aplicación lo consuma. Una vez la aplicación consume el mensaje, la parte restante del mensaje se copia y el proceso se repite hasta que se consume la trama completo. Antes de iniciar el progreso de la copia de mensajes en tamaños pequeños, la capa de administrador elimina el puntero a la trama de la lista supervisada por temporizador porque el temporizador puede caducar y corromper el mensaje. Además, la capa de administrador notifica a la capa inferior la entrega satisfactoria de datos solo cuando se envía un mensaje completo a la aplicación. Al final del proceso de copia secuencial, la capa de administrador elimina la trama del fondo de memoria.

En el caso de datos fragmentados, a medida que esta capa recibe los fragmentos, copia los fragmentos en la memoria intermedia de aplicación y notifica a la capa de sesión. La capa de sesión reenvía la notificación a la capa de transporte. La capa de transporte, después de recibir notificaciones para una cantidad de mensajes del tamaño de ventana, envía un acuse de recibo al transmisor sobre la recepción de los mensajes. Cuando el último fragmento se entrega con éxito a la aplicación, esto implica que se ha entregado un mensaje completo. En tales casos, la capa de administrador notifica el éxito a la capa de sesión, y la capa de sesión envía un mensaje de acuse de recibo al transmisor relativo al éxito, proporcionando así una entrega de datos garantizada.

Flujo de datos descendente por la pila

Suponiendo que en el caso de una transferencia de datos orientados a conexión, el proceso de establecimiento de comunicación ya se realizó y ya se generó un CID válido, la aplicación copia los datos en una memoria intermedia de aplicación y pasa un puntero a la API expuesta por la capa de administrador para enviar datos a través de puertos virtuales. La aplicación también especifica el descriptor de archivo que maneja la comunicación y el tamaño de los datos que se escribirán en el puerto virtual.

La prioridad de un mensaje está determinada por la prioridad del puerto virtual que se esté utilizando, o la prioridad se puede establecer para el mensaje que pasa. Por lo tanto, a través de un conjunto de API, la capa de administrador informa a la capa de sesión sobre la prioridad de los datos, el tamaño de los datos, el descriptor de archivo para la comunicación, el puntero a la memoria intermedia de aplicación y si los datos son orientados a conexión o sin conexión. Si los datos son sin conexión, la capa de sesión examina la tabla de descriptores de archivo y determina el número de puerto asociado con el descriptor de archivo. A continuación, la capa de sesión añade las direcciones de los puertos de origen y de destino como cabecera a los datos. Si la transferencia va a estar orientada a conexión, la capa de sesión realiza una búsqueda en la tabla CID y determina el CID asociado con el descriptor de archivo y añade este CID como cabecera a los datos. A continuación, la capa de sesión reenvía este puntero a la capa de transporte y espera un acuse de recibo del receptor.

La capa superior de transporte determina el tamaño de los datos y determina si se requiere fragmentación o no. Si se necesita fragmentación, la capa superior de transporte divide los datos en tamaños manejables y añade información a la cabecera para que los datos puedan volver a ensamblarse en la capa superior de transporte del receptor. Si no se necesita fragmentación, la capa superior de transporte sigue añadiendo alguna información, en una o más realizaciones. Por ejemplo, la capa superior de transporte copia los datos de la memoria intermedia de aplicación en el fondo de memoria del transmisor y, según la prioridad de los datos, almacena el puntero en las colas de mensajes adecuadas.

La capa inferior de transporte finalmente lee el puntero de la cola de prioridad y lo reenvía a la capa de enlace. La capa de enlace determina la dirección lógica de destino y la añade a la cabecera de datos, calcula un CRC en la trama y lo añade a la trama antes de enviarlo. La capa MAC determina el bus en el que está disponible el destino y envía los datos a través de ese bus.

Flujo de datos ascendente en la pila

A medida que la trama de datos llega al bus subyacente, la capa MAC determina si la trama es para el subsistema o para algún otro subsistema. Si es para algún otro subsistema, la capa MAC descarta la trama de datos. La capa MAC copia tramas de datos válidos en una región de memoria compartida y llama a una API en la capa de enlace para informarle sobre la llegada de nuevos datos. En toda la pila, solo se actualiza el puntero a estos datos para reducir la copia múltiple de fragmentos.

La capa de enlace calcula el CRC en la trama recibida y compara el CRC calculado con el CRC en la trama recibida. Las tramas con CRC no válidos se eliminan. Los punteros a tramas válidas se reenvían a la capa inferior de transporte.

La capa inferior de transporte lee la prioridad de la trama y añade un puntero a la trama a la cola de prioridad respectiva. El puntero a la trama permanece en la cola y espera a que la aplicación adecuada lo consuma. Finalmente, la capa superior de transporte de la aplicación de destino lee el puntero a la trama desde la cola de prioridad.

La capa superior de transporte examina las cabeceras para determinar si los datos están fragmentados o son un mensaje completo. Si los datos están fragmentados, la capa vuelve a ensamblar todos los mensajes de la secuencia y a continuación los reenvía a la capa de aplicación. Si los datos no están fragmentados, reenvía directamente el puntero a la trama, a la capa de sesión a través de llamadas API apropiadas.

La capa de sesión examina las cabeceras de las tramas y determina si el mensaje es del tipo sin conexión u orientado a conexión. Si el mensaje es sin conexión, la capa de sesión busca el número de puerto de destino y determina el descriptor de archivo que maneja ese puerto. La capa de sesión reenvía el puntero a la capa de administrador con la información adecuada del descriptor de archivo. Si la trama es orientada a conexión, la capa de sesión lee el CID y determina el manejador de archivos que maneja esa comunicación. La capa de sesión a continuación reenvía la información del descriptor de archivo a la capa de administrador y espera un acuse de recibo de la capa de administrador. La capa de administrador envía un acuse de recibo que indica si los datos se entregaron a la aplicación o no. Esta información es utilizada por la capa de sesión para acusar recibo de los datos. La capa de administrador puede implementarse con una capa ligera o delgada y es responsable de copiar los datos del fondo de memoria en la memoria intermedia de aplicación y liberar el fondo de memoria. Una vez los datos se copian en la memoria de la aplicación, la capa de administrador informa a la aplicación sobre los datos disponibles. La capa de administrador envía un acuse de recibo a la capa de sesión. Así, a las aplicaciones, la capa de administrador ofrece métodos síncronos y asíncronos para leer y escribir en los puertos virtuales.

La figura 9 ilustra un diagrama de actividad que muestra el enrutamiento entre varios dispositivos. Tal como se muestra, el dispositivo A está conectado directamente al dispositivo B, que está conectado directamente al dispositivo C. El dispositivo A no está conectado directamente al dispositivo C. Cuando el dispositivo A intenta enviar un mensaje al dispositivo C, envía el mensaje y el dispositivo B lee el mensaje, determina que el mensaje no es para el dispositivo y verifica si hay una ruta al dispositivo en la tabla de destino del dispositivo B. Si es así, el dispositivo B reenvía el mensaje al dispositivo C, que procesa los datos. Por lo tanto, las realizaciones de la invención permiten configuraciones de enrutamiento y cadena tipo margarita o multibus que generalmente no son tan flexibles como son posibles en dispositivos médicos tales como bombas de infusión.

A continuación se detalla una realización de la API de la capa de administrador. La capa de administrador proporciona la API para habilitar la programación de sockets sobre la pila de protocolos. Las llamadas a la API de la capa de administrador son utilizadas por cualquier aplicación que desee transferir datos usando una realización de la invención.

pro_socket - crea un socket independiente en un dominio de comunicación y devuelve un descriptor de archivo que se puede usar en llamadas de función posteriores que operan sobre sockets.

int16 pro_socket (tipo ConnectionType, uint8 *pSocket)

Argumentos:

type: especifica el tipo de socket que se va a crear (CONNECTIONTYPE y CONNECTIONLESSTYPE para intercambio de datos orientado a conexión y sin conexión).

pSocket: puntero entero para devolver el socket recién creado.

typedef enum ConnType

{

CONNECTIONTYPE = 1,

CONNECTIONLESSTYPE = 2,

RAWTYPE = 3

} ConnectionType;

Al completarse con éxito, la función devolverá un ÉXITO; de lo contrario, se devuelve el código de error apropiado. La API devuelve el socket asignado en la variable de referencia pSocket pasada como parámetro.

pro_bind - asigna una dirección local a un socket identificado por el socket del descriptor de archivo.

int16 pro_bind (uint8 uint8Socket, const ProSockaddr *pAddress)

typedef struct pro_sockaddr

{

dirección uint8;

portNo uint8;

prioridad uint8;

indicadores uint8;

tiempo de espera uint32;

*filtro datafilter;

} ProSockaddr;

dirección: contiene la dirección lógica del dispositivo

portNo: contiene el número de puerto para la conexión

prioridad: contiene la prioridad del puerto. Todos los datos que pasan por este puerto heredan la prioridad de los puertos

indicadores: contiene indicadores de configuración para cambiar el comportamiento del socket

TIMEOUT: el indicador está activado, espera a que se complete una operación dentro de un período de tiempo determinado, de lo contrario, regresa.

SOJJNGER: el indicador activado indica que una conexión se terminará solo cuando todos los datos pendientes de enviar se envíen con éxito.

FILTERj DATA: el indicador activado indica que los datos que se corresponden con el patrón de filtro proporcionado solo se reenviarán a la función de devolución de llamada registrada para manejarlo. Si se restablece el indicador, los datos que se corresponden con el filtro se enviarán tanto al manejador de socket normal como a la función de devolución de llamada registrada.

timeout: si se establece el indicador TIMEOUT, el valor de tiempo de espera se especifica aquí. Un valor de tiempo de espera de 0 regresa inmediatamente.

filtro: lista de enlaces de estructura de tipo filtro de datos que define el filtro que se aplicará a los datos recibidos. Más de un elemento en esta lista de enlaces tendrá una propiedad de operador lógico OR. Por ejemplo, si una aplicación desea procesar datos de PMC, UIC, CE o los tres, creará tres nodos en esta lista de enlaces, uno para cada PMC, UIC y CE.

La estructura de filtro de datos se utiliza para permitir que las aplicaciones seleccionen qué mensajes desean recibir y qué función debe manejar qué tipo de mensajes. Se utiliza un patrón de expresión regular para crear un filtro sobre los datos recibidos y, una vez se encuentra una correspondencia, los datos se reenvían a la función de devolución de llamada registrada.

typedef struct

{

char *regEx;

índice uint8;

longitud uint8;

*devolución de llamada vacío;

*filtro datafilter;

}datafilter;

regEx: puntero a la expresión regular que se usará para la correspondencia.

índice: ubicación para comenzar a buscar correspondencias en la sección de datos del mensaje recibido. Un '0' en este campo indica que la correspondencia comenzará desde el principio.

longitud: a partir del índice proporcionado, indica la longitud de la sección de datos que se considerará para la correspondencia de expresiones regulares. Si índice contiene '0' y longitud contiene '0', la correspondencia se realizará en toda la sección de datos.

devolución de llamada: función que se llamará en caso de una correspondencia satisfactoria. Si este campo se ajusta a nulo, todos los paquetes de datos en correspondencia se eliminarán según el indicador FILTER_DATA. filtro: lista de enlaces de cualquier filtro adicional que se añadirá sobre el filtro existente. Si este campo contiene filtros adicionales, en una correspondencia satisfactoria, se realiza una devolución de llamada a la función especificada en la estructura que contiene esta lista de enlaces. Esta lista de enlaces de filtros tiene propiedades de operador lógico Y, es decir, una correspondencia es satisfactoria solo si todas las expresiones regEx especificadas en todos los filtros se corresponden. Como ejemplo, si una aplicación desea procesar datos que contienen expresiones PMC, UIC y CE, instanciará este filtro para PMC y tendrá una lista de enlaces que contiene filtros para UIC y CE respectivamente.

Una o más realizaciones soportan tres niveles de prioridad para mensajes, a saber, alta, media y baja. La enum que define la prioridad del mensaje es la siguiente.

typedef enum ProPriority

{

HIGHPRIORITYTYPE = 1,

MEDIUMPRIORITYTYPE = 2,

LOWPRIORITYTYPE = 3

} MessagePriority;

Argumentos:

uint8Socket: descriptor de archivo del socket que va a vincular

pAddress: puntero a la estructura ProSockaddr que contiene la dirección a vincular al socket.

Valor de retorno:

al completarse con éxito, la función devolverá ÉXITO; de lo contrario, el código de error apropiado.

pro_connect: intenta conectar un socket a la dirección especificada.

int16 pro_connect (uint8 uint8Socket, const ProSockaddr *pAddress)

Argumentos:

uint8Socket: socket que se va a conectar a la dirección especificada.

pAddress: puntero a la estructura pro_sockaddr que contiene la dirección del par.

Valor de retorno:

Al completarse con éxito, la función devolverá ÉXITO; de lo contrario, devuelve el código de error apropiado pro_listen - marca el socket al que hace referencia "socket" como un socket pasivo, es decir, como un socket que se usará para aceptar solicitudes de conexión entrantes usando accept().

int16 pro_listen (uint8 uint8Socket, uint8 uint8Backlog)

Argumentos:

uint8Socket: descriptor de archivo de un socket que se tiene que poner en modo de aceptación de conexiones. uint8Backlog: establece un límite sobre el número de conexiones pendientes en la cola de escucha del socket. Un cero ajustaría la longitud de la cola a la longitud de cola mínima definida por el sistema.

Valor de retorno:

Al completarse con éxito, la función devolverá ÉXITO; de lo contrario, se devuelve el código de error apropiado. pro_accept - extrae la primera conexión en la cola de conexiones pendientes, crea un nuevo socket conectado con el mismo protocolo de tipo de socket y familia de direcciones que el socket especificado y devuelve un nuevo descriptor de archivo para el socket.

int16 pro_accept (uint8 uint8Socket, ProSockaddr ‘pAddress, uint8 *pClientSocket)

Argumentos:

uint8Socket: descriptor de archivo asociado con socket.

pAddress: un puntero NULO o un puntero a la estructura ProSockaddr donde se devolverá la dirección del socket de conexión.

pClientSocket: puntero a un entero sin signo para devolver el descriptor de archivo asociado con el socket recién creado.

Valor de retorno:

Una vez completado con éxito, se devuelve ÉXITO junto con un descriptor de archivo asociado para el socket recién creado; en caso de fallo, devuelve el código de error apropiado.

pro_send - inicia la transmisión de un mensaje desde el socket especificado a su par. La función pro_send() envía un mensaje cuando el socket está conectado.

int16 pro_send (uint8 uint8Socket, const void ‘pBuffer, uint32 intLength, uint32 *pBytesSent)

Argumentos:

uint8Socket: descriptor de archivo del socket

pBuffer: apunta a la memoria intermedia que contiene el mensaje a enviar.

intLength: longitud del mensaje en bytes.

pBytesSent: puntero a un número entero para devolver el número real de bytes enviados.

Valor de retorno:

Una vez completada con éxito, la API devuelve ÉXITO; de lo contrario, se devuelve el código de error apropiado.

pro_recv - recibe un mensaje de un socket en modo conexión o modo sin conexión. Normalmente se usa con sockets conectados porque no proporciona la dirección de origen de los datos recibidos a la aplicación.

int16 pro_recv (uint8 uint8Socket, void *pBuffer, uint32 uintLength, uint32 *pBytes *pBytesReceived) Argumentos:

uint8Socket: descriptor de archivo de socket.

pBuffer: puntero a la memoria intermedia donde se debe almacenar el mensaje.

uintLength: longitud en bytes del mensaje a recibir.

pBytesReceived: puntero a un número entero para devolver el número de bytes realmente recibidos.

Valor de retorno:

Una vez completado con éxito, se devuelve ÉXITO junto con el número de bytes en la referencia pasada como parámetro; de lo contrario, devuelve el código de error apropiado.

pro_close - desasigna el descriptor de archivo y hace que el descriptor de archivo esté disponible para funciones que asignan descriptores de archivo. Se eliminan todos los bloqueos de registro pendientes propiedad del proceso en el archivo asociado con el descriptor de archivo. Hace que el socket se destruya. Si el socket es orientado a conexión, y la opción SOJJNGER está activada para el socket con un tiempo de permanencia distinto de cero, y el socket tiene datos no transmitidos, entonces pro_closeO bloquea hasta el intervalo de permanencia actual para todos los datos pendientes para ser transmitido.

int16 pro_close (uint8 uint8Socket)

Argumentos:

uint8Socket: descriptor de archivo del socket que debe cerrarse.

Valor de retorno:

Al completarse con éxito, la función devolverá ÉXITO; de lo contrario, se devolverá el código de error apropiado. Un experto en la técnica reconocerá que, además de la API ejemplar ilustrada anteriormente para la capa de administrador, las API para las capas de sesión, de transporte y de enlace de datos pueden implementarse según se desee para comunicar los mensajes que se muestran en las figuras 10A-D, 11A-B y 12A-B dependiendo de la aplicación deseada.

Una o más realizaciones de la invención pueden implementarse como un sistema o método. Por ejemplo, al menos una realización puede incluir un método de comunicación de dispositivos médicos que incluye aceptar una solicitud de un dispositivo programable para obtener un identificador de dispositivo asociado con un dispositivo transmisor asociado con la solicitud, un tipo de conexión orientada a conexión o sin conexión y un número de dispositivo receptor asociado con un dispositivo receptor al que transmitir un mensaje. El método también puede incluir determinar un número de puerto de un puerto al que transmitir dicho mensaje, por ejemplo, a través de un dispositivo programable solicitante o del dispositivo programable que recibe la solicitud. Las realizaciones también pueden incluir la generación de un identificador de comunicación o CID para al menos las ventajas establecidas a lo largo de esta descripción. Las realizaciones también pueden incluir aceptar una solicitud asociada con una función médica, introducir el CID y la función médica en el mensaje, determinar si el tipo de conexión es orientada a conexión o sin conexión y transmitir el mensaje a un dispositivo médico. Este escenario se muestra con valores de ejemplo para demostrar el formato y la transferencia de mensajes anteriores en las figuras 13A y 13B, que están destinados a acoplarse entre sí en el lado derecho de la figura 13A y el lado izquierdo de la figura 13B.

Las realizaciones también pueden incluir transmitir el mensaje al dispositivo receptor incluso si el dispositivo receptor no está directamente conectado al dispositivo transmisor. Esto permite un enrutamiento integrado que permite que los dispositivos pasen mensajes sin necesidad de un maestro para controlar todas las fases de la comunicación, por ejemplo.

Las realizaciones también pueden incluir aceptar una solicitud de multidifusión configurada para permitir que múltiples dispositivos receptores reciban el mensaje. Las realizaciones pueden incluir además aceptar un parámetro de prioridad configurado para permitir el tratamiento priorizado del mensaje. Esto permite que los mensajes con alta prioridad se entreguen antes que otros mensajes de menor prioridad y en una o más realizaciones pueden implementarse con una pluralidad de estructuras de datos de mensajes tales como colas, listas enlazadas o cualquier otra estructura o estructuras de datos. Las realizaciones pueden incluir transmitir mensajes desde una cola de mensajes de alta prioridad antes de transmitir datos desde una cola de mensajes de baja prioridad. Otras realizaciones pueden aplicar cualquier tipo de patrón de estrategia al proceso de entrega y pueden, por ejemplo, cambiar las estrategias dependiendo del tipo de mensajes que es probable que se reciban en períodos de tiempo particulares. Esto permite el tratamiento y procesamiento predictivo de mensajes para proporcionar una entrega inteligente y robusta de funciones médicas.

Las realizaciones también pueden incluir determinar si el tamaño de los datos a transferir es mayor que un valor de fragmentación predeterminado y empaquetar los datos en una pluralidad de mensajes para facilitar la transferencia. Las realizaciones pueden utilizar eficientemente la memoria y, por ejemplo, reducir la latencia copiando un puntero al mensaje entre una pluralidad de capas de mensajes sin copiar el mensaje en sí. Este es el caso dado que el mensaje no tiene que ser reconstruido en su totalidad dentro de la pila hasta que se reciba el mensaje completo en la aplicación. Además, las realizaciones de la invención pueden utilizar gestión de memoria optimizada que incluye solicitar memoria de una memoria intermedia que incluye tamaños no uniformes para aumentar aún más la eficiencia de la utilización de la memoria de datos y reducir la memoria requerida en general. Cuando se envían paquetes de datos o mensajes que son más grandes que el tamaño máximo permitido por el hardware subyacente, las realizaciones pueden incluir establecer un último indicador de fragmentación en un mensaje final de mensaje fragmentado, iniciar un temporizador para un acuse de recibo y retransmitir el mensaje final si dicho temporizador expira. Se pueden conseguir aumentos adicionales en la eficiencia mediante realizaciones que incluyen recibir una solicitud para cambiar un tamaño de ventana para recibir mensajes fragmentados y ajustar el uso de la memoria en base a esto, por ejemplo, tener tamaños de ventana menores para enlaces de comunicación más fiables. Las realizaciones también pueden incluir proporcionar el identificador de dispositivo a un dispositivo médico nuevo que reemplaza el dispositivo médico después de intercambiar en caliente el dispositivo médico nuevo por el dispositivo médico original, es decir, si ocurre un fallo. Esto permite que las realizaciones de la invención proporcionen una funcionalidad robusta y una sustitución transparente del hardware sin interrumpir las funciones médicas o al menos minimizando las interrupciones. Las realizaciones también pueden incluir proporcionar un puntero a un mensaje completo después de recibir múltiples mensajes fragmentados sin copiar datos del mensaje recibido después de recibirlos. Esto permite que los datos entrantes se introduzcan en una memoria intermedia una vez, y se entreguen a la aplicación después de que se reciban los datos sin, por ejemplo, realizar copias extrañas, lo que reduce la utilización de la memoria y el procesamiento del dispositivo programable requerido. Una o más realizaciones de la invención pueden incluir aceptar una solicitud de infusión asociada con una función médica relacionada con la infusión. Cualquier otro tipo de función médica es acorde con el espíritu de la invención.

Las realizaciones del sistema pueden incluir un dispositivo programable configurado para aceptar una solicitud para obtener un identificador de dispositivo asociado con un dispositivo transmisor asociado con la solicitud, un tipo de conexión de orientada a conexión o sin conexión, un número de dispositivo receptor asociado con un dispositivo receptor al que transmitir un mensaje. Las realizaciones del sistema pueden determinar además un número de puerto de un puerto al que transmitir dicho mensaje, generar un identificador de comunicación o CID y aceptar una solicitud asociada con una función médica. El sistema también puede introducir el CID y la función médica en el mensaje, determinar si el tipo de conexión es orientada a conexión o sin conexión y transmitir el mensaje a un dispositivo médico. Las realizaciones del sistema también pueden implementar toda la funcionalidad del método descrito anteriormente y pueden utilizar cualquiera de las estructuras de datos o API descritas aquí en combinación.

Si bien la invención aquí descrita se ha dado a conocer por medio de realizaciones específicas y aplicaciones de la misma, los expertos en la materia podrían realizar numerosas modificaciones y variaciones en la medida en que estas modificaciones y variaciones estén dentro del alcance de la invención definida en las reivindicaciones.

Claims

REIVINDICACIONES

1. Un método de comunicación de dispositivos médicos para un sistema de bomba de infusión, comprendiendo el método:

un control de motor de bomba, PMC, que acepta una solicitud de conexión de un controlador de interfaz de usuario, UIC, comprendiendo la solicitud:

un identificador de dispositivo del UIC,

un número de dispositivo receptor del PMC al que transmitir un mensaje de datos de infusión,

en donde el PMC acepta dicha solicitud y genera un identificador de comunicación, CID,

introducir el CID en un mensaje de aceptación de conexión,

transmitir el mensaje de aceptación de conexión al UIC,

en donde el UIC extrae y almacena el CID del mensaje de aceptación de conexión, comprendiendo además el método

aceptar, por el UIC, una solicitud de infusión asociada con una función médica relacionada con la infusión, introducir el CID y dicha función médica en el mensaje de datos de infusión, y

transmitir el mensaje de datos de infusión al PMC.

2. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: aceptar un parámetro de prioridad configurado para permitir el tratamiento priorizado de dicho mensaje de datos de infusión.

3. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: determinar si un tamaño de datos en el mensaje de datos de infusión a transferir es mayor que un valor de fragmentación predeterminado; y

empaquetar dichos datos en el mensaje de datos de infusión en una pluralidad de mensajes de datos de infusión independientemente de la anchura del bus de datos subyacente.

4. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: copiar un puntero a dicho mensaje de datos de infusión entre una pluralidad de capas de mensajes de datos de infusión sin copiar dicho mensaje de datos de infusión en sí mismo.

5. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: solicitar memoria de una memoria intermedia que comprende tamaños no uniformes; o

devolver una memoria intermedia a la memoria si dicha memoria intermedia supera un umbral de antigüedad predefinido.

6. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: establecer un último indicador de fragmentación en un mensaje final de mensaje fragmentado;

iniciar un temporizador para un acuse de recibo; y,

retransmitir dicho mensaje final si expira dicho temporizador.

7. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: recibir una solicitud para cambiar un tamaño de ventana para recibir mensajes fragmentados y

ajustar el uso de la memoria en función de ello.

8. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: transmitir mensajes de datos de infusión desde una cola de mensajes de alta prioridad antes de transmitir datos desde una cola de mensajes de baja prioridad.

9. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además: reensamblar un mensaje fragmentado en un mensaje completo en una memoria intermedia de aplicación.

10. El método de comunicación de dispositivos médicos según la reivindicación 1, en donde la comunicación de la capa de sesión se realiza independientemente de la topología del bus; o en donde

el método comprende además comunicar a través de múltiples buses de datos heterogéneos de manera independiente de la topología del bus, en donde dichos múltiples buses de datos heterogéneos comprenden topologías de anillo, estrella, malla o árbol o cualquier combinación de las mismas.

11. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además utilizar un hilo del núcleo para ejecutar una capa de enlace de datos y una capa inferior de transporte para bloquear operaciones de lectura y escritura o utilizar 2*N+1 hilos del núcleo para operaciones de lectura y escritura asíncronas, donde N es el número de aplicaciones que utilizan dichas operaciones asíncronas de lectura y escritura.

12. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además comunicar usando una capa MAC que abstrae al menos un bus de datos subyacente, donde dicho al menos un bus de datos subyacente comprende caminos de datos en serie o paralelos o buses de datos heterogéneos.

13. El método de comunicación de dispositivos médicos según la reivindicación 1, que comprende además filtrar dicho mensaje de datos de infusión en función de una expresión regular, que especifica la ubicación, la longitud y el contenido de los datos en correspondencia, en la parte de datos del paquete.

14. Un sistema de comunicación de dispositivos médicos que comprende:

un control de motor de bomba, PMC, configurado para aceptar una solicitud de conexión de un controlador de interfaz de usuario, UIC, comprendiendo la solicitud:

un identificador de dispositivo del UIC,

en donde el PMC está configurado para

aceptar la solicitud y generar un identificador de comunicación, CID,

introducir el CID en un mensaje de aceptación de conexión,

transmitir el mensaje de aceptación de conexión al UIC,

en donde el UIC extrae y almacena el CID del mensaje de aceptación de conexión, el UIC está configurado además para

aceptar una solicitud de infusión asociada con una función médica relacionada con la infusión,

introducir dicho CID y dicha función médica en el mensaje de datos de infusión, y

transmitir dicho mensaje de datos de infusión al PMC.