Inside the box
Here are six things you should know about automation design, but may have forgotten along the way.
1. Scalability. If only you had a nickel for every time you’ve heard, “Think outside the box!” For some applications, this represents one of the core pieces of the PLC (many boxes) versus PC-based control (one box) debate. If you design with a PLC, then wind up needing more axes of control or additional control loops, you may need to buy more CPUs, communication cards, hardware, software, and integration time. A multi-core industrial PC (IPC) can be more scalable, adding control loops as needed.
2. Integrated control programming environment. Most programming software touts various easy-to-use features. Many programming packages offer capabilities to incorporate control, motion, human-machine interface and operator interface, I/O, communications, and other programming in one system. Libraries of pre-assembled code are very helpful, as are those that offer all IEC 61131-3 languages, since some are more useful than others for certain programming challenges. However, especially since we’re interested attracting younger engineers, software that also integrates C/C++, .NET, and simulation may be especially helpful.
3. Closed versus open. We did an article years ago on what openness means. There’s little consensus, but some suggest that IPCs are generally more open and supportable in the long run, compared to PLCs. More than 15 years ago, some predicted the demise of PLCs, and PLCs are going strong, evolving with the rest of us. Even so, it seems that electronics and software make an increasingly greater contribution to automation engineering creativity. Platforms that promote greater scalability, flexibility, and preservation of programming assets may have an edge by interesting and attracting the best and brightest of new engineering talent.
4. Application experience. Ensure that the application/sales engineers, distributors, or system integrators you’re working with have applied the hardware and software to implementations with elements similar to yours, with measurable results. No two applications are exactly alike, unless you’re printing money by applying a cookie-cutter design across multiple sites. Even across industries, there are many more similarities than you might think, especially with the right tool sets.
5. Usability. Engineers should be required to use the products they design. Security should be built in and set as the default. Elements that can wear out sooner or require maintenance should be easy to access and fix. Mission-critical components should offer diagnostics, alerts, and redundancy, as needed. Optimization, self-configuration, interoperability, and wizards should be more than marketing phrases. We need to design products to help get the world out the messes we’ve gotten ourselves into, using creative and elegant engineering, not complexities heaped on conundrums.
And if there’s redemption, the engineers who designed that car with the inaccessible final spark plug have chosen every slowest checkout line since then.
6. Convergence. Where it makes sense, consider products that combine functionality. Twenty years ago, did anyone consider that we’d have cool engineering applications, e-mail, texting, games, video, a camera, an alarm clock, a stopwatch, global maps, geopositioning, a music library, an encyclopedia, warehouses of storage space—and a wireless, mobile telephone—in one device? For us, it might mean greater connectivity of information, programming, and assets across design, simulation, testing, operations manufacturing, maintenance, enterprise, and the supply chain—bringing dollars and sense to control engineering. Get creative with your automation, controls, and instrumentation designs.
– Mark T. Hoske, content manager, CFE Media, Control Engineering, email@example.com.
Other articles of interest follow.