Dynamic device name assignment in mtconnect

[johnmichaloski]

Question: I want to be able to support Devices that might be assigned to a different IP address at different times. This might happen during DHCP when a router assigns an IP address to the Device. Thus, an existing Device-Agent IP configuration would be invalid. Another possibility is that the devices “move” and then replug into a router (I call this a mobile assets case) while still talking to the same MTConnect Agent. Again, the IP might change, thus nullifying the Device/Agent IP assigned configuration.

Is there any way for MTConnect to do dynamic device assignment not based on IP but on the device name?

I am posting it to the issues web site, soweb crawlers will find my response!

[wsobel]

John,

Thanks for posting the issue. I'll make the changes to the agent and add a

* device: <device name|uuid>

Command to the adapter interface as well as various tests. The search order will be UUID and then Name – not that it should be an issue.

[johnmichaloski]

Answer: Yes! But you have to code a little in the Adapter. Support for dynamic device data assignment is already programmed into the Agent.

First, a little background on Internet machine naming and addresses. An Internet Host is defined by either:
• its Internet Protocol (IP) address (a four-part number string such as "129.6.32.47).
• its host name (a text string such as " astro.nist.gov") which consists of the machine name (e.g., "astro") and the domain name (e.g., " nist.gov " refers to the NIST network).

Typically, an IP address is used, because the host name needs a “Naming Service” to resolve the name to an IP address, which isn’t always available.

Devices can change IP Addresses for a number of reasons:

1. Dynamic Host Configuration Protocol (DHCP) or
2. Mobile assets. Moving devices around and replugging into a router.
3. Many firewalls act as routers and assign back-end PC IP address.

DHCP is a standardized networking protocol that dynamically configures network parameters, in our case the IP address. With DHCP, computers request networking parameters (in this case an IP) automatically from a DHCP server, and the DHCP server configures settings automatically. This contrasts to static allocation of IP addresses, for which the IP never changes. Most manufacturing shop floor use static IP since it is easier to track assets this way.

Figure 1 Adapter DHCP IP Assignment Day1

Figure 2 Adapter DHCP IP Assignment Day2
Note however, if the device uses DHCP the IP can change. For example, changes in the order of request may lead to different IP address assignments. For example, in day one, shown in Figure 1, Device1 could be assigned the IP 11.240.193.158 and Device2 could be assigned the IP 11.240.193.159. And the next day Day 2, when the machines boot in different order, the IP assignment could be reversed, as shown in Figure 2. Thus, data from Device1 and Device2 could be sent on 11.24.193.158 depending on the day and DHCP assignment order. Thus, another mechanism (in this case use of Device Name) must be in place to resolve which Device is sending data across an IP and port.

Next, you need to understand how a Device is configured in an MTConnect Agent. In the installation folder is the file, Agent.cfg, which defines the MTConnect configuration. Figure 3 shows this file, wherein Adapters are defined with a name/internet host/port from which the MTConnect Agent will read data. Thus, in the Agent.cfg configuration file example, in the section Adapters {…} are two devices “Device1” and “Device2”. Adapter one is defined by the IP address 11.240.193.158 and the port 7878 and is given the name Device1. Thus, to communicate to the Adapter the Agent uses the TCP socket 11.240.193.158:7878. The second Adapter has the TCP socket address 11.240.193.159:7878 and the name Device2.

Figure 3 Agent.cfg Example Configuration of MTConnect Agent

. Also of importance in the Agent.cfg file is the statement Devices=Device.xml which specifies the file that contains the XML Document describing all the data items for every device (each with a unique device name) under control by the Agent. Of note, the Device name specified by the Adapter must match a Device name in this file.

Adapters are back ends that connect Devices to Agents. Adapters output “SHDR” (pronounced Shudder) that the Agent reads from the given IP address and port. Using static IP definition, below is a sample SHDR string for transmitting Xabs data. The line is terminated with a line feed (\n) which is ASCII character 10 or 0xA and fields are separated by a “|” pipe. Plain SHDR text output from the Device looks like:
2014-09-29T23:59:33.460470Z|Xabs|1.4198908806\n
Now, let’s assume we want to transmit data from the device, “M1”. In this case the tag Xabs is prefixed by the device name and a colon character; e.g., “M1:Xabs”. The SHDR now looks like this:

2014-09-29T23:59:33.460470Z|M1:Xabs|1.4198908806\n
The Agent parses either the “Plain” (i.e., |Xabs|) or “Device” prefixed tags (i.e., |M1:Xabs|). However, when the Device colon prefix is appended to the tag name, the Agent will use this name to look up the corresponding Device (e.g., in Devices.xml) that matches this device name. Thus, the data will be streamed to the correct Device.

As mentioned, the code in the adapter needs to modified slightly to enable the Dynamic Device configuration by the Agent. We will need to modify all the classes that derive from the base class “DeviceDatum”, but will not be shown here. Only DeviceDatum will be modified to handle the Device name prefixing in the SHDR output. First, you will need to (1) add a character string mDeviceName of UNITS_LEN to the class DeviceDatum as well as (2) modify the constructor to accept a device name. We use the null string (i.e., “”) as a default initializer to aDeviceName so existing code works, and we can ignore prefix appending if desired.

class DeviceDatum {
protected:
/* The name of the Device */
(1) char mDeviceName [UNITS_LEN];
...
(2) DeviceDatum(const char *aName, const char *aDeviceName=””)

...
};
Now, the constructor needs to be modified to prefix the Device name to the DeviceDatum tag name. First, we copy the given device name into the member device name character string. Next, if an actual device is defined, then this Device name and colon is prefixed to the SHDR tag name. Now, every time this data item is output it will have a device name, colon and device datum name (e.g., “Device1:Xabs”). There exists a DeviceDatum method called prefixName which will append the device name on all SHDR communication.

DeviceDatum::DeviceDatum(const char *aName, const char *aDeviceName)
{
...
strncpy(mDeviceName, aDeviceName, NAME_LEN);
mDeviceName[NAME_LEN - 1] = '\0';
strcpy(mOrigName, mName);
if(strlen(mDeviceName)>0)
prefixName(mDeviceName);
...
}
It is the responsibility of the programmer to pass in the Device name for each datum item construction. Again, the Adapter software can either read this device name at installation or hand edit the device name in an ini file. How this device name is assigned by configuration is omitted.

The Adapter name must match a Device in the Agent devices.xml file.

Posted: John Michaloski Tue 07/26/11 03:01:07 PM

[wsobel]

Name prefixing

Name prefixing is only required if the default device given in the cfg file or dynamically assigned by the adapter changes. The prefix of the data item is usually used in sensors that get data from multiple machines like a XBee hub.

For the name resolution issue, here are some thoughts...

SMB allows for dynamic updating of local DNS with DHCP assigned IP addresses. There are other local BIND compatible solutions for other operating systems as well – samba on linux supports this... you can also do DHCP reservations with a known MAC address. But let's say you can't do any of that...

A couple of solutions: If you know the IP address range, a port scan could be done periodically on all machine in that range. If an adapter is found (port 7878 or whatever is given), a connection can be attempted and dynamically assigned as above to the device. An additional port scanner thread would need to be created with a short timeout on connections.

The address would need to be given as follows:

  Host: 192.168.0.128-134

or we could net masks, but that will not allow for easy subsetting of the address ranges. More than one range can be specified as well.

This would require a meta-adapter or an adapter factory that can create other adapters from the port scanner. Unlike a first class adapter that goes into a wait loop once it disconnects, this adapter will exit and allow the port scanner to reconnect next time. There is some additional house keeping required as well to make sure there are no duplicate connections, etc...

[wsobel]

I have added the

* device: <...>

Support in 1.3.0.8 and changed the device name requirements for adapters to allow for a lazy match. I have not built binaries yet, so please download and test.

[johnmichaloski]

I should clarify my ignorance. I'm not a DHCP expert. Most IT DHCP look at your macid before they let you on the network, and assign you same IP. But I know my old wireless router and natbox randomly assigned IPs - so it can be done.

However, I was informed that the MTConnect target application had 20 fixed ips, and the underlying devices on this network changed ips. Whether this is due to a firewall which remaps the ips to confuse hackers, or the mobility of (although macids should be the same), I am not sure. I did not need to know. I do know if you dynamically assign device identification - MTConnect can handle it. I tried it - it works.

[wsobel]

This would be easy to configure with a range or list of IPs. DHCP usually works with ranges of IP addresses, but putting 20 IPs as specific adapters into the cfg file may be tedious, though it will work with the current implementation. The new version will support what you're requiring, except not quite as elegantly as giving a simple IP address range.