When planning improvements to a legacy HMI/SCADA system, the option of migration to a more advanced system needs to be considered to ensure that the functionality and usability of the system meets expectations and changing demands of the business.
Einstein said: “Significant problems cannot be solved at the same level of thinking with which we created them.”
As businesses expand, operational infrastructure grows and ages. Consequently, as companies focus on growth, it may be time to acknowledge that tools which were once solutions have now become sources of problems in themselves.
The dilemma of a Plant Operations Manager highlights this scenario well:
• The SCADA system, that ten years ago met the process control needs of the operations, is now unable to keep in step with the pace of expansion of the total business.
• This legacy system is now unable to meet and address the increasingly stringent safety/security/regulatory reporting requirements of today.
• Yesterday’s productivity benchmarks have been raised and senior management is aggressively seeking reduced energy/infrastructure costs and improved incidence management.
• Driven by competitive pressures, the increased demand from senior management for greater plant floor visibility is also showing up major gaps in the control system’s reporting functions.
• When ageing hardware components of the legacy system have to be replaced (be they PLCs, RTUs, CPUs or even PCs), the ripple effect on the communications and the software systems is significant and at times calls for changes to both communications and software.
• Eventually the cost of maintaining the legacy system (labour, training, spares, downtime etc) as well as the opportunity cost (lack of synergies with business systems and reduced leverage of new analysis techniques) makes the legacy SCADA system ‘part of the problem.’
While the need for improvements is felt, tangible barriers to moving from the old to the new still exist. Various industry estimates place the value of legacy process control systems, which have reached the end of their realistic life cycle, in excess of US$60 billion globally. The barriers that have contributed to creating this scenario include the following:
• Fear of the unknown: Users who do not want to move out of their comfort zone tend to imagine the worst in change. Typical questions brought up in the discussion on improvement are: “What if the new system does not do the job?”, “Has the time really come for a change?”, “If it is not broken, why fix it?”
• Fear of losing control/exclusivity: Users who have traditionally had exclusive rights or control over a legacy system may fear ‘losing out’ if there is a move to a more sophisticated, open and transparent system
• Fear of ‘collateral damage’: Talk of improved process control brings with it the usually unsupported concern over potential job losses; even if the new system is being brought in to keep in step with increased production or expanded operations.
• Inability to capture and quantify all potential benefits: If a company’s business processes and systems themselves are in need of streamlining, it becomes even more difficult to create the business case for a move up the technology path. In the case of HMI/SCADA, often strategic benefits are hardest to capture when quantifying benefits.
• Inability to get all users and stakeholders to provide synergistic input: The success of any move away from legacy control systems can only be guaranteed if all users and stakeholders (operators, managers, system integrators, senior management etc) are able to share needs, priorities, feedback and value perception; so that the calculated ROI truly reflects the benefit to the firm, as well as leads to action.
While proactive companies recognize that such barriers must be crossed, they also see the huge risk in not taking that step forward to more advanced performance-enhancing systems.
What do I risk if I do not solve legacy system issues?
• Loss in productivity due to potential downtime
• Loss in revenues due to control system limitations in keeping up with growing production, reduced leverage on energy savings and infrastructure cost savings, reduced ability to use modern analytical techniques etc
• Cost of maintenance of the system becomes prohibitive and total cost of ownership rises beyond previously estimated thresholds
• System components not manufactured any more or spares availability is a challenge
• Service / support not offered for older versions
• Reduced ability to link with modern business systems (ERP, MES, SCM etc)
• Reduced ability to comply with reporting requirements in safety/security/regulatory domains
• Reduced ability to respond effectively to incidents on the plant floor
• Reduced flexibility to grow the control system with changing operational needs (expansion in production or number of locations); especially if locked in with a proprietary legacy system
Fortunately, new technologies and solutions from the process control industry can help remedy the situation. In terms of software alone, the total global SCADA software market is worth around US$700 million today; with growth in excess of 10 percent per annum.
But how does one go about leveraging software solutions and making the necessary improvements?
How do I patch an old garment with a new piece of cloth?
The options are many:
Hot fixes are minor changes; typically a simple replacement of a file to fix a single bug. Low risk, but also, relatively little long term value (unless it solves a problem in a mission-critical process).
Service packs are minor upgrades to the software and contain a number of hot fixes. Low risk, but here again, relatively low long term value, although it should make your system more stable.
Upgrades provide users the comfort of staying in familiar territory, with the benefit of an improved suite of features. Companies that want their GUIs looking the same and do not relish the idea of retraining operators find much merit in simply ‘stepping up’ to step forward.
Perfectly logical, when your SCADA supplier also has a clear and sustainable development path for its suite of products. Higher risk than a mere service pack, but significantly higher value in the bargain.
Is an upgrade the best way forward?
The options discussed above appear clear in their risk-value position, and needless to say, each is adopted by users based on the need, context and priorities of the company.
Of the three, upgrades deliver most value in improving the organization’s leverage of new technology. Having said that, a few points must necessarily be introduced now, to muddy the waters:
• When faced with a need to improve the performance of their SCADA system, companies typically start with the options available with their existing SCADA vendor. Again, a sensible place to start, as long as the investigation does not stop with the incumbent vendor. In general, companies tend to start with the product and work back to their needs. Instead, companies would do well to ‘begin with the end in mind’ i.e. start with their changed needs, derive their new performance requirements and then widen the horizon to consider all potential solutions on offer.
Therefore, a straightforward upgrade of the existing system may not be the only way forward. For instance, questions that need to be asked and answered include: Is the existing system best suited for the needs of the organization? Were standards used for the existing system (and if the system is across multiple installations, are the standards uniform across all sites?) What other solutions does the industry offer which address my requirements?
• Apart from the obvious costs of purchasing new hardware and software for upgrades, companies tend to overlook the fact that upgrades necessitate a full testing of the upgraded system; a significant cost component that must be factored in when system ROI is calculated.
• Most importantly, not all vendors support early versions of their software and most do not have convenient and effective conversion tools to take old versions up the upgrade path.
• For some very old systems, upgrade options are simply unavailable or difficult to achieve if at all.
• To upgrade a legacy system, extensive documentation of the system is required. If such documentation is unavailable or inadequate, time spent on documentation for upgrade purposes can be quite high.
• It is often the case that operators who maintained the legacy system have left the company, and no one else knows how to fix or update the system when required.
• In some upgrade versions of legacy systems, certain features (that end-users want to retain) are dropped or missing. This means there cannot be a ‘one-click’ upgrade to the newer version.
Therefore if a company throws open the assessment and proactively researches the process control options available in the industry, the potential for migration to a new and perhaps more appropriate SCADA system may be considered.
The road less travelled
Migration paths can generally take two forms:
• Full replacement i.e. disregarding the existing system altogether and starting from scratch; or virtually ‘forklifting’ system architecture, components, directories etc.
• Migration i.e. moving to another improved platform without the risk that comes with completely ‘re-engineering’ the system
Full replacement or starting from scratch is doable; however it may involve more time spent in understanding the old system, creating a new architecture, validating/testing etc as well as considerably more risk than migration.
The chart below presents a simplified positioning of various improvements to legacy systems based on the cost/risk versus value matrix.
The cost/risk versus value matrix is useful not only in plotting the relative ROI of the various options, but also in comparing multiple vendors for the same option and making a choice of vendor on this basis.
For migration, a number of considerations influence the position of the vendors’ solutions in the matrix.
• Migration using standard industry-leading products promises less risk than full replacement starting from scratch.
• Migration costs, manpower, time, errors and risks increase when the exercise involves manually converting each component of a display/graphic page from the legacy system to the new platform.
• Migration that involves manual testing of each component in the project in all locations increases testing and rework time and cost.
• Migration that does not provide the flexibility to adjust for enhancements in functionality and usability reduces the long term value to the company.
The chart below shows the three key phases of pre-migration, actual migration and post-migration.
Getting it right
If a company decides to go down the migration path, the choice of conversion methodology and tools would depend on how well it can simplify the process, reduce the time and cost of conversion and still maintain reliability.
While some homegrown tools are used by system integrators to automate information entry tasks, the process control industry is still a long way off from the position of offering a range of full-functionality automated conversion tools to migrate multiple platforms from most major vendors.
However, one such tool available today is Switch2Citect from Citect; an automated solution that can convert various legacy systems to CitectSCADA. Switch2Citect stores the legacy system configuration into an intermediate generic format which then allows users to define the ‘what’ and ‘how’ of conversion. Enhancements in both functionality and usability can be made along the way. As one engineer remarked, “(An automated conversion tool) allowed us to convert our customer’s legacy system in far less time and with reduced risk compared to manual conversion. The project came in under budget and ahead of time – great for us and our customer.”
While automated conversion does have very tangible benefits, difficulties in code/script conversion, the different security models used and the variations in the way different brands of products reproduce displays mean that automated conversion cannot be used for all parts of the migration process.
However, when used appropriately, an automated tool delivers substantial savings in time, effort and cost of conversion. For example, a process mimic display (for simulation of a process) done manually could take anywhere between one and two days, whereas converting the legacy display using an automated tool would do much of the work in minutes, leaving plenty of time to put the finishing touches to the conversion with far less risk of introducing new errors. Additionally, if the automated tool allows the user to adjust the conversion rules, it is also possible to automatically add additional functionality, improve maintainability and introduce corporate standards. Automated conversion will also result in much reduced testing time.
In the end, migrating systems need not be a process fraught with error, uncertainty or the inability to enhance usability and functionality. If companies adequately research the available offerings from the HMI/SCADA industry, ask and answer the right questions, involve all levels of stakeholders in the process and look for tools to make the migration simpler and more efficient, the result will be a whole new level of process control performance with greater gains in flexibility, reliability and productivity.
Commentary provided by Citect/Frost & Sullivan