Product Catalog
RTU and Datalogger
|
|
Product Catalog |
|
|
|
q |
|
|
|
|
|
|
|
|
|
|
RemoteLog Usage Tips
Application Ideas
The "Client" Advantage
Is RemoteLog a Client or a Server?
Inexpensive Ethernet Connections
Reporting on Exception (Alarm Reporting Techniques)
Security Topics
Secure Path Through the Firewall
Addressing Client Security Concerns
See Also: Low Power RemoteLog Special Features
The discrete inputs on a RemoteLog may be used as pulse counter inputs. If you are reading pulses from a mechanical contact, we suggest selecting "Slow Filtering" to eliminate extra counts being registered due to contact bounce. If you have pulses occurring faster than 100 pulses per second, use the first discrete channel, which accepts pulses up to 50 KHz. As an option, you can assign two analog registers to each counter so that 32 bit results may be reported (maximum count value of greater than 2,000,000,000).
A common RemoteLog application is measurement of power demand. Typically, pulses from a power meter, indicating Kilowatt-Hours are applied to a discrete input channel. Simply configure that input for Pulse Rate Mode with a measurement period equal to the power demand interval of interest (typically five or fifteen minutes). RemoteLog will report the accumulated count for the interval in the corresponding analog input register. Datalogging can be synchronized to capture records at the end of the count period to accurately capture the power demand measurement(s). The count values will be retained in battery-backed memory to reduce data loss in the event of power failures.
Up to 32 prioritized alarm conditions can be configured. Each alarm is configurable to be triggered by an ON or OFF discrete input or a high or low analog input with a configurable deadband. RemoteLog can be configured to transmit an ASCII message, I/O register values or optional datalog records when an alarm condition occurs. See RemoteLog Alarm Reporting Techniques for more information.
RemoteLog has the ability to do simple control based upon user-configured alarms. This is done by configuring an alarm condition that energizes a discrete output when an analog input exceeds a predetermined value, or when a discrete input changes state. Here are some examples of simple control:
On/Off control to fill a tank, based upon a threshold (analog input) or count value
You can use RemoteLog to fill a tank, based upon a tank level sensor such as a switch or float.
Load shedding based upon power demand
Use a rate counter (count pulses for a period of time) to monitor demand. This analog input can be used within a RemoteLog Alarm to turn on a discrete output if the demand (counts in x minutes) exceeds the alarm threshold.
The term "server" suggests a large or complex central store of data, but this is not necessarily the case. A server is an object (software or hardware with embedded software) that is available to supply information upon request. On the Internet, many clients (users) can make requests from a server (website). There is, however, another scenario of great interest. By this same definition, a simple I/O module is a data server because it is a servant (slave) that waits for, then responds to, requests for I/O status from a master (otherwise known as a client because it makes requests of the servers). Accordingly, in a simple control system, the controller (PLC, DCS or RTU) is the master device and is the client. It polls the I/O modules (servers) for information. It is perhaps a bit strange to discover that the client can be the smarter device and that there can be many servers and as few as one client in a system.
It can be either or both. The choice is yours. A look at the alternatives may help you decide which is best for your system. RemoteLog can simultaneously act as a master and as a slave using the advanced SIXNET "I/O for Windows" protocol. This secure communications method uses packets to ensure the integrity of the data transmissions. Both command and reply messages can travel simultaneously over the same channel. The result is that the remote access port (the telephone modem, wireless modem or Ethernet port) is always listening for incoming messages and can report exceptions as they occur. With the creation of a simple driver, your server can receive these messages, as well as scheduled transmissions such as data transfers. RemoteLog gives you a unique opportunity to be a client (master) or server (slave), or if you wish both as the same time!
If RemoteLog is setup as a server, it will be necessary to assign a static (fixed) IP address to the device so that clients looking for information can find it on the Internet. Unfortunately, IP addresses are scarce commodities. Assuming that you can find availability, high costs for IP address assignment can be encountered in the form of administrative time from the local network administrator, or from commercial broadband service that includes static IP addresses (sometimes as high as US$400 per month).
The alternative is to connect RemoteLog as a client, so that it is equivalent to a browser to the network. IP addresses can be borrowed using DHCP, often with no cost for the installation (because the site already has a contract for many Internet connections of this type). This type of connection will also benefit from an Easy connection through the local firewall and the advantages of being able to Report on Exception.
Often, Remote Terminal Units in distributed systems are configured for periodic and usually infrequent connections to the central host site. This is particularly true in large systems using telephone and/or radio links where the considerations of polling time, communications bandwidth and sometimes cost are significant factors. If everything is running smoothly, this background reporting of status and uploading of historical data files is adequate for the application. The problem is, timely reports of alarm conditions are often required. Waiting for hours or the end of the day is not acceptable. The solution is to give the RTU "Report on Exception" capabilities so that it can report alarms on an unsolicited basis. For the RTU to "call in" it must become the client (master) and the host must be the server (slave). This is exactly the action a RemoteLog will take. RemoteLog can be configured such that when an alarm occurs, RemoteLog will send an ASCII message describing the condition, or it will send I/O register data. Please note that a "slave" driver is needed on the receiving end for either type of transmission. For I/O register data, there are two off-the-shelf choices: the SIXNET Control Room IOmap (included in the optional SCS feature set of the SIXNET I/O Tool Kit) or a SIXNET gateway configured as a Master Terminal Unit. For alarm messages, a simple Windows slave driver will be needed.
Many times we have seen plans to include a web server in in-plant equipment scuttled by serious security issues. What is often overlooked is that for a person outside the plant to use a browser to interrogate a web server inside the plant, they must cross the firewall. More often than not, an external third party will not be granted permission (if it is even possible) to access data from within the plant over the Ethernet (intranet) network structure.
The generally preferred alternative is to configure a RemoteLog as a client that initiates the conversation, in the same manner as a user addressing a web site from a standard web browser. In this manner, the client RemoteLog within the plant sends messages out through the firewall. The firewall software, monitoring the IP address in the outgoing messages, then allows that address to respond back to the same client. This standard security technique is similar in principal to a dial back system that only allows data to be transferred after the source of the request has been confirmed.
The question we have been asked is: can RemoteLog pose a security risk by providing access to the network from outside sources? The answer is NO. RemoteLog is deliberately designed not to forward messages and to not function as a gateway. It does not support ftp or telnet and does not perform protocol conversions. It does not contain Windows software. In summary, it cannot serve as a bridge into your network.
RemoteLog has an optional message validation feature that ensures that a remote access is only granted to authorized users. A 32-bit security code can be configured into the RemoteLog that must be matched to two analog register values in an incoming message before the RemoteLog will respond to data requests. By using standard I/O registers as a security device, standard I/O drivers can be used to send validated commands.
