Application Layer
Within the header is an 18-bit number called the Parameter Group Number, or PGN, which identifies the contents of the packet. The largest part of the RV-C definition is the list of all the packet types, and the PGNs that identify them. A typical product may support a dozen or more PGNs, all of which are defined by the protocol.
Certain PGNs are common to all products – and for some support is mandatory. There are PGNs for assigning Source Addresses, and for identifying the manufacturer and model of the component. There are PGNs for providing diagnostic information and general operating status. There are even PGNs for identifying which PGNs the product supports.
At a minimum, every product must properly use and respond to the messages related to Source Address assignment, component identification, diagnostics and operating status, and identifying the PGNs the node supports. All else is optional – although every product will also have PGNs that directly relate to its operation that they would be naturally expected to support.
It should be noted that since RV-C is built upon international protocols, it always uses metric units. Nodes that use English units in their internal programming or data presentation must convert whenever they send or receive data.
The RVIA committee is working to define PGNs for all products that are expected to be on the market in the near future, but the list will surely expand as new applications are devised. Thus the process of defining PGNs is an ongoing one, and through the RVIA and ANSI a procedure is being put in place to allow every component vendor the opportunity to submit new PGNs for inclusion in the protocol.
Sometimes it may be appropriate for a node to include features that are outside the RV-C PGN definitions. For example, there may be very product-specific configuration or factory testing features that would not be appropriate for general use. RV-C defines a way for components to communicate “proprietary” messages, just for this purpose. The content of these messages does not need to be documented in the RV-C specification, and can even be encrypted if there are trade secrets to be protected. However, proprietary messaging should be reserved for those few situations where the conventional PGNs are not appropriate.