An Approach using Agents to Dynamic DICOM ...

An Approach using Agents to Dynamic DICOM Applications Reconfiguration Abdala, D. D., Luz Jr., A. D., Wangenheim, A. v. February, 2005 {caju, antoniol, awangenh}@inf.ufsc.br The Cyclops Project Laboratory of Telemedicine (LAB TELEMED) Computer Science and Statistics Department (INE) Federal University of Santa Catarina (UFSC) Florianópolis – Santa Catarina – Brazil

Phone: Fax:

+ 00 55 48 331-9516 + 00 55 48 331-9516 R16

Abstract – This work presents a new approach to reconfiguration of DICOM systems using script oriented mobile agents that work in a proactive fashion reacting to configuration changes in either Server or Client’s side, and so, updating the necessary parameters to enable the correct function of PACs Systems. Keywords – Mobile Agents; DICOM; PACs Systems; Server Reconfiguration on the Fly. I.

INTRODUCTION

Within DICOM [1] compliant PACS – Picture Archiving Communication Systems – environments, the usage dynamics says that one or more radiological image servers [2] should receive exams from a sort of different imaging equipments and then store them in a medical image database. However, the image access to diagnosis purpose occurs by exam retrieval using DICOM compliant clients software that must understand and implement the DICOM communication layer as defined in [3] who has a number of information constraints like communication ports, network identification name and IP address. Any change in configuration of this attributes either in client or server sides imply in a configuration change in both client and server communication sides. One possible way to automate this costly human task is the usage of autonomous mobile agents, which should without human intervention watch over configuration changes and then update the necessary hosts. For reasons of data security, medical ethics and computational accessibility, it’s necessary to set up a connection between both client and server hosts and they must previously know each other. To certify some host relinquishment a set of parameters require previous configuration like the host IP address, agreeable

communication ports and a DICOM identification over the network, or AETITLE. However, in a distributed environment like a radiological center or a telemedicine network, where a number of mobile hosts (palm tops, tablets PCs), workstations and servers using as communication protocol the DICOM communication stack, any change in only one host implies a considerable effort of reconfiguration changes in almost all other hosts. A possible automation of such task is possible and subject of this paper, using agent’s technology to listen possible configuration parameter changes, stationary agents, and automatic replication changes in other pertinent hosts, mobile agents. In academics literature exists more references to automatic or dynamics reconfiguration of parameters for a vast group of applications systems, mainly to analyze and reconfiguration of network, between these texts are [11], [12], [13], [14] and [15]. However any these are prepared to supports DICOM applications particularities, this increases the validate of this proposes. II.

PROBLEM DESCRIPTION

The DICOM protocol [4] establishes a sort of necessary characteristics to allow a system to work with medical data like data structures, storage strategies and communication way. However, the DICOM standard is a theoretical reference to DICOM compliant systems development, setting on almost no implementation issues and there are gaps over situations that could arise after the development step like maintenance and reconfiguration changes. The most basic of them is the updating of configuration information in remote hosts, called in DICOM jargon of RemoteAE – Remote Application Entity. The reconfiguration problem can be small and easily manageable in small environments like radiological centers with feel host, where a set of remote hosts communicate with a central image server where a person can easily be delegated to

go from host to host manually reconfiguring the necessary parameters. However, the problem grows exponentially in larger networks, like the Telemedicine Network of Santa Catarina State –Brazil– having hosts geographically distributed over the entire state. Any configuration change will unchain a considerable number of phone calls, e-mails to notify the responsible technical team from all health centers to perform the necessary changes. Larger health centers have a sort of different DICOM access systems, like workstations to perform radiological findings, palm tops to medical/nurse patient bed side care attendance and different servers, that in a case where DICOM communication parameters needs reconfiguration, the task to stop such systems could be prohibitive. In some cases, the hosts operate without a technical team nearby like in small health centers, creating the necessity of human translocation or requiring remote reconfiguration, bringing up problems of network accessibility. Considering such scenario the existence of a automatic way to perform reconfiguration of DICOM communication parameters on the fly in remotely distributed host show up as a viable approach to solve this sort of problem. III.

