The URC runs on a client machine as a Windows executable and communicates with the Target device residing on the RERC-AMI web site. The URC resides on a local computer and attempts to invoke the target residing on a local or remote host computer with a HTTP protocol. Both programs are coded in C# on WinXP platform but the target device uses ASP.NET for its communication and simulation protocol.
The target device can also be programmed to work on the client machine (where the URC resides) on its localhost website with the help of Internet Information Server (IIS).
The communication between URC and target happens via a request-acknowledgement method. The ANSI/INCITS standard files always reside on the target (Web) side. Depending on the number of files available, when queried the target informs the URC of the available devices and the URC builds an interface for the selected device.
An instance of the data being transferred on this communication can optionally be saved on either target or URC side and the instance file is usually named after the username who logs in. If no username is given, a guest user is assumed. Whether a user logs in with a valid username or wants to test the system as a guest, an instance file will be constructed by the Target when one is not available. But if an instance file already exists, URC gives the option to the user to load the instance file or start a fresh instance of the Target. It should be mentioned here that in this simulation,
A simple principle is used to implement communication between the URC and the Target. When the URC is ready, it allows the user to login as a registered or guest user where the user can select his preferences and save them. In the next step when the URC is ready to read/control a Target device, it sends a query to the target HTTP location (local or remote). The Web site informs the URC a list of Target devices that are available, looking for a set of four ANSI/INCITS files (Socket, Presentation, RDF and Target Description) for a device to be made available to URC. The set of four files follow a standard format in name and content. The list is sent back to the URC as a concatenated string. It is the job of URC to split the long string into individual device names and show them as a list of available devices to the user in the format the user prefers. User is then allowed to select a target device for controlling.
Once a device is selected by the user, the URC sends query again to the target asking it to open, display, close and do many other functions. Once a device is selected and communication established, everything the URC sends is received by the Target and the instance of the Target is updated immediately. When the URC does not send a query, the Target goes on working in its programmed mode, updating itself automatically. Every time the target is queried, it gives an acknowledgement to URC and gives status of “all” variables and other entities. These status signals can be populated by URC on its screens as appropriate. URC can also program a thread to invoke or update the target at regular intervals without user intervention.
Of note is the make the simulation more realistic, the web software includes internal algorithms that vary sensor signals such as heart rate or blood pressure is a reasonably physiologic manner. These are then faithfully updated on-the-fly on the MedURC interface generator, communicating only through the open socket between the MedURC executable running in Windows on the local computer and the Web site that includes the program that implements an instance of the target and also houses the standards-compliant files.