If you a component vendors supplying the RV industry and you are wondering where to start, you have found the right place.
| Attachment | Size |
|---|---|
| RV-C Brochure.pdf | 15.39 MB |
Multiplexing is a fancy word for a simple idea. It merely refers to providing a “party line” for different devices to talk on. A typical RV contains many electronic products – electronic controls run the generator, inverter, refrigerator, air conditioning, and many other systems. And most of those products have some method of communicating. But each speaks a different language, to the benefit of no one.
Multiplexing defines a common language for every product, regardless of the manufacturer or function. A single pair of wires connects every element in the network, linking every product together like the phones in a party line. Every component can talk, and every component can hear the conversation.
Just as the telephone changed the world in so many ways, multiplexing promises to revolutionize the RV industry in many important ways. Other industries have already embraced it – most notably the automotive manufacturers who use multiplexing in every car and truck built today. And while there are many reasons the RV industry is embracing the technology, three key factors are driving it forward.
Universal Diagnostics
If you take your car into the shop today, the mechanic's first action is to plug in a computer into its diagnostic port. That port is an example of diagnostics using multiplexing. It will soon be possible for RV technicians to access a similar port in the service bay of a motorhome, plug in a cable from their laptop computer, and within seconds be reading diagnostic information from the major systems in the coach. Just like their automotive counterparts, they will be able to perform tests, configure components, collect data, and print reports. A single inexpensive tool will work for every component, regardless of the manufacturer.
Service cost and quality is widely acknowledged as an important concern in the RV industry. By providing the same type of service diagnostics as the automotive industry, multiplexing will improve diagnostic speed and accuracy, reduce warranty costs, and improve the customer experience.
Embedded Intelligence
A common feature in today's coach is a safety interlock that prevents the coach from being driven when a slide room is extended. Surely a sensible feature, which brings to mind the question: why doesn't the coach have a similar interlock for the shore cord, bay doors, or satellite dish? The answer is simple: while putting in one safety interlock is fairly easy, putting in several is much harder – not just to install, but to troubleshoot and fix if a problem occurs. But multiplexing changes that dramatically. With multiplexing, adding additional interlocks becomes trivial.
And many other types of “embedded intelligence” become possible. Products can change the way they function based on the available power sources. Climate control systems can interact intelligently. Features that were once impossible become a simple matter of programming.
Design (and User) Convenience
Multiplexing makes many things possible. With it, you can have multiple controls for the same component - or control multiple components from a single panel. Product controls can be customized for the specific application. The scope for vendors and designers to differentiate their product, refine the controls, and improve the customer experience is expanded exponentially.
Of course, the most powerful reason the RV industry is aggressively adopting this technology is simple: The future demands it. Every similar industry – from automotive to farm equipment, aviation to marine – has already moved to multiplexing. It is becoming a basic customer expectation. Just as no computer beyond the most basic is sold today without a network card, the time shall come when no RV over a certain price point wouldn't be similarly connected. The question is not “Whether”, but “When”.
If Multiplexing means allowing electronic devices to talk on the same wire, using the same language, then RV-C is simply the description of the wire and the language. There are multiplexing protocols defined for cars, tractors, factories, and aircraft. RV-C is simply a protocol designed specifically for RVs, and supported by major RV manufacturers and component vendors.
RV-C is based on a protocol called “CAN”, or “Controller Area Network”. Developed by Bosch GmbH in the 1980s primarily for the automotive industry, CAN has become the basis for protocols used in all kinds of vehicles. Virtually all cars built in Europe, and a great many built in America, include a CAN network that connects the engine, transmission, anti-lock brakes, and instrument panel.
CAN is the steel girders from which RV-C is built. The rest of the structure is work of the RVIA Technical Subcommittee for Multiplexing Electronics. Formed by the RVIA in 2001, the committee membership includes representatives of over two dozen leading RV builders and suppliers. The committee began its work by selecting CAN as the basis for RV-C, favoring the technology for its reliability, low cost, and wide availability of chips and tools. Since then, the committee has labored for two years to define the rest of the “language”.
The result of their work is a document available to the public through the RVIA. The essential elements of the work are complete, but just as the English language continually adds new words, RV-C will continually expand to include novel devices and new technologies. Ultimately, the process of maintaining and expanding the language will become the job of ANSI, the American National Standards Institute, with the close participation of the RVIA and its members.
There are alternatives to RV-C. Several vendors in our industry market proprietary multiplexing products. And almost every vendor with an electronically controlled product has had to wrestle with the communications between their product and its control panel. In fact, many RVs have as many as a half-dozen of these component-specific panels installed.
Standalone controls offer no new capabilities to entice the RV designer. Adopting RV-C does not mean that a standalone control panel can't be offered. In fact, using RV-C as the protocol for a standalone display is costs very little more than using a conventional point-to-point method such as RS-232. Nothing is lost in adopting RV-C - the product can still be marketed and installed in the conventional way.
But introducing a new proprietary protocol into the market would be a huge gamble for any company, and would almost certainly fail. It goes without saying that RV manufacturers are less than enthusiastic about adopting proprietary solutions and accepting the vendor lock-in they create. Such a network would have to have some truly compelling features to be viable in the current market. Adopting another vendor's protocol would be a similar gamble – will that vendor's protocol be more successful than the efforts of the entire industry?
Not surprisingly, already a large number of major vendors have announced products or otherwise indicated their intention of supporting RV-C in their products. And many others are simply waiting for the market to develop. The RV manufacturers are in a similar state: some have dedicated staff time to their implementation, others are still exploring. RV-C is the safe bet for both vendors and manufacturers who want the benefits of multiplexing.
The terminology of multiplexing can be confusing. The computer world is filled with protocols such as USB, Ethernet, and TCP/IP. RV-C differs from all of these in one crucial way: RV-C is complete. Not in the sense that everything about the protocol is written – in fact, it will never be complete in that sense, since new products will be introduced and added to the definition far into the future. It is complete in the sense that it defines every aspect of communication, from the type of wire used to the specific data items transmitted. This is not true of most computer protocols, which typically define just one or two “layers”, such as the physical wiring, message routing, or message contents. We'll outline the major layers here.
The wiring used in an RV-C network is a simple twisted pair, installed in a bus topology. A “trunk” is laid (we recommend Raychem 2019E0309 as a 20 gage cable that satisfies the impedance limits), and terminated at each end with a 120 ohm resistor placed across the pair. Nodes are connected to the trunk by “drops” of the same cable, teed into the trunk. Drops can be no longer than six feet, and can connect only a single node. No shielding is required. The two lines are designated “High” and “Low” (or sometimes “+” and “-” or “A” and “B”). All nodes are connected high to high, low to low.
RV-C does not designate a particular connector. The RV-C lines may be on a separate connector or part of the main connector for a product. Generally it should not be connected via a splice to a pigtail. Permanent splices make it very difficult to locate a problem in the wiring.
Data on the network moves at 250 kbps – about five times faster than a fast modem. All data is sent in packets consisting of a 21 bit header and up to eight bytes of data. If the network bandwidth is 100% utilized there may be up to about 3000 packets transmitted per second.
The header identifies the contents of the packet – that is, what kind of data is enclosed. It also identifies the sender, and in some cases the intended recipient. Finally, it includes the “priority” - higher priority packets get transmitted before lower priority packets.
The details of how the CAN protocol determines which node gets to transmit at each moment are handled by the CAN Controller in the node hardware. The details are unimportant here, except that it must be noted that it relies on every node having a unique address. This “Source Address” is a number up to 255, and assigning this address is a key part of the RV-C implementation.
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.
Among the PGNs required for all RV-C nodes is the Diagnostic Message. This PGN includes a general status indicator (red/yellow/green light), and if there are any problems with the node, a list of codes identifying the errors. Each error is identified with a System Identifier (“SID”) and a Failure Mode.
The SID is taken from a list of components defined for that particular product. For example, the generator start relay is assigned a particular SID. The Failure Mode identifies the way that particular component failed - “mechanical failure”, for example. By using SIDs and Failure Modes, all errors are distilled to a set of numbers transmitted on the network.
A simple diagnostic tool needs only to ask each node for its diagnostic status, and translate the SIDs and Failure Modes into terms a user can understand. Of course, many nodes will have more sophisticated tests implemented in their software.
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.