The Aglet objects can be started, interrupted or be dispatched to a specific remote place through Internet. An example of such usage is to resume the execution of a given agent started in a host A in another host B. To do that, all execution data must be contextualized as well as the own code (bite code in Java). To decide the transfer of a given execution context, there is no need to trigger a external event, been possible an agent internal event decide to do so. It’s yet possible an agent to perform communication with other agents, previously known or not, using to do that the message exchange mechanism defined on the toolkit. The Aglets structure consists of two distinct parts, core and proxy, Fig. 1. The core is the heart of the aglet and contains all of the aglet's internal variables and methods. It provides interfaces through which the aglet may communicate with its environment [9]. The proxy part has responsibility of encapsulate the aglet core, providing access to private methods and variables. Moreover, Aglets contains an ID and an itinerary, to mobile agents.

MATERIAL

To develop the necessary agents, Mastar and Slave, to solve reconfiguration on the fly of DICOM communication parameters was choused the Java Aglets Toolkit [5] as development platform as well as Agents management environment. To perform the usability tests was choused the Telemedicine Network of Santa Catarina State – Brazil – as agents execution environment with twenty-six (26) DICOM compliant nodes and five (5) reconfigurable attributes, and so, to validate the proposed reconfiguration procedure. The DICOM compliant software running on the host was choused amongst the available Cyclops DICOM compliant software, the Cyclops Medical Station [REF] as diagnosis clients and Cyclops DCM Sever [REF] as DICOM Image Server. A. Aglets Aglets is a mobile agents platform completely implemented using Java technology created by IBM [REF] Research Lab – Tokio – and originally idealized to run over Java 1.1 version. It becomes open source on version 2.0, hoping to interest more people to work on the adaptation to further Java releases. Actually, the Aglets toolkit is on version 2.0.2 and can be downloaded in [8]. This platform for development of mobile agents propose some Java classes with mobility capabilities between different hosts and possibility to work in different operating systems architectures, a desirable feature since DICOM software like DB Image Servers [REF], DICOM Diagnostic Viewer Clients [REF], and imaging equipments like tomography, Magnetic Resonance Imaging, ultrasounds, ECG, and EEG to cite just a few, can run in different operating systems. The toolkit has yet a library to development and construction of agents from scratch.

Fig. 1 – Aglets Structure [9].

Delineating a comparative between aglets and applets, the last one has the characteristic of application state transmission and works only from server to client. On the other hand, Aglets can move from a host to another, allowing call backs to the original host [REF]. However, is important to each remote host have a security authentication based in communication reliance. Thereby, is necessary to publish the files “.java.policy” and “.keystore” on home server application directory. These files are created to manage the user names and passwords, and are required on server startup. Another important aspect are the data structures used within the agent where an aglet to be able to transfer from a host to another must only use classes and other internal serialize structures since it will be translated in a sequential byte structure to travel over the network. B. Telemedicine Network of Santa Catarina State -RCT The Telemedicine Network of Santa Catarina State is a project where a number of regional health centers geographically distributed in 6 main regions at Santa Catarina State – Brazil – are logically integrated over the internet to perform heath care and medical image exam diagnosis on distance allowing to specialist physicians from different areas to work in any place, facilitating the process of exam regulation and offering virtual rooms to group of physicians meet each other and discuss difficult cases. The main reason of

such project is to solve the problem of specialist lack in inland regions, allowing specialist from the main state cities to perform de needed findings. Given the characteristic of sparse geographical distribution of the health care centers over the State, this environment shows up as a perfect place to study the viability of reconfiguration systems using mobile agents. IV. METHODS

The presented proposal aims to supply the reconfiguration needs of DICOM compliant systems interconnected in medium and large medical data communication networks using the Java agents’ technology combining both mobile and stationary agents to perform de dynamic reconfiguration task. Agents are organized in Master Agents (stationary agents) and Slave Agents (mobile agents), and they are intended to live in an environment similar to one depicted in Fig. 2.

