Can you identify a safety controller from its CIP device type?

Every EtherNet/IP device carries an Identity object, and attribute 2 of that object is the Device Type: a number that says which ODVA profile the device implements. It is the one field in an identity reply that is not vendor specific. The vendor ID needs ODVA's vendor list to mean anything. The product code is a private catalogue number that is useless without that vendor's own table. The product name is a string, and on several families the operator can change it.

So the device type looked like the right field to build on. Our EtherNet/IP module was parsing it off the wire and throwing it away, while keeping the product code, which is the less useful of the two. The plan was straightforward: harvest ODVA's profile table, compile it into the binary, and use it to recognise safety equipment without sending anything a safety controller might not like.

The question we had to answer first

Before writing a line of it, one thing had to be settled. Does a GuardLogix report a device type that is distinct from a ControlLogix? If a safety controller and an ordinary controller share a profile number, the numeric half of the idea is inert and the whole design collapses onto product-name matching, which is weaker.

ODVA publishes a conformance marketplace. Every product that passes conformance testing gets an entry, and the entry prints the declared device profile. The record for the GuardLogix 5580 family covers the controller and the 1756-L8SP safety partner together, and it states:

Device Type: Programmable Logic Controller: 0x0E

The same profile an ordinary PLC declares. A safety controller, and the safety partner that sits beside it, both announce themselves as a plain programmable logic controller.

What that means in a plant

It means the device type cannot tell a safety controller from a process controller, and no amount of table building will change that. If we had shipped the original idea, a customer with a GuardLogix would have received a report that quietly failed to mark their safety controller as safety equipment, and a customer with a ControlLogix might have received one that marked it wrongly. Both are worse than saying nothing.

The rule we work to is that a fabricated device fact is worse than a missing one, because it ships in the box, it reads as authoritative, and it is acted on in front of live plant equipment. A recogniser that is right most of the time is not a recogniser. It is a coin flip with a citation.

What the number can actually do

The table was still worth building, for a different reason. ODVA publishes forty device profiles, and four of them are safety profiles by ODVA's own naming: Safety Discrete I/O Device, Safety Analog I/O Device, Safety Drive Device and CIP Motion Safety Drive Device. A device declaring one of those is safety equipment by definition, not by our judgement.

That turns out to be the strongest do-not-touch signal an unauthenticated read can produce. One identity reply. No session, no writes, no consumed connection slot. When it fires, the aggressive and brute-force classes close on that host for the rest of the engagement, on the same keys the policy engine already reads rather than a new key of our own invention.

And the converse is written into the code, because it is the part that is easy to get wrong: a false result from that check means "this profile does not say safety", never "this device is not safety related". A GuardLogix will always land on the wrong side of it. There is a test whose entire job is to fail if anyone ever adds 0x0E to the safety set, because doing so would mark every controller on the plant floor as safety equipment and tell the operator nothing.

Two things we refused to write down

The first was a table entry from a Rockwell EDS example. The vendor's own EDS authoring guide prints a sample device section containing a product type of 0xFFFF labelled "Generic Device". It is tempting, and it is a synthetic sample under a fictional vendor code 65500 named "Test Vendor 65500". It is a formatting illustration, not a profile assignment. ODVA assigns 0x2B to the generic device profile.

The second was a range. ODVA's open publication states that vendor specific profiles carry numbers in "0x64 through 0xC7 or 0x0300 through 0x02FF". That second range has an upper bound below its own lower bound. It is a misprint, and the correction is obvious enough to guess at, which is exactly why we did not. Codes the document does not place are reported as unplaced, and the code says why.

The part that generalises

Both source documents we needed came back from an automated fetch as unreadable binary with a confident statement that the requested facts were not present. Extracting the text layer locally produced 182,310 and 78,026 characters of clean text, and the facts were in there.

A failed fetch is not a failed fact. On an air-gapped product this matters more than it sounds, because whatever is not compiled into the binary does not exist for that customer, and a fact wrongly recorded as absent stays absent for every plant that installs it.