They say the difference between the the ordinary man and the genius is as simple as this: The ordinary man learns from his mistakes. The genius learns from the mistakes of others. If you are starting a new RV-C node design, here is your chance to become a genius. We've collected a list of some of the common mistakes we have seen in RV-C design projects. In most cases the pitfalls aren't terribly technical. They mostly are straightforward ideas that sometimes fall between the cracks in our rush to get the product finished. Use this guide as a checklist and maybe they'll start calling you a genius.
The RV-C bus operates at 250 Kbps, which translates to a maximum of about 2500 messages per second. In practice you'll rarely see a RV-C bus loaded to more than a tenth of that level. But when you are designing your node you have to presume the worst.
That's because even if only 250 messages are coming each second, they will come in bursts. Most messages are broadcast either in response to an internal timer or in response to a broadcast request. For example, an inverter/charger has about ten messages that it may send when it's 500ms timer triggers. These will likely be sent in rapid succession. If a service tool makes a global request for a DM1, every node in the network will respond immediately, leading to a burst of perhaps a dozen messages. That's the nature of RV-C traffic - burst of data followed by long (relatively speaking) interludes of quiet.
Therefore you have to design your node with the worst-case scenario in mind - one message every 400 microseconds. If your CAN controller has a two-message buffer, you have to be able to service that controller at least every 800 microseconds. A larger buffer reduces the speed you need.
If you plan on parsing your incoming messages immediately, then you must be careful to ensure that the longest path through your parsing routine doesn't exceed the 400 microsecond limit. And that calculation has to consider the possibility of higher-level interrupts or tasks interrupting the routine.
But since your controller probably has other tasks to handle on a tight schedule, the common technique is to set up a secondary buffer that can hold more messages. An ISR merely moves messages from the controller to this secondary buffer, and then the main loop processes the messages in the buffer at its leisure. Now you have milliseconds, not microseconds, to deal with the secondary buffer.
Whatever your product is, it should be self-sufficient in certain important ways. You have to be prepared to deal with the possibility that the network goes down, and that other nodes can appear or disappear at any time. Your node has to tbe able to operate autonomously.
Specifically, this means:
It must be able to power up safely, without input from any other device.
It must maintain its own configuration information, without relying on data from a control panel or other source.
It must be able to accept commands from any source.
This last item carries with it a critical corollary. You cannot assume that an incoming command is safe to process. Each node is responsible for its own safety interlocks. Those interlocks may be based on data from other nodes, such as the CHASSIS_MOBILITY_STATUS, but the logic must be held locally. You have to assume that other devices - and the users - are ignorant about the safety issues with your product.
When you move from designing closed systems to designing open systems, you have to work to a higher standard. In a closed system you can get away with fudging your definitions, writing indecipherable documentation, and cheating the specification. Often you can compensate for a bug in the main device with a workaround in the control panel. You can indulge in a lot of bad habits simply because no one will really know but you.
If you are singing in the shower, who knows that you are off-key?
But with open networks, it's like singing on a stage in front of thousands. If you are off-key, you'll get tomatoes thrown at you. If you fudge the spec the system might not work predictably - and you will be found out. If your documentation is wrong, your customers will send you the bill for the time they wasted as a result.
It only takes a little bit longer to get these things right. The payoff comes with less time and money wasted in the later stages of implementation. It's the difference between being an Engineer and just a "board jockey". Open systems demand professionalism.
Of the "Big Five" - the PGNs that must be supported to be considered RV-C compliant, the Request for PGN seems to be the one that designers are most likely to implement incompletely. This PGN has more wide-ranging consequences that might appear at first glance.
There are two versions of this PGN. The address-specific version (PGN 0xEAxx, where xx is your node's source address) always requires a response. If the PGN is one that your node supports, your node responds with the appropriate data. If your PGN doesn't support that PGN, your node replies with a NAK (0xE9FF), with code 1.
But many requests are global, using PGN 0xEAFF. In this case, your node either responds with the requested data or it does nothing. It does not send the NAK.
What many designers forget is that your node must support requests for all PGNs that it ever broadcasts. It is not limited to just the DM1, PRODUCT_ID, or NAME PGNs.
So, you've finished the product and it's time to wrap up the documentation. Sure, you have the Installation Manual and the User's Manual to get together. And internally you have your BOM and test suite. But now you have one more document to put together. We call it the Application Document, and without it your customers don't have a prayer of having a successful program.
Some companies fold the "AppDoc" and the Installation Manual together. Others treat them separately. But whereas the Installation Manual is concerned largely with the physical placement of the product in the RV, the AppDoc is concerned with the logical placement of the product in the RV-C network. It details how the product will operate in the network environment.
One section of the AppDoc should detail the RV-C basics - the PRODUCT_ID format and source addressing scheme. A second section should detail the DM1-RV messages (DSA, SPN-RV and Failure Modes) that the node may broadcast.
The largest section should list all the PGNs that the unit broadcasts. Each PGN should be explained fully, particularly where the RV-C document allows for interpretation or where the device does not support all of the features in the protocol. For example, RV-C often defines far more possible status values than your product actually supports. List the values that are valid, and if there is any ambiguity in the RV-C document clarify the definitions of each value.
Alongside that section is the list of PGNs that the device will parse and process. Again, be careful to clarify any potentially ambiguous descriptions.
The document should provide a table of the Required Inputs - the list of PGNs that are absolutely essential to the operation of the product. This may include, for example, the Chassis Mobility Status PGN if your product requires a safety interlock.
A thorough AppDoc will save you and your customers a tremendous amount of time and effort throughout the design, production, and service cycles. Put it at the top of your documentation priorities, and it will pay huge dividends.
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.
There are only five PGNs that are absolutely essential for an RV-C node. All nodes must support these, even if they have no real function on the network.
DM1 - The DM1 must be sent on a regular schedule. This is the "heartbeat" that allows other nodes to detect your presence on the network.
NAME - This message prevents two nodes from using the same source address. Even if you use static addressing, sending this PGN is essential.
Product ID - The DM1 says you are here. NAME says where you are. Product ID says who you really are. This PGN is crucial as it allows a service technician to identify your product exactly.
Request for PGN - This is the only PGN that you absolutely must respond to. If you don't respond to requests, no one will ever know your NAME or ID. Remember to parse both the address-specific version and the global version.
ACK/NAK - At the very least you need to acknowledge Requests for PGNs. Pay attention to what needs to be acknowledged and what doesn't. Do not send a NAK when a global request for a PGN is sent that you don't support. Do acknowledge any address-specific requests. Do not acknowledge merely informational messages, but do acknowledge commands to your device.
We suggest to all programmers to begin every project by implementing these five basic features. Only after these are complete and tested should you add the application-specific commands and messages.