Like many control designers, I find myself raising my head up out of my day-to-day work to find that I seem to have missed the start of a new trend. It’s easy to figure out how it happens. There are plenty of distractions, as I wear several hats, and it can be hard to give fair attention to all the various aspects of the job.
While I would like to claim to be multi-tasking, the truth is, like a bee, I may dwell from time to time on a flower of a particularly sweet nectar. It’s not a caught-up-in-the-moment scenario so much as a focused train of thought and a desire to tick something off the ever-present list of things to do. A recent come-up-for-air moment led me down a path I had not expected.
Like many manufacturers, we are starting to see an uptick in the number and quality of candidates for technical positions. This has been a welcome relief. The years-long pandemic led to a labor shortage, in general, and that led to embracing innovative ways to maintain the same production output with fewer people.
As we all know, much of that innovation came in the form of investing in automated means of performing the tasks on the plant floor. The immediate relief of a machine filling the gap, literally, on the production line was closely followed by the panic over what to do about needing to teach and maintain these smarter machines.
Recent trends tell us that technical people are becoming available or looking for different opportunities now that we are on the downhill side of the reaction to the pandemic.
The unseen impact of more people playing in the same sandbox is how to manage the application and computer-aided-design (CAD) files when more than one or two people will need periodic access to these files.
The instant answer was to use the vault-style programs that include add-ons to the software packages we use. Well, maybe that isn’t the best solution to the issue.
For example, we use Solidworks for our mechanical drawings. We customize machines and have our own machine shop to support this activity. We even build some machines of our own design, and Solidworks is a great platform for this activity.
Like most CAD/CAM software, Solidworks offers product data management (PDM) to go with the design software. As expected, it creates a single-point repository on a server where files can be checked in and out. In addition to controlling who has the file checked out, it also provides version control where previous versions are kept for reference or even to restore to use, if needed. PDM offers to store other file types as part of an overall project management system.
AutoCAD, with add-on feature sets of mechanical, electrical and plumbing (MEP), is our other main CAD development environment. Like Solidworks, Autodesk offers a vault product, which resides on a server and performs the same functions of check-out/in and version control. This product, too, can store files of various types as part of a whole project management system.
For programmable-logic-controller (PLC), programmable-automation-controller (PAC) and human-machine-interface (HMI) development, we are nearly exclusively a Rockwell-based user. However, unlike the Solidworks and Autodesk environments, we don’t have the advantage of the files automatically upgrading to the latest version of the software when new releases come out.
Following the pattern of the design-software companies, we looked for a Rockwell Automation vault, and we found one, of sorts. FactoryTalk Hub is a web-based launch point for a series of products, providing the user with a single point to launch many things Rockwell-related. In this group are products related to design, operations and maintenance.
FactoryTalk Vault is an icon in the Hub. Vault allows you to create folders, where you can upload various file types to manage, just like the other project management systems.
Once files are uploaded, they show up with the appropriate icons to indicate the type of file. Other users can download files from there, edit them and upload them again. While this serves the basic central file storage/management aspect, it falls short of its true potential in that it appears the Hub was designed around current hardware platforms only.
Like many users of automation products, our installed base has everything from an early model SLC 500 brick PLC and MicroLogix 1000 series PLCs to CompactLogix/ControlLogix PACs and recently the Micro800 family on the processor side and myriad versions of the PanelView platform—Classic, Plus, Plus 6, Plus 7, 5000 series—for operator interfaces. We also have some Parker and Siemens HMIs in our inventory and in everyday use.
By focusing on the latest platform only, this particular product completely ignores the fact that many, perhaps most, users still have plenty of legacy products in their inventories that are rendered to legacy-file status instead of a living document with real-time use.
The conclusion we drew from this research is that perhaps there will not be a one-stop-shopping event to manage the files that we create with our automation projects. We could invest in vault-type software for each of our main software design platforms, or we could invest in a generic platform offering version control software and be satisfied with just general file control.
Another major consideration when going after file version control is where the repository will be located. While both Autodesk and Solidworks versions reside on a server within your network architecture, other products like FactoryTalk Vault, Git, PVCS and others are web-based storage points. I get a lot of side looks every time I mention this, but I’m not so sure that a cloud-based storage is where I want to be.
The huge cloud-based services that are driving business these days, while seemingly secure, may not be as safe as we would hope. Every day it seems there is yet another news story of a server or software platform that has been hacked and data has been leaked/shared/made available openly. Another thought is what happens when I need to get to my files and my Internet connection is severed or down for service? I need to work right now, but my file is on a cloud server.
It was the investigation into the FactoryTalk Hub that brought about a term that is popping up more and more in our automation lives: Software-as-a-service (SaaS) is in pretty much every aspect of business life. So, what does it mean? Well, this is a software platform that you don’t own—you use it and pay a fee, based on how much you use it.
The software, in many cases, actually resides on a cloud-based server. While this is convenient, in that you don’t have that big application eating up your local hard drive space, you are, again, dependent on a secure and ever-present connection to the Internet. In the example of the Hub product, the various tools are part of multiple platforms, and access to them is, again, incumbent on paying a user fee to have access to them.
So, this discussion might come off as being negative toward cloud-based services and the SaaS approach. Perhaps that is so. However, depending on your business model, this type of marketing/deployment has benefits, as well. If, for example, we have a small design team and not everyone needs daily access to the development software, then this might be an ideal way to run the engineering department.
Users pop on and off the service, and we pay only a fee for the time that we are in the development software. To make an intelligent decision, we would really have to accurately record the time we spend in each software application and record it, so that we can determine if a yearly fee to have local software installations to the computer is more economical than a service-based approach.
Jumping to this approach may also leave legacy-hardware support/online troubleshooting behind accidentally. If you have a large installed base, like we do at my job, there isn’t an option to drop off the old hardware platforms because we use them every day.
One last subject in this software-themed discussion—local licenses vs. network. This subject felt like a burn after we discovered it. We have a couple of people, like myself, who are in the program development environment on a daily basis. It makes sense that we have individual, dedicated licenses for this type of use. We have others who seldom need the software, usually for troubleshooting purposes, and only need to access the software from time to time.
We have always used local licenses and buy a new collection of licenses when we make new hires for the tech positions. As one can imagine, having six or seven technicians spread out over three shifts in a 24-hour operation can get expensive for laptops and software.
When we recently added a new technician, we realized that maybe we don’t need to keep paying for support of multiple licenses of our application-development software. If that is the case, perhaps we could use network licenses that are shared between the technicians. They could still have their own laptops, but, considering the price of the license for each of five common software platforms that we use, this might be a significant savings for us.
When we asked for a quote for the five software applications, but with network licenses, the quote came back with the same “local” license that we normally purchase. When we questioned our supplier, we were told that they are the same licenses, but you just put them on a server instead of an individual laptop.
While the answer seemed simple, in hindsight, it exposed a misunderstanding that others might have. Instead of paying each year to upkeep seven software licenses on five different development platforms, perhaps we could only have four sets of licenses with one set being for the floor support folks to share between the three shifts in two plants.
Take some time to plot out your current situation and perhaps a change in deployment of licenses might make better sense.
