Transcript
Len Vermillion: What factors would be considered in determining the TCO of a SCADA System?
Barry Baker: 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.
Len Vermillion: What are analog and digital factors?
Barry Baker: 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.
Len Vermillion: How is this different from the TCO calculation for an IT system?
Barry Baker: 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.
Len Vermillion: What considerations are there for initial purchase price?
Barry Baker: 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.
Len Vermillion: What are build-phase considerations?
Barry Baker: 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.
Len Vermillion: What are operate-phase cost considerations?
Barry Baker: 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.
Len Vermillion: What are maintenance cost considerations?
Barry Baker: 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.
