Attributes to Configure in the Comm-Port Point

Attribute Name Description
nettop file This attribute specifies the location of the nettop file. This attribute can be of any of the rtBytes data element types.
journal file This attribute specifies the location of the journal file. This attribute can be of any of the rtBytes data element types.
process name Specifies the RTAP name that this scan task will run as. This is useful for debugging purposes when there are more than one BSAP communication port.
ip mode

This attribute indicates whether this is an IP connection to the RTU or a serial connection. Valid values are:

0 = Serial RS-232

1 = IP

2 = Serial VSAT Slave

3 = Serial via TCP/IP Terminal Server

If a terminal server is used, the "ip info" values below will be used to open a TCP/IP connection.
ip info

This table contains information for the IP connection to the RTU:

Field Number Field Name DE Type Possible Values
0 enabled rtLOGICAL 0=disabled, 1=enabled
1 reserved1 rtUINT8
2 host rtBYTES20 valid host name
3 service rtBYTES20 valid service name
4 ts service rtBYTES20 valid service name for timesync port

Where:

Field Name Description
enabled Indicates whether the current entry is enabled or not. If this entry is disabled (zero) and a failover to this entry is performed, the failover will fail.
host This is the name of an entry in the /etc/hosts file.
service This is the name of an entry in the /etc/services file.
ts service This is the name of an entry in the /etc/services file for the timesync port (defaults to 1235 if empty).
ip index This attribute is an index into the "ip info" table for the current IP based connection.
comm info

This table contains the following information:

Field Number Field Name DE Type Possible Values
0 key up delay rtINT16 -32,767 to +32,767 (msec)
1 key down delay rtINT16 0 to 32,767 (msec)
2 channel clear delay rtUINT16 0 to 65,535 (msec)
3 turn around delay rtUINT16 0 to 65,535 (msec)

Where:

Field Name Description
key up delay The desired time to wait (in milliseconds) after asserting RTS (request to send), before sending data. If the value is 0 (zero), no RTS is asserted. If the value is greater than zero, the host will wait that number of milliseconds, after asserting RTS, before beginning transmission, regardless of the value of CTS (clear to send). If the value is less than zero, the host will wait until either the CTS signal is received, or the specified number of milliseconds has expired before transmitting. If the specified time expires before CTS is received, the transmission fails.
key down delay The desired time to wait (in milliseconds) after the last data character has been sent, before resetting RTS (request to send). This should be a positive number; if the value is negative, the minimum time of rtNap() is used (see Section 3 of the RTAP Reference Manual for details).
channel clear delay The desired time to wait (in milliseconds) for the DCD (data carrier detect) line to clear before asserting RTS. If this value is zero, the DCD line will be ignored. If the value is positive, the host will wait the specified number of milliseconds for the DCD to clear before asserting RTS. If the DCD line has not cleared before the specified time has expired, the transmission fails.
turn around delay The desired time to wait (in milliseconds) after data has been transmitted in either direction, before a transmission in the opposite direction is initiated. This time must be at least the sum of the "channel clear delay", "key up delay" and "key down delay".
rs232 info

This table contains the following information:

Field Number Field Name DE Type Possible Values
0 baud rate rtUINT16 50 to 19200 (bits/sec.)
1 data bits rtUINT8 7 or 8 (bits)
2 stop bits rtUINT8 1 or 2 (bits)
3 parity rtUINT8 0=none, 1=odd, 2=even
4 reserved rtUINT8  

Where:

Field Name Description
baud rate The transmission rate of the communication line in bits per second.
data bits The number of significant bits within a transmitted character or byte.
stop bits The number of bits indicating the end of a transmitted character.
parity The type of parity used for verifying correct communication at the character level. Parity can be either even, odd, or none. If parity is specified, and a parity error occurs, then the character is ignored. This will cause a communication error.
dial string

Specifies the chat script used for talking to the modem. This attribute is only used if "modem" is set to one. The chat script is a series of expect-send pairs separated by white space. The following special sets of characters are treated specially when preceded by a double backslash:

Characters Description
d delay for two seconds
p delay for 0.25 seconds
n line feed
r carriage return
t tab
s space
T replaced with phone number to dial

 

[note] Control characters can be sent by preceding the character with a caret.