A. Master Agents In this proposal, the Master Agents are the stationary ones, localized in every DICOM network communication hosts. This agent’s group is responsible to execute the verification of configuration changes in relevant parameters needed to establish DICOM communication between applications that uses this protocol. It verifies the configuration file changes and is responsible to manage the creation of Slave Agents. The Master Agent startup must take place together with the host activation either with active DICOM software running or not, granting that any change occurred in remote hosts will be replicated locally, since the configuration file is completely dissociated from the DICOM application.

Fig. 2 – Agent Network Distribution

The subdivision between master and slaves agents, focus the promotion of: • Accelerate the execution of verification changes task on the configuration “.xml” file on a given host and reply changes on the other remote hosts. • Don’t overload the information traffic on the network, since mobile agents are specialized on the task of configuration file actualization, what implies in be able to have less information to transport from a host to another. • Minimize the possibility of task incompletion delegated to agents by network communication failures, inactive remote host and any other network related reason. The used resources by the agents are two well formatted files in xml standard. These files are one Configuration File, that stores all DICOM Application configurations, and one Log File, that store the agents tasks historic to eventual analyze of its performance or others pertinent verifications. In these next subsections will be presents the execution flow of both agent’s and the resources structures with the goals of allows the most agreement about the purpose of this work.

Fig. 3: Master Agent Fluxogram.

The schematic execution line of Master Agents, Fig. 3, can be understood if we attempt to: • On creation time the agent start the configuration file scan, searching for possible changes in comparison with the previous state, that is internally save within the agent. The watched parameter is the configuration file time stamp;

• If no changes are detected in the watched configuration attributes, it follows the verification process from time to time laying in a stand by state and reactivated by a given rechecking time. This execution strategy allows that becomes needed low need of processor time to perform the verification task; • If any change are detected on the watched configuration parameters, the agent starts the verification of which ones was changed, since the configuration file is constituted by different parameter sessions with possible unchanged attributes. In other words, this step is concerned in identify exactly which attributes changed performing a file parsing. The watched attributes of interest are the ones used by local entities, marked on the XML file by tag , used by remote application entities, marked by tag and that one used by communication Upper Layer, or DICOM communication server layer, marked by tag ; • It’s possible that a change on the configuration file doesn’t affect any crucial communication parameter since configuration file is concerned also about other aspects of DICOM application configuration. In such cases any remote changes are scheduled and the Agent turns back to time stamp verification state. • If any pertinent configuration communication parameter change is verified, the agent update it’s internal state with the changed configuration parameters, creates a list of remote hosts that has some kind of interaction with the local entity. If it was unable to create the remote host’s list, it turn back to time stamp verification task; • The next step is to create a Slave Agent to any host present on the related remote host’s list and log on the local log file the creation of these agents; • After Slave Agents creation, the Master Agents goes to time stamp verification step again. B. Slave Agents Slave Agents are mobile agents that are intended to propagate the changes occurred in a DICOM configuration file watched in a given HOST to all other connected hosts. The creation of this set of agents is relied to a given Master Agent that internally perform de task without the need of human intervention. The execution flow of Slave Agents presented in Fig. 4, follows: • After creation, the Slave Agent proceeds performing a peek test on the target remote host to which it must be sent. If there is no remote host answer, it’s possible that it is inactive or inaccessible. To assure that, a number of trials are performed, and with no positive answer, the Slave agent becomes dormant being awakened from time to time, until it be able to obtain a valid answer. All these trials are properly logged on local log file; • When a positive answer are received, the slave agent interrupt the execution on local host and transfer itself to the target remote host, where it will perform the reconfiguration task; • Once on target host, the Slave Agent check if it has writing permission over the configuration file;

Fig. 4: Slave Agent Fluxogram.

