Trends are funny. Some trends seem to quickly grab the attention of the public, only to fizzle out after the launch of the next trend. In retail, this is most notable with the latest kids’ toy — as soon as the holidays have passed so has the hype. Other trends take a long time to hit their apex because there are sometimes dependencies that govern the pace of development and market acceptance. A good example is space exploration. In the past, only countries could build a space program. Now, because of the market need and the technology available, there are quite a few private companies reaching out towards space.

So, what trend (problem in search of a solution) has been vexing automation for decades? Simplified software. To be more exact, the ability to move a machine’s mechanics in a predictable way. First-generation machine building (before PLCs), programming was done by mechanical engineers with cams and gearing. Add to that a motor with a Start and Stop button and you had a production machine. As time passed, electrical engineering was added with heaps of relays, cam switches, counters, etc. to add functionality and flexibility to that stable, focused mechanical design. 

We could have stopped there, but automation engineers are persistent. In the early 1970s (driven by the newest technology) PLCs, servo motors and electronic drives replaced the main driveshaft and motor scheme to deliver even more flexibility and speed to machines. But with a major problem: software. The addition of motion controllers created another level of complexity to something that once was “programmed” with relays. Automation has been wrestling with the trend to simplify since. 

The first iteration of software simplicity was ladder logic. The idea: The ability to program a PLC in the same way that wiring diagrams were written to document the electrical side of a relay driven machine. Early on with ladder, everything was good. The ladder programming style lends itself to handling bit driven logic (Booleans) and with simple motion control it was enough. But one motor became two, and then became a dozen, all synchronized for more performance and ladder couldn’t keep up. This is not because ladder is a bad programming tool (it is in fact one of the better ones because it is WYSIWYG), but because it is a bit-handler at its core. The introduction of multi-axes motion control ushered in hundreds of variables and dozens of math-driven function blocks that required bigger and more powerful PLCs. This is where the software simplicity trend starts.

Most technology providers started hearing the call from their base to reduce the complexity driven by the motion control technology that everybody in automation wants. The response from technology companies was “templates.” It makes sense. If you are a technology provider helping OEMs make machines with your software editor, you end up doing the same tasks each time you start writing a program: Enable Axes, Create a Mode Control, Track and Respond to Errors and Provide a way to shape the motion. But the problem that no one technology provider could see is that the complexity is driven by the number of software editors each provider has. For example, if there are 500-plus technology companies with products on the market, and each provider makes a template based on its own unique hardware and software then you will have 500-plus different programs. This means if an OEM or end user wants to try a new technology, they might have to invest in a new software platform and training for their organization before using the software. 

There have been industry groups addressing the problem of software standards, but even if you get the templates and function block libraries uniform across platforms, you still have the technology provider’s software editor that will never be unified (that is their secret sauce).

So, from the ’70s, we have been following the persistent trend of software simplicity but never getting there even though PLCs (for all purposes industrial PCs) have been getting more powerful and less expensive. What do we do now? Eliminate the unique software from each technology provider.

The software simplicity trend has surpassed templates because each template is platform dependent and has not adopted standards, and because templates don’t eliminate the platform specific editors. What we need is to go back to the original problem — the ability to move machine mechanics in a predictable way. This is where middleware can help, a lot. 

What Is Middleware?

Let’s start with an easy to understand example of a middleware device — a universal TV remote control. You buy a universal remote to eliminate the need for an endless number of remotes provided for each component (TV, Blu-Ray player, receiver, PC, game systems, etc.). To “program” the remote, you enter a predetermined code for each unique component. You then test that the remote on each component to make sure it is working. It’s simple.

Middleware is a definition for a piece of programmed code used by the controller, in automation’s case, a PLC. Middleware sits between the firmware of the hardware we want to move and the programmer/user of the machine.  Middleware contains two basic parts: a library of canned functions and a Human Machine Interface to configure the middleware’s functions. With middleware, we eliminate the last remaining problem with our software simplicity trend — the software. That is because the system connects the user directly to the machine components through the functions provided in the middleware. 

For middleware to work, the technology provider must know the applications they are targeting and provide 100% of the functions needed for the OEM to use it. Therefore, you will find middleware packages that are specific, like conveyor controls, adjustment systems, automatic guided vehicles (AGV), intermittent machines, etc. Middleware packages contain all the functionalities listed at the beginning of our trend, but in a way that they can all be configured through the on-board HMI. In the case of middleware, the most effective HMI is web-based so that anybody with a computer and a browser can connect and configure the motion and logic. 

The most important function of the middleware is to automatically detect, parameterize and add drives and I/O to the controller, which is a task that is normally done with the technology provider’s unique software. 

If you add this all together, middleware allows the OEM engineer to:

1. Connect the hardware of the system;
2. Power the system to confirm the configuration; and
3. Configure the functionality for the machine they are building.

Expect that if the middleware package specifies that it can be used on an AGV or Intermittent machine, you can make that machine without software or technology provider support. The biggest benefit? Because the middleware has the HMI via browser, your service engineers will never need to call for specific source codes or software to troubleshoot legacy machines. 

Does this mean the end of technology provider software editors? Doubtful. But it does pave the way for more simplified software and a new way of thinking about programming.

AMK Automation Corp. helps industrial automation machine builders and their global customers simplify machine needs with cabinet-free and in-cabinet drive and motion control solutions. Please visit amk.systems.