In addition to the above special characters, it is possible to set a timeout value for receiving a response from the modem within the string using the TIMEOUT value string. The value is specified in seconds and will be used until the next TIMEOUT token.

Embedded expect-send pairs can be put into the expect string by using a dash as a separator.

Example:

TIMEOUT 5 \"\" AT OK-AT-OK \\dATDT\\T TIMEOUT 60 CONNECT

Sets initial timeout to five seconds, expects nothing, sends AT, expects OK, but if it doesn't get it, will send AT and expect OK, pauses for two seconds, sends ATDT followed by phone number, and waits sixty seconds for the CONNECT string.
modem Specifies whether this communication port is connected through a modem or not.
hangup string Specifies the string that will be sent to the modem to hang it up. For example, +++ATH0.
abort strings Specifies a set of strings that will be returned from the modem when the dial fails. For example,
  • BUSY
  • NO CARRIER
alarm dest This vector contains a list of IP host addresses in which the RTU should send alarm information to. The name should be available via the /etc/hosts file.
rbe dest This vector contains a list of IP host addresses in which the RTU should send RBE information to. The name should be available via the /etc/hosts file.
poll after ack This attribute indicates whether a poll request is sent out after an acknowledgement message is received from the RTU. This attribute is only used if in serial mode. If this value is zero, then it is assumed that the poll message(s) will be sent using the PRBX timer.
poll wait ms This attribute indicates the number of milli-seconds to wait before sending the poll message out. This attribute is only used if "poll after ack" above is set to one.
nrt This vector indicates the maximum number of RTU's allows at each level of the Bristol RTU hierarchy. Note that the scan task does not check the values. For IP based communications, the first record (level 1) should always be one.
nrt version This attribute contains the version of the Node Routing Table.
rtu in backup This attribute will indicate if the current connection to the RTU has changed into backup mode. This is as indicated by the RTU.
serial mode This attribute specifies the serial mode. A value of zero indicates synchronous communications, while a value of one indicates asynchronous communications. In synchronous communication mode, each RTU on the communication port will be sent a request only after communications with the previous RTU has completed.
ts disable This indicates whether the scan task should respond to timesync requests from the RTU.
device in scan This attribute indicates which scan device is currently being serviced (either with a poll request or by a response from the RTU).
shutdown action This attribute specifies the OpenBSI shutdown action when the communication port is disabled, as either: 0 (zero) to shutdown OpenBSI, 1 (one) to shutdown OpenBSI only if the scan task started it up or 2 (two) to never shutdown OpenBSI.
desktop name This attribute specifies the name of a desktop to create. A new window station is created first with no security attributes. The scan task then attaches itself to the window station and creates a new desktop (again with no security attributes) with the given name and attaches the processes thread to this desktop. This is only required if the RTAP environment is started from a service that interacts with the user (which can potentially change the security attributes and prevent the scan task from being able to startup the OpenBSI services).
handle alarms

This attribute determines whether the scan task will handle alarm messages from the RTU(s) or not.

[note] Only alarms currently in the RTU's alarm queue are received. The scan task does not poll the RTU(s) for all alarm values.
handle RBE

This attribute determines whether the scan task will handle RBE (Report By Exception) messages from the RTU(s) or not.

[note] RBE messages are received from the point of scan task startup. The scan task does not poll the RTU(s) for the RBE values.
debug device UNIX

The device file where debug information is to be printed. The full path must be provided; for example "/dev/ptyqf". In addition to a device file, the following key words are recognized: "stdout" and "stderr"; which send debug information to the specified file pointer.

[warning] If a pseudo-terminal device is to be used, specify the master device; otherwise the driver will be hung on the open waiting for the master side of the pseudo-terminal to be opened.

 

[caution] If a pseudo-terminal device is used, the scan task must be started before any process tries to open the slave device; otherwise no debug information will be printed.
Windows

This specifies a "named pipe" that will be created on the server machine. Client applications can then make connections to this "named pipe" to receive debug information. A separate thread is created to handle each client. There is a maximum of six client connections allowed. Additional clients trying to connect will fail.

Since this is a "named pipe", clients can connect from other machines on the network.

See the tesserNet Scan Debug Utilities for freely distributable client applications.

[warning] Depending on the network connection speed, some debug data may be lost. Tests here, show that for a full 10 Mbit/sec connection, no data is lost.