• If hasn’t permission to read and write the configuration file, the agent will return to verification permission state until either granted this access level; • When the agent gets permission to write in configuration file, its will proceed with this file update task execution. At this moment, is important explain that is necessary to plans two distinct types of Slave Agents, each one is specialized in a specific task. The first type consists in a parameters update agent, its task is only update the origin host relatives configuration file parameters on a RemoteAE. The second one will be responsible to remove the references of its LocalAE in the RemoteAE remotesAEs list in the case of this RemoteAE either removed in its LocalAE remotesAEs list. But, the both Slave Agents types have the same execution flux; • After execute the update configuration file task, the agent verify the permission to write in the log file of the execution task host. In negative cases the agent will proceed the write authorization again still obtain its. • If obtains authorization to write in log file, the agent proceed with the executed task registers to permits the future analyze of the realized events in configuration file of that DICOM host;

• After register the executed task, the agent verifies the connection between its actual host and origin host. If don’t obtain an successful connection answer, its will continues in this verification state; • When the agent gets the positive connection answer its interrupts the execution process and goes back to its origin host. Arriving in its LocalAE the agents restart the execution process verifying the write permission in the local Log file. In negative cases its will continue waiting and verifying the permission; • After obtains the write file authorization, the agent register in this file the its return to the origin host; • With its returns registered in local log file, the agent ends its execution process. C. Resources During its task execution the agents, Master and Slave, uses two distinct resources, .xml files: the DICOM configuration file, that contain the DICOM application entity information, and the Log file, this ones is used to registry all agents operations in configuration file and the agents return to origin host after its successful task execution. Tab. 1: Configuration File. 1 2 3 4007 4 5 6 7 tibia 8 tibia 9 tibia.telemedicina.ufsc.br 10 #[150 162 67 28] 11 12 13 14 15 osso 16 osso 17 osso.telemedicina.ufsc.br 18 #[150 162 67 171] 19 4001 20 21 22 nuca 23 nuca 24 nuca.telemedicina.ufsc.br 25 #[150 162 67 10] 26 4007 27 28 29

A DICOM Application Entities configuration file has the information about all the necessary characteristics to maintenance the functional state in the application entity, however, in this work will be used only the characteristics that contains information about the DICOM communication establishment process. The Tab. 1 presents the excellent configuration characteristics list. These will be analyzed for Master and Slave agents during its task execution process. This

example was extracted of an real used application entity configuration file. These characteristics can be described as: • ApplicationEntities – name: this attribute store the application entity names that uses this configuration file; • upperLayer – port: this tag relates the connection port used to communicate with this application entity; • localAE – dicom – AETitle: this one store the DICOM application entity unique identification in its DICOM communication network; • localAE – dicom – label: store the entity description that will be presented when any application relates this application entity; • localAE – dicom – host: this tag contains the host name of the application entity execution machine; • localAE – dicom – address: this one contains the IP address of the application execution machine; • remoteAE – dicom – AETitle: store the remote DICOM applicaton entity unique identification in communication network; • remoteAE – dicom – label: this one store the remote application entity description; • remoteAE – dicom – host: contains the remote machine host name; • remoteAE – dicom – address: contains the remote application entity execution machine IP address; Must be remembered that one configuration file can contains more than one local application entity characteristics descriptions. In same mode, can exist more than one reference to remotes application entities that are qualified to communicate with the local entity owner of the configuration file. Tab. 2: Log File. 1 2 3 osso 4 tibia 5 update 6 07/10/2005 7 09:45:21 8 9 10 tibia 11 nuca 12 remove 13 07/10/2005 14 10:57:32 15 16 17 tibia 18 osso 19 createSlave 20 08/10/2005 21 16:09:58 22 23 24 tibia 25 osso 26 returnSlave 27 08/10/2005 28 16:10:03 29 30

Tab. 3: Task description: update port number in Application Entity = "NUCA". This host is a mainly DICOM Server of RCT.

3.800

DICOM scanner

2.150

2,26 1,68

1,57

torax.telemedicina.ufsc.br

workstation

8

umbigo

umbigo.telemedicina.ufsc.br

workstation

8

menisco

menisco.telemedicina.ufsc.br

workstation

