Get the PRODUCT_ID Right the First Time.
The PRODUCT_ID is a simple, nearly free-form PGN, which means it's exactly the kind of PGN that gets screwed up the most. The importance of the PRODUCT_ID may not be obvious at first glance, but it is one of the most critical PGNs, which is why it is one of the "Big Four" - the PGNs that are absolutely required to be supported.
The PRODUCT_ID is simply a text field in four parts - Make, Model, Serial Number, and Unit Number. Each part is separated by an asterisk. Loosely speaking, the Make is the name of the company that makes or distributes the product. It should correspond to the name on the physical label. Each company should be consistent across their product lines with their Make. If one product is from "ACME PRODUCTS", so should all the products from that company.
The Model is more free-form. Usually this consists of a model name and a version number - for example, "DR2000 v2.00". Again, the format should be kept consistent, even to the length of the names. The reason will be apparent.
Not all products get a unique Serial Number, and that doesn't mean this field should be left blank. It can also be used for a lot number, build date, or other datum that can be useful in the field. The Unit Number is provided for those items where the physical unit may have a different identifier than the electronic controls. It is commonly left blank.
The first use of the PRODUCT_ID is as a way to communicate to a service technician the critical details of the product. Since it is a simple text field, the technician can usually read this from even the simplest service tool. Therefore, it is the best place to put the crucial data needed for troubleshooting. Completeness is the key. The encoded data should be enough to fully identify the unit for technical support.
The second use is for more advanced service tool features. As a product evolves it may be necessary for a service tool to query this field and adjust its feature set accordingly. The software may hide or display certain parameters according to the model or version it finds. Consistency is the key. The format should be consistent across models so the software can properly identify the target.
Sometimes it isn't just the service tool that needs this datum. Other network nodes may need to identify product versions in order to implement workarounds for known bugs, or to adjust their feature set. Product inevitably evolve, and the PRODUCT_ID provides an important tool for dealing with changes in the field.