The ‘rent or buy’ concept is not a new one. It’s the difference between buying software on a perpetual or subscription basis:
Perpetual license - Pay once, to use the software for as long as you wish. Ongoing updates and support will be an ‘optional extra’ or provided for a limited time from the date of purchase.
Subscription license - Regularly pay a recurring fee for access to the software. Product updates and support costs are bundled into the subscription.
Despite a wider trend towards subscription and ‘Software as a Service’ (SaaS) products; when you buy industrial automation software you can still choose the licensing model which best suits your needs. Where you may get less choice however, is whether you actually own the software which runs your plant at all…
In this post I want to highlight several characteristics of automation software which everyone who buys it needs to be aware of. Buying automation software without this understanding can turn out to be an expensive mistake. One that’s easy to make, and even large blue-chip companies get it wrong.
Hopefully this equips you to ask the right questions when engaging automation suppliers. Helping you buy open technology and putting you in control.
Automation software
First it’s important to understand the components of automation software, as the language used by vendors isn’t always clear. Broadly industrial automation software can be categoriesd in two ways:
System - The ‘system’ is the software package created by (typically) a large automation manufacturer. It’s the software environment your vendor uses to configure the equipment they are supplying so it operates your plant correctly. The ‘system’ can be likened to your computers’ operating system, except in most cases it’s tied to the hardware being used so is more like macOS than Windows or Linux. For example, you must use a Siemens TIA Portal or STEP 7 system to configure a Siemens PLC; likewise Rockwell’s Studio 5000 or Connected Components Workbench is needed to configure it’s Allen-Bradley PLCs.
Configuration - Using the ‘system’ your vendor will create a Project containing the software configuration used for programming the automation equipment to control your plant and machinery. The ‘configuration’ is the source code discussed below, and can also be referred to as the application, logic, project or config.
With this distinction clear, read on to learn about the methods automation vendors use to keep ownership of software in order to secure the loyalty of their customers.
What have you bought?
We recently received an enquiry from one of our clients - a multinational, publicly listed enterprise. Several of their sites had used a systems integrator to upgrade their process historians. The contracts looked good value at the time, pricing was competitve and included a comprehensive support agreement.
A few years on, things looked a little different. The process historians were not being backed up or maintained. On looking into changing suppliers our client discovered system software licenses they thought were purchased in their name had in fact been leased to them by the systems integrator. Meaning the cost of changing to another supplier, even the software manufacturer, would include paying for the software again.
The enquiry? Could we help upgrade the process historians, and move them onto new licenses they’d purchased to exit the supplier relationship.
When buying control systems with a software component ensure your automation vendor buys the software in your name, not theirs. This does not prevent the vendor from providing you with support, but ensures the software manufacturer has your details on file as the end-user.
Regardless of whether you change vendors in the future, or decide to ‘self-maintain’, you retain ownership of the software and access to manufacturer support.
Where’s the source code?
More common when buying a pre-built machine, but not unknown in distributed control systems, is the practice of vendors keeping ownership of PLC ‘source code’. This is the program which tells a machine’s embedded controller how to operate the equipment and communicate with other systems.
In the case of machinery, the manufacturer has invested significantly in developing their product and likely doesn’t want their know-how falling into the wrong hands. Also, their business is better equipped than others to provide follow on service and support.
Longer-term this situation can hurt end-users, when:
- The original equipment manaufacturer (OEM) decides to withdraw support for the product line
- Over time the OEM loses the experts who originally designed and manufactured the machine
- OEM goes out of business, or otherwise, can’t meet its obligations
- Control of source code is used to prevent the end-user going elsewhere for related systems
- The PLC within the machine fails, and they are reliant on the OEM to fix it
For process control systems, where PLC software has been written specifically for the end-user in line with their requirements, there’s no justification for withholding access to source code. If IP must be protected this can be done to specific code blocks (see below), rather than the entire configuration and holding the end user to ransom.
Ensure you have a copy of the source code for every PLC you own.
Do not accept arguments your supplier may give about protecting their IP. If they need to protect know-how this can be done as described below while allowing you to have a copy for disaster recovery.
IP-protected software
A feature of almost all the systems used to configure PLCs have is the ability to password protect the software components. This feature is often referred to as IP or know-how protection and allows automation vendors to protect software they develop from being copied or used without their knowledge. Vendors often develop clever solutions to industry specific problems or applications, investing time which they may only be able to recover by selling the resulting product more than once.
However this feature can also be used to completely remove the ability of end-users to view and modify the software they’ve paid to develop and are reliant on to run their plant. Meaning the original supplier must be used for all future support, modifications and updates
Ask whether any of the configuration developed for your project will be IP-protected, and for documentation which describes what this does to allow future modifications, additions or upgrades of the software.
If a software configuration is developed against detailed requirements you’ve supplied it’s your IP, not your suppliers. They may implement specific code blocks they own to increase project efficiency and quality but how the plant works and should be controlled is your company’s know-how.