8

cerebro

cerebro.telemedicina.ufsc.br

secundary server

550.000

O processo de validação da proposta foi realizado utilizando como parâmetro de análise de tempo decorrido o timestamp impresso pelo Master Agent no arquivo de log da entidade de aplicação local ao criar os Slave Agents responsáveis por

a

1

torax

1,46

bo ca

backup server

ne l

coluna.telemedicina.ufsc.br

pe

2.150

coluna

ca

workstation

a

menisco.telemedicina.ufsc.br

bu l

2.150

menisco

so

2.150

DICOM printer

os

workstation

boca.telemedicina.ufsc.br

an di

canela.telemedicina.ufsc.br

boca

1,73

m

canela

1,98 1,65

1,34

1,20

an io

2.150

ia

workstation

cr

pe.telemedicina.ufsc.br

tib

pe

1,84

o

workstation

mandibula.telemedicina.ufsc.br

re br

osso.telemedicina.ufsc.br

mandibula

ce

osso

2,85 2,49

o

3.800

bi g

3.800

workstation

en is co

workstation

cranio.telemedicina.ufsc.br

m

tibia.telemedicina.ufsc.br

cranio

ax

tibia

3,72

um

Host Description

a

Host Name

to r

RemoteAETitle

Time to RCT Server RemoteAE Update

Distance to LocalAE (m)

lu n

Com o objetivo de validar e comprovar a utilidade e performance da proposta desenvolvida neste trabalho foram realizados testes de utilização dos agentes durante o processo de atualização dos arquivos de configuração de alguns dos hosts que fazem parte da RCT. Como citado em seções anteriores, foram utilizados ao todo 28 máquinas distribuídas entre servidores de imagens, estações de trabalho, impressoras, scanners e servidores de backup, geograficamente separados. Para sintetizar as informações apresentadas neste artigo, serão apresentados apenas os resultados obtidos durante a atualização do arquivo de configuração do servidor de imagens principal da RCT, localizado na cidade de Florianópolis-SC, Tab. 3.

co

RESULTS & CONCLUSIONS

en is co

V.

realizar a tarefa de atualização dos arquivos de configuração e, o timestamp registrado pelos Slave Agents ao retornarem ao seu host de origem, após terem executado sua tarefa no host remoto. Nos resultados apresentados aqui é encontrado um ambiente ótimo para realização do processo de atualização, o que implica nos baixos valores de tempo decorrido para a execução da tarefa. Porém, não se deve deixar de considerar que esse tempo para execução pode aumentar consideravelmente caso o host destino esteja inativo, ou mesmo, caso o agent não possua permissão imediata para escrita nos arquivos de configuração e log remotos, além do tempo gasto para obtenção da permissão de escrita no arquivo de log do host de origem. A inatividade do host remoto ou a falta de permissão de escrita nos arquivos do host remoto ou no host de origem, não inviabilizam a execução da tarefa por parte dos agentes, visto que o fluxograma apresentado anteriormente prevê que os agentes devem permanecer no estado de teste de uma determinada condição ate que uma posição favorável seja obtida. Um gráfico contendo o tempo, em segundos, decorrido durante o processo de atualização de cada um dos hosts cadastrados como RemoteAE no arquivo de configurações do servidor de imagens principal da RCT é apresentado na Fig. 5. Observando esses valores pode-se concluir que utilizando a proposta de utilização de agentes para reconfiguração dinâmica dos arquivos de configuração das entidades de aplicação de uma rede de comunicação DICOM, apresentada por este trabalho, demanda um tempo de atualização dos parâmetros utilizados na comunicação inúmeras vezes menor do que uma atualização manual desses arquivos. Além da diminuição do custo de tempo decorrido para atualização, deve-se ainda considerar que com a atualização manual não se pode descartar a existência de falhas humanas durante a execução da tarefa, o que pode ocasionar maior custo de tempo e demais atributos que devem ser considerados quando se utiliza mão-de-obra humana (custo financeiro, físico, etc.).

m

