All of us in this industry are partners sometimes and competitors sometimes. But there is one place where I hope we can cooperate to avoid the problems that have hurt the auto industry's electronic protocols. That's the area of service tools. Today any garage that wants to work on multiple brands of cars, trucks, or truck engines is required to invest thousands of dollars in equipment. And not just once - but year after year. Our industry, with it's mom-and-pop service facilities, just isn't going to spend that kind of money to be able to work on multiple brands of coaches and components.
I don't want to follow the truck industry. When J1587/J1708 first came out, one company developed and sold a "universal" hand-held service tool. It was hugely successful, but it was also very expensive. After a few years, companies like Caterpillar and Cummins came out with their own proprietary, laptop based tools. Each one was a lot less money than the handheld, but each company had their own tool. Eventually the company that made the handheld went bankrupt, but the dealers were left with having to buy multiple tools. Even worse - unsatisfied with the engine builders' tools, the body builders like Freightliner and Paccar came out with their own tools. Today a service center may have a half-dozen different tool packages to learn and maintain.
I believe that the problem started with that first hald-held tool. The idea was correct, but the company got greedy. They got spoiled by the margins they earned selling $2000 hardware units. So they were slow to move to the laptop and palm platforms, where they couldn't make the money on the hardware. The laptop proved to be the right platform, but it ended up being developed piecemeal, with scant thought towards making the pieces fit together.
Our industry gets to start fresh, and hopefully we can be smarter. If I'm right, then the key is that we start with a universal, laptop-based tool, and we don't get greedy. We've been doing our homework in this area, and we've found reasonably priced USB-CAN hardware, and we've put together a package of hardware and software that we can sell for $295.00 - a price which the service centers we've worked with tell us is reasonable. We won't make much money at that price, but it isn't charity work, either.
And here is the key: the software is modular. It consists of a base module that handles all the USB and RV-C overhead, and that has hooks that allow multiple "child" modules to run alongside. Those child modules are ordinary executable (.exe) files, and can be product-specific programs for troubleshooting and configuration. They can be written in any language, and since all the underlying USB and CAN routines are handled by the base program, the child modules are simple to create.
The program also has features that allow the author of a module to control who can run it, allowing a company to require certain training, authorization, or even maintaining a subscription. These modules can be distributed along with the service tool hardware, or by the author's own means. The contents and usage of the module is entirely under the control of the company that creates it.
To sweeten the deal, we are willing to build simple modules free of charge for any company. By simple, I mean a module that implements ordinary configuration and troubleshooting for perhaps a dozen or two parameters. The module will be functional - but not fancy. If your device is more complicated than that, or you are looking for something special in the feature set or the look-and-feel, we're willing to negotiate a time-and-materials contract. Or we will provide source code for a basic module that you can then develop into a full-blown program.
We have already developed some basic modules, such as a generic diagnostic code reader, a data logger, and a message sender, as well as modules for our own products. The program also has other important features, such as scripting. We use scripts for a variety of purposes, such as configuring coach systems in production at the RV plant. (Simple products may not really require a full program module. A script may be enough to handle the testing and configuration of a product with just a few parameters.)
We are also already building modules for certain other companies. PowerTech and TireSafeGuard both have modules in process as I write this.
If you think we're on the right track, let me know. Even more importantly, if you think we're on the wrong track, please post your opinions here. If we as an industry get this wrong, it may take years to recover.