From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Development Best Practices Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

Developing a Mobile Agent System Using LabVIEW Object-Oriented Programming

Introduction

A mobile agent [1] is a piece of software that autonomously performs tasks, interacts with its environment, and moves between hosts. In contrast to conventional object-oriented languages, such as ANSI C++ or Java, objects are not maintained as entities but as passive data that follows the dataflow paradigm of LabVIEW. The HGF base class library [2] provides LabVIEW OOP classes that implement important design patterns with respect to dataflow and the ability to treat LabVIEW objects as entities. Classes with passive data only (HGF_Visitable) are strictly distinguished from classes activating them (HGF_ThreadPool). We implemented a stationary device agent as an example to demonstrate the feasibility. This application describes the extension of this concept towards mobile agents.

HGF Basic Class Library

You can use the HGF basic class library to implement several design patterns— such as factory, threadPool, and visitor, and an object-oriented event mechanism—that can use LabVIEW OOP objects by following the data flow. The factory pattern programmatically creates initialized objects. In createObjekt.vi, a standard object of the desired class is created and subsequently initialized by the dynamic dispatch initialize.vi. Every HGF factory child class can overwrite this to initialize its own attributes that are transferred as variant-attributes.

The threadPool starts using VI-server method threads (HGF_Worker). Those workers activate HGF_Tasks by calling up the task’s dynamic dispatch action.vi. Using the event mechanism (HGF_Event), the software can synchronize processes and transmit objects across process borders. The visitor pattern manipulates objects and the object wire is not directly accessible. The HGF_Visitable accepts (accept.vi) an HGF_Visitor and calls up its visit.vi with itself as the parameter. HGF_Visitor child classes call up the public methods of the HGF_Visitable child classes in the corresponding override VIs.

Agent-Based Auxiliary Classes

As part of a thesis [4], a prototype for a mobile agent system was developed, which extends the HGF basic class library. The basic class for mobile agents is MoAgSy_Agent and specialized HGF_Visitable. It accepts MoAgSy_Visitor child classes, which is a differentiation of HGF_Visitor. Those agents are passive data objects activated by using the threadPool and a special task, MoAgSy_Engine. MoAgSy_Visitor objects determine when they spring into action and which public methods to perform.

The HGF_GPG class works with the GnuPG [3] command line functions to programmatically provide encryption and signature functions of GnuPG in LabVIEW. The HGF_SV library complements the basic class system by classes that include event mechanisms for the shared variables. LabVIEW alone does not programmatically create and destruct environment variables. This functionality is supplemented by the LabVIEW Datalogging and Supervisory Control (DSC) Module and integrated by the HGF_DSC class library.

Mobile Agent System Prototype

A host application serves as a local interface for the agents. This interface consists of a host class that provides the required management data with its attributes and a runHost.vi that provides the GUI, as well as the required infrastructure to receive and activate agents. For the communication in this prototype, we used environmental variables.

A ThreadPool starts two workers. Those subsequently activate one task each that in turn encapsulate an HGF_DSCManager or HGF_DSCMonitor. Those differentiate the HGF_Visitable class. Using the event mechanism, the tasks wait in the queue for appropriate visitors to create the required shared variables with the manager and register them with the monitor. The monitor reacts to changes from the environment variables and sends the corresponding visitors, which carry the new value in their attributes (in this case a message), to the host or the addressed agent.

A message class (MoAgSy_Message), the objects of which can contain text messages as well as visitor or agent objects in their attributes, serves as the message container for the communication within the agent system. The message-objects are turned into a string using the Flatten to String VI, which subsequently is transferred to a shared variable. The event registered with the monitor delivers the string back. Afterward, the message-object is reconstructed using Unflatten From String VI. There is an additional option to asymmetrically encrypt the string by using the HGF_GPG class method and therefore only allow the desired destination the decryption, because private attributes can be visible for anyone if using the flatten to and unflatten from string VIs in connection with the public transport channel of the environment variable.

Transmitting the agents between hosts and client applications requires the exchange of several messages. First, the authorization on the destination host to activate the agent needs to be verified by a positive list. If this is authorized, the corresponding classes load from a local file into the memory. With this mechanism, previously unknown agent classes can load in the runtime system. If successful, the agent is encrypted, transmitted, and activated.

An agent is activated by the host creating a new engine task (see Figure 1) using the MoAgSy_Factory, which contains the agent in the form of an initialization parameter, and transferring it to a threadPool.

iamgea.png
Figure 1: Dynamic Dispatch Action VI of Engine Tasks

The engine task drives a synchronized state machine (see Figure 2) implemented using a statechart module. For the initial transition, the agent transfers into the state machine’s internal attributes. The state machine initializes the agent’s communication interface, where a new environment variable is created and an event for this variable is registered.

imageb.png

Figure 2: Agent State of Machine State Diagram

Afterward, the state machine switches into the waiting status and the engine waits for incoming message-objects. Incoming messages trigger a state change. First, recipient and type of message are verified. Text messages and agents both result in a call up of a dynamic dispatch VI, in which specialized agent class reactions are implemented on the corresponding message. Visitors in the visitor state (see Figure 3) are applied to the agent. The transfer of a traveling visitor, MoAgSy_Visitor_travel, triggers the migration to another host.

imagec.png

Figure 3: State Visitor Input Activities of Agent State Machine

To allow both reactive and autonomous acting agents, the agent basic class has a timeout-visitor. After a certain period of time, This timeout-visitor is transferred by the event mechanism of the engine tasks to the state machine and can therefore trigger a reoccurring action of the agent. Furthermore, the agent can also send an asynchronous message to itself.

By implementing specialized agents and corresponding visitors, we can expand the mobile agent system at any time, and in turn we can create custom-designed applications.

A VI independent from the host system is required to initialize at least the first agent and send it to another host. While the initialization can be individually implemented for each agent class, the transfer to the host using startAgent.vi is provided by the factory of the mobile agent system.

Conclusion

Using simple agents, we demonstrated and proved the functionality of basic classes and the host system. HGF basic classes form a supported basis for scalable, event-driven, and distributed object-oriented projects in LabVIEW. Next, we need to research and test the performance and stability of the mobile agent system using a larger application. We also need to develop further additives to implement agent libraries; simplify error troubleshooting; and manage active as well as persistent agents.

References

[1]D.Lange M.Oshima "Programming And Deploying Java Mobile Agents With Aglets", Addison Wesley, ISBN 0-201-32582-9

[2]H.Brand, D.Beck, F.Berck "Machbarkeitsstudie: LVOOP basiertes Agenten-System", erschienen in "Virtuelle Instrumente in der Praxis - Begleitband zum Kongress VIP 2009", Rahman Jamal, Hans Jascchinski (Hrsg.), Heidelberg: Hüthig Verlag, 2009

[3]http://www.gnupg.org/

[4]F.Berck "Prototyp für ein mobiles Agentensystem in NI LabVIEW", Hochschule Darmstadt University of Applied Science, FB EIT, 2010, http://wiki.gsi.de/pub/NIUser/LVMobileAgentSystem/DiplomarbeitFrederikBerck.pdf

This content was written by Frederik Berck and Dr. Holger Brand, GSI Helmholtz Center for Heavy Ion Research GmbH, Darmstadt.

Contributors