21st-century toolbox
Maintenance workers carry some tools that are recognized by everyone and others that are recognized by those with only limited mechanical work experience. Likewise, software maintenance and upkeep requires tools, and their use needs to be just as typical and self-explanatory. Ideally, these tools shouldn’t require training before being used by those responsible for the software. Usually, this means that they need to be provided on common platforms, like Microsoft-, or web-based interfaces.
One common tool for plant systems is a well-defined configuration management capability. (See “Digital technology spawns need for configuration management,” POWER, July 2008.) Plants must be able to compare a specific software configuration to an “as-built,” “as-required,” or “current” configuration. Some software vendors supply these configuration management tools and some don’t. Some tools supplied with an automation system work well; some don’t. Invariably, vendors focus on the initial design and development of their software, not on long-term life-cycle issues.
The data management toolset also needs to be consistent with the toolsets required of other software packages. For example, plants are typically designed using sophisticated computer-aided design software programs. “Virtual” plants are delivered along with the physical plant. If a virtual plant is going to have any “life-cycle” value to plant management, then the upkeep tools must be familiar and self-explanatory to those responsible for its maintenance. Owner/operators are demanding that the design data be provided in forms that plant management can use throughout the life of the plant. This impacts the tools selected by the engineering, procurement, and construction contractors to design the plant and “deliver” a virtual plant.
The service center model
One way to manage software life-cycle issues (and, for that matter, current software operations) is through the third-party service or partner model. With this approach, the software vendor essentially becomes the assigned “owner” of the plant’s software. Several power plant software suppliers now offer a monitoring and diagnostic service on a subscription fee basis.
One of the life-cycle benefits of this approach is that plant systems or components can be consistently benchmarked to those at other facilities of similar vintage, duty, operating life, and model number. Model-based software may be especially amenable to a services approach. Essentially, software design, engineering, revision, upkeep, calibration and retraining, and maintenance are managed by a third party, allowing the staff to focus on the power plant’s physical operation and maintenance, not software life-cycle issues.
Many owner/operators with large portfolios of plant assets have already converted to a centralized performance monitoring facility model where monitoring and diagnostic (M&D) responsibility either resides or is shared. (See this month's Special Report for a description of Entergy’s Performance Monitoring and Diagnostic Center.) Independent power producers and merchant plant owner/operators, who manage many of the latest combined-cycle facilities, depend on the gas and steam turbine supplier for 24/7 monitoring and diagnostics; related services providers collect, analyze, and manage fleetwide data for such machines. Now, software vendors with even more specialized, and often more complex, M&D capabilities are beginning to deploy the services model to power plants.
Going forward
Below are some specific recommendations for managing software life-cycle issues.
Measure to manage. You can’t manage what you don’t measure. Some in the software business talk of software quality assurance (QA). The diagram provides a high-level overview of the metrics being contemplated for QA evaluations of software.
Inspect, don’t expect. Software quality assurance evaluations often include these metrics. You can’t control what you don’t measure. Source: www.dcs.qmw.ac.uk/~norman/papers /qa_metrics_article/section_3_metrics.html
Hold implementation post-mortems. Plenty of meetings are held to plan a successful software implementation, culminating in the “go live” date. Post-implementation meetings should be held to determine what went right, what went wrong, who retains ownership, how to meet continuous training requirements, who handles software storage, and the like.
Conduct usability evaluations. This is an emerging area of analysis, as indicated by the recent publication of books such as Maturing Usability: Quality in Software, Interaction, and Value, by B. Jefferies, et al. (October 2007). Most power plant owner/operators assess products through the experience of their peers in power generation; formal usability evaluations may prove to be excellent supplements.
Outsource and partner. If your plant is not the flagship of the fleet, if power generation is not the “core business” of your plant owner, or if you are owned by a small utility, resources may be scarce. Even contemplating the purchase of performance-based software may be daunting because of a lack of expertise. The emerging service center model is ideal for these situations.
—Timothy E. Hurst, PE (timh@hursttech.com) is president of Hurst Technologies (www.hursttech.com), a consulting engineering firm specializing in instrumentation and control systems for nuclear and fossil-fueled power stations. He also is a POWER contributing editor.
Email
Comments
Print
Reuse
