Adding RV-C functionality to a product is straightforward, and well within the technical capabilities of any company that is already familiar with digital electronics. Although there are several companies that offer specialized tools and software which can accelerate development, most designers will be able to succeed using only their own wits and a few inexpensive tools. But designing a product for a multiplexed environment does require a little extra thought.
Most devices are designed to operate independently, generally with a single point of control. Controls are either integrated into the product, or a single remote panel is provided. Multiplexing demands certain provisions to allow every node to be controlled from multiple sources.
All nodes fit into one of three categories:
* Conventional components such as sensors, lights, gensets, slide rooms that are monitored and controlled,
* User interface items such as control panels and switches, and
* Embedded intelligences, such as thermostats and genstart modules, that automate and control other nodes.
Many products encapsulate more than one type. For example, a thermostat may embody both a temperature sensor and a heating control. But it should be noted that logically the “intelligence” that determines when the furnace is turned on could be implemented in a wall thermostat, in the furnace itself, or in some other module. This fact has important implications.
A node should be as simple as possible – but no simpler! For example, although when designing a furnace, it may seem wise to integrate a thermostat logic into the furnace, that may be a mistake. At least, it is extremely important that the thermostat feature can be disabled. The RV designer may intend to use a different thermostat control, perhaps with additional features that the furnace designer could not anticipate. The furnace must be able to operate as just a furnace – something that turns off and on upon command.
A well-designed node is autonomous – self-sufficient for its general operation. Conventional products often store their configuration information in their control panel – this is a problem in a multiplexed environment which may have several (or no) control panels. Whatever configuration information a node needs should be contained in its own non-volatile memory. It should not assume any other node is on-line, except whatever is absolutely necessary for its operation.
Of course, some products naturally require others to be installed. For example, a thermostat is useless without a furnace and/or air conditioner. In such cases, it is important that the product fails “gracefully” if the other node is taken off-line. A furnace, for example, should probably turn off if no thermostat is present. Sometimes this is a safety issue – mechanical products especially require proper programming. In some cases this means a mechanical override should be provided for emergency use.
The autonomy principle also means that certain safety features always be integrated into the product. For example, most generators shut down when their coolant gets too hot. Although it is possible to implement this feature through a remote controller, it would be a serious mistake. Fundamental safety and self-preservation features should remain integrated into the product.
An important point to remember: if some other device commands your node to perform an unsafe or self-destructive action consider that it is your node's fault if it obeys! For example, if a slide room is extended while the coach is in motion, it is the fault of the slide room for failing to check the chassis status. Do not expect every other manufacturer to understand all the safety issues associated with your product and to properly implement the solutions.
The electronic hardware has two major parts. The CAN Controller handles all the logic necessary to transmit and receive data. It handles “arbitration”, the process by which all the nodes in the network determine who gets to talk next, as well as the transmission speed and other aspects of the process. Most of this it does automatically – the main processor doesn't need to concern itself with the details of the transmission and reception.
The other main component is the Transceiver, which steps the signals from the Controller to the proper voltage levels to be heard on the network. CAN Controllers are often integrated into the main microprocessor – in fact, almost every major microprocessor family includes versions with an integrated CAN controller. Atmel, Microchip, Intel, Motorola, Fujitsu, Infineon, NEC, Phillips, TI, ST-Micro, Toshiba, Hitachi, and National Semiconductor all offer CAN on at least some of their processors – 8, 16, and 32 bit. The transceiver, however, is almost always a standalone component.
Note that some transceivers support a signal-shaping technique intended to reduce EMI. Do not implement this feature – transceivers from different manufacturers occasionally have troubles intercommunicating when one or the other is using this wave-shaping.
RV-C operates at 250 kbps. Since data is transmitted in packets with eight bytes of data and 21 bits of overhead, this translates into about 3000 packets per second. In actual use it will rarely see this much activity, but the processor must be able to deal with bursts of that speed.
Most controllers have a limited buffer – generally a dozen packets or so. Therefore the processor must be able to check the buffer and process any contents rapidly – every 3 milliseconds or so. For most processors this requires using a timer interrupt to call the service routing. Some advanced products may use the services of an RTOS. Not all messages need to be stored, so memory size is not necessarily impacted. But the processor must be able to handle the throughput.
RV-C software can be extremely simple. Most products need only support a handful of messages and can ignore everything else. A few features, however, are mandatory.
One mandatory feature is the addressing procedure. As noted above, every node on the network must use a Source Address to identify all the messages it sends. Nodes may use either “static addressing”, in which case the Source Address is preset and never changes, or “dynamic addressing”, where the address is determined when the node is powered on and it may change as other nodes are added.
Static addressing is very simple – the node simply uses the Default Source Address defined for that product type. It “claims” this address when it starts up, and when another node attempts to claim the same address it responds with a message that informs the other node that it can't change. (It has 250 ms to respond). It's extremely easy to implement, but suffers from one obvious drawback – you can't put two of them on the same network. Perhaps not a problem for a generator, but unforgivable for a control panel.
A node with dynamic addressing starts by claiming an address from a recommended range. If a static node is already there, the dynamic node tries the next lower address. If another dynamic node is using the address a tie-breaking procedure is used, and the loser moves on.
Nodes that implement dynamic addressing also must implement some sort of unique identifier, an embedded serial number that serves as part of the tie-breaker. Dynamic addressing does not require a lot of code – fewer than 100 lines of “C” code can encapsulate the entire process.
Because some nodes may be dynamically addressed, nodes can't assume that another node's Source Address will always stay the same. The Source Address alone does not identify a node – in fact, RV-C has no provision for completely identifying a node and its capabilities. Although this may seem to be an oversight, it isn't. Each packet of data is defined without reference to the source address. When parsing a message the receiving node can ignore the source address – the only exception being for proprietary messages. There is little reason to keep track of the addresses of other nodes.
The source-independence of the messages also means that most data will have just a single source. There is no “battery voltage” PGN, but there are PGNs for chargers, isolators, and other devices that include a battery voltage. Thus a node looking for the current battery voltage must ask for “voltage at the charger” or “voltage at the isolator”. There is an implicit assumption that there is only one battery isolator. In the case of the charger (and many other products) there are specific provisions for identifying multiple units.
The other features that are mandatory for all nodes are the Diagnostic PGN, the Product Identification PGN, and the response to a PGN Request. Any node can query any other node or all nodes on the network for specific information. If a node is specifically asked for a datum, it must respond either with the data, or with a certain negative response.
If a node embeds the functions of more than one product, such as an inverter/charger combination, a generator that includes a genstart module, or a furnace that integrates a thermostat, the programming hardly changes. The node uses a single Source Address for all messages. The only distinction comes with the Diagnostic Message – the node will send one message for each product that it embeds. Each product is distinguished by a different Default Source Address, which is included in the diagnostic packet.
Since one of the main benefits of RV-C is the ability to provide diagnostic information through an inexpensive electronic tool, some consideration should be given to diagnostics in the design. Of course, at a minimum an RV-C component must support the basic diagnostic features described above. Some components may need additional configuration and diagnostic tools.
One of the benefits of RV-C is that each component vendor does not have to reinvent the diagnostic tool. The same technician's tool can potential work for every node on the network. SilverLeaf Electronics is introducing just such a “universal tool” - a laptop-based cable adapter and software package. SilverLeaf will include a basic diagnostic module in their laptop software for all components, at no charge to either the vendor or the technician. For many products this will be sufficient, but some vendors will wish to create more powerful modules that include proprietary capabilities.
The tools to do so are available from SilverLeaf for a reasonable price, or vendors can contract to have SilverLeaf do the programming. This custom software can use RV-C's provisions for proprietary messaging to perform whatever unique configuration or diagnostic tasks the product requires. Such a module could be used for factory testing and advanced configuration, as well as ordinary diagnostics.
Software modules can be distributed as a free download, a for-pay download, or with a “key” that the technician would have to enter before they can use it. This last capability allows the vendor to require the technician to complete a training course or qualify in some other way to use the software.
Most vendors are not used to providing the type of documentation that is required to live in a multi-vendor environment. Ordinary installation manuals are not enough. For a RV builder to be able to install an RV-C component with confidence in its interoperability they need much more detailed information.
The “RV-C Interface Application Document” should include a description of the product and its functions. It should also explicitly and completely define the following:
* Source addressing scheme used, and default address.
* The PGNs and data items it supports.
* The PGNs and data items it requires to operate.
* The commands it accepts.
* The commands it issues.
As it describes each message or command, it should also document its failure modes – how the product responds if a datum is missing or an invalid command is received.
Service documentation should include the SIDs defined for the product, and service advice appropriate to each SID and Failure Mode.