Factors to determine total cost of ownership of SCADA systems

The classic economic definition of the total cost of ownership (TCO) is the purchase price of an asset plus its operating costs over the asset’s lifespan. While this may be relatively easy to calculate for hard goods like a piece of machinery, the cost factors for soft goods, such as SCADA software, are more complicated to ascertain due to their wide range of features and licensing models. Control talked with Barry Baker, vice president of Trihedral Engineering Limited, to gain some insights from his more than 30 years of SCADA systems experience in many diverse industries.

 

 

A: Most SCADA systems will be required to operate for a decade or more before any major disruptive changes in an OT environment, so the TCO calculation can be divided into three distinct phases: build, operate and maintain. They can be performed by different users and both analog and digital factors are used in the calculation of TCO. 

 

 

A: Costs that can be calculated, such as the purchase price or I/O capacity per license, are analog in nature. A digital consideration is something such as reliability, which translates to a question of the cost of failure to the purchaser. For most in our industry, pricing in failure is simply a no-go, so it becomes digital, either meeting the reliability threshold or not.

 

One customer evaluating SCADA software products had an option to get free SCADA software included from a potential hardware vendor. While the purchasing department liked the price, the project owner noted the free software could cost a lot if it failed in the monitoring of their billion-dollar asset portfolio. You can guess that they determined free, with uncertain reliability, was not really an option.

 

 

A: While OT and IT systems are both software, most IT systems tend to follow the major release cycles in OS platforms, such as the three-to-five-year schedule of major releases of Microsoft Windows or associated IT hardware, which responds to changes in processors, network types or compatibility with other IT hardware. In contrast, most OT systems focus on industrial control hardware for a particular process that's required to have high availability disrupted with weekly updates. In some OT operations there are stringent change controls to minimize risks to critical infrastructure because there's a possibility of unintended consequences when performing updates. In other industries, OT system engineering may be subject to laws regarding professional engineering practices due to their legislated liabilities relating to serving the public.  

 

 

A: The purchase price translates into the license cost because software is conveyed by its license vs. physical transfer of hard goods. The license agreement determines how the software operates and under what restrictions. The common forms of operation are perpetual licenses that never terminate, or time-limited software-as-a-service (SaaS) licenses that are common in cloud-based systems. In a SaaS agreement, the purchaser is required to periodically pay a license fee for the software to continue to operate, whereas perpetual is a one-time initial charge.

 

When evaluating both, there is the analog consideration of the time-value of money over the expected lifetime of use coupled with a possible yearly price escalation on SaaS because most systems are not immune from inflation. In a digital consideration, the purchaser must “guesstimate” the expected lifespan of the SaaS and determine their upset cost if it's discontinued.

 

When it comes to impact from license restrictions, the purchaser must evaluate potential costs of any obligations to the software licensor, such as purchaser being required to indemnify the software supplier for certain activities or license breaches. The software license may have a stated limitation of use that can expose the purchaser to liability for selecting the wrong product if a failure later occurred.

 

Finally, there is the determination of how much software is needed and/or if any additional components are required to meet the application needs. An example is determining the number of I/O to be monitored. Are you forced to pay for the maximum product size, or can you reduce costs by sizing it to what you need? This should not be confused with what the license agreement allows, as “unlimited I/O license” means it can monitor an infinite amount of I/O, which isn’t practical since computers have processing limitations. 

 

 

A: Systems which come with integrated functionality will have a lower build cost vs. having to write code to achieve the same. The argument that writing code allows flexibility overlooks the hidden costs to maintain that code over the lifespan of the system. The timeframe includes product, OS, and personnel changes that impact how a particular script performs, and is called technical debt. There are other considerations as computer languages can fall out of favor in support, or be blocked by security concerns or changes to licensing models, such as VBA and JAVA.

 

Also, a user must consider ease of configuration. Are there any separate sub-components that must be configured to achieve system functionality? Is the database ready to use or are there license costs and administration time to be considered? If so, the complexity in the solution will result in more build time and costs.

 

 

A: The purchaser must determine if the product is intuitive and easy to learn. Operators will change over the system lifespan, so what is the cost to train new people? Can it be self-taught or easily learned with on-the-job teaching from other operators?

 

Also, does the product include tools that aid the operator, such as ISA 18.2 alarm management, easy navigation, operator notes, and the ability to trend and analyze suspect I/O without requiring additional engineering work?

 

Finally, how easy is it to recover from errors? Software with integrated features allows for fast recovery, and results in lower operational costs. These features are sometimes available as third-party products but require additional integration time. User workflow enforcement ensures use vs. the “always-on” availability of integrated product solutions. 

 

 

A: The first is how easy it is to update and maintain product concurrency. We want to avoid the Windows XP trap, where the OS was provided with patches for many years but otherwise abandoned with regards to product evolution. In the end, when Microsoft terminated support, users were forced to make major changes with disruptions to their businesses. Products that provide an easy evolution path by maintaining backward compatibility are less costly to maintain vs. purchasing a major product version and undergoing rework of the application on a periodic basis.