Source Code Issues for Embedded Engineers

In the technology world, we expect things to get easier and better. If you’re a little older you remember your grandmother’s TV. It took four men to carry it into the house, you had to get up and walk over to it to change one of the three channels, and the channels went completely off the air at about midnight. The idea of hanging a TV on a wall like a picture and having hundreds of channels that you could change from your recliner was just unfathomable.

Most things have been like this. Cars are so much easier and safer to drive now than they were in the past. Appliances use so much less energy. And remember the lack of automation in manufacturing plants just thirty years ago. Before electronic drives we used line shafts. Line shafts, for you younger folks, were long shafts powered by a huge motor at one of a machine. Mechanical engineers designed all sorts of gear boxes to power other pieces of the machine off that main line shaft. To run the machine, you had to just turn on the big motor powering the line shaft. Lots of problems with that, of course. Those expensive gear boxes broke, and to make a speed change you had to swap out some of the gears in the gear box. Electronic drive systems solved those problems.

There’s one place where we haven’t made much progress, and it seems to frustrate me more every year. RTA supplies a lot of customers building automation products with source code for networking applications. Customers use RTA EtherNet/IP Source code, Modbus TCP source code, PROFINET IO source code and more (DeviceNet, CANopen, Modbus RTU) to enable their devices for factory floor applications. When complete, these devices, now network enabled, must be certified by the relevant trade organization for that technology: ODVA for EtherNet/IP and CIP (Common Industrial Protocol) applications, Profinet International for PROFINET IO and the EtherCAT technology group for EtherCAT.

These organizations have a set of standards and a set of very comprehensive tests that they use to ensure that the end devices meet the requirements of the relevant specifications. What I’ve seen in the past few years, and I don’t like it, is that these requirements seem to be more and more moving targets. They seem to change frequently. One of the reasons is, and I support this, to more comprehensively test the end devices. That’s supportable.

What’s not supportable is the kind of thing that Profinet International has done several times. They vastly increased the requirements for access to their networks causing our customers massive new investment in the technology. A few years ago, they added a whole new layer of diagnostics. They required SNMP and generally, vastly increased the time and expense for device manufacturers to support PROFINET IO.

The other big problem is that with every increase in requirements, the minimum code size increases. What was once supportable in a processor with only 500 K of Flash memory is no longer supportable. Now the device manufacturer has to spin their hardware to add more flash and, sometimes, replace the processor with something faster. When you add the time to port their new application, test everything and deploy that new device, it becomes an almost intolerable expense.

At RTA, we plan to address this problem here in 2019. And, hopefully, just like going from the mammoth television, you’ll be able to sit in the recliner. That’s my goal. Look for more details in the coming months.