Na Tab. 2 são apresentadas a estrutura do arquivo de log de eventos que será utilizado por ambos os agentes. A exemplo do arquivo de configurações, o arquivo de log apresentado foi extraído de um arquivo de configurações utilizado por uma entidade de aplicação ativa. As informações contidas no arquivo se referem a: • ApplicationEntities – name: armazena o nome da entidade de aplicação a qual se utiliza desse arquivo de configurações; • event – localAE: armazena o nome da entidade de aplicação de origem do agente que está procedendo com o registro de log; • event – remoteAE: armazena o nome da entidade de aplicação remota para a qual o agente foi designado; • event – task: armazena o registro da tarefa que foi realizada pelo agente; • event – date: armazena a data na qual o agente realizou a tarefa informada no task; • event – time: armazena o horário da realização da tarefa.

Fig. 5: Task description: update port number in Application Entity = "NUCA". This host is a mainly DICOM Server of RCT.

VI. FUTURE WORKS

• desenvolvimento de interface gráfica para realização de alterações de configuração e integrar essa interface com os sistema de agentes; VII. ACKNOWLEDGMENTS

Pessoal do cylops Patroas Pessoal da SES VIII. REFERENCES [1]

FRANKLIN , S., GRAESSER, A. Is it an Agent, or just a Program?: A Taxonomy for Autonomous Agents. Proceedings of the Third International Workshop on Agent Theories, Architectures, and Languages, Springer-Verlag, 1996.

[2]

DELLANI, Paulo - Desenvolvimento de um Servidor de Imagens Médicas Digitais no Padrão Dicom. Dissertação de Mestrado – 2001.

[3]

DICOM Official Website. Available in: accessed in October, 10, 2005.

[4]

_______. Digital Imaging and Communications in Medicine (DICOM) Part 8: Network Communication Support for Message Exchange. Virginia, 2000. Available in: . Accessed in October 10, 2005.

[5]

FERRARI, Luca. The Aglets 2.0.2 User’s Manual. April 06, 2004. Available in: . Accessed in October 10, 2005.

[6]

VENNERS, Bill. The Architecture of Aglets – The Inner Workings of an Agent Technology. Published in JavaWorld, April 1997. Available in: . Accessed in October 10, 2005.

[7]

OYAMADA, Marcio Seiji, ITO, Sergio Akira. Aglets: Agentes Móveis em Java. Curso de Pós-Graduação em Ciência da Computação. Universidade Federal do Rio Grande do Sul. Porto Alegre, RS. July, 1998.

[8]

_______. Aglets Web Site. Available in: http://aglets.sourceforge.net. Accessed in October 11, 2005.

[9]

CLEMENTS, P.E., et al. Aglets Enabling the Virtual Enterprise. First International Conference on Managing Enterprises – Stakeholders, Engineering, Logistics and Achievement - ME-SELA’97. Loughborough, UK. July, 1997.

[10]

ABDALA, D. D., Cyclops Personal – Uma Ferramenta para Gerenciamento e Visualização de Imagens Médicas no Padrão DICOM 3.0 (Trabalho de conclusão de curso – Ciências da Computação), Universidade Federal de Santa Catarina, Santa Catarina.

[11]

BAUER, Michael A., et al. Services Supporting Management of Distributed Applications and Systems. IBM Systems Journal, 36(4). 1997.

[12]

KATCHABAW, Michael J. et al. Making Distributed Applications Manageable Through Instrumentation. The Journal of Systems and Software, 45(2). 1999.

[13]

FELFERNIG, Alexander. Distributed Configuration as Distributed Dynamic Constraint Satisfaction. Lecture Notes in Computer Science, 2070. 2001.

[14]

F. Cristian. Automatic reconfiguration in the presence of failures. IEE Software Engineering Journal, 8(2), March 1993.

[15]

M. Endler. A model for distributed management of dynamic changes. In Fourth IFIP/IEEE International Workshop on Distributed Systems: Operations and Management DSOM'93. Long Branch, New Jersey, October, 1993.