Features. Information Technology: Managing software life-cycle issues

Power, Oct 2008 by Hurst, Tim, Corp, Hurst Technologies

face=+Italic; Software ranges from shrink-wrapped products available 'off the shelf' to custom corporate implementations of enterprise systems that require sessions with shrinks to keep everyone sane. Regardless of its complexity, every piece of software a plant uses, or interfaces to, poses critical issues that require life-cycle management. Although functionality has always been the chief specification for software, plants must pay far more attention to long-term quality issues. These two concerns are often at odds with each other.face=-Italic;

By Tim Hurst, Hurst Technologies Corp.

A recent survey of power plant owner/operators revealed that 'version control' is one of the most prevalent issues with software applications--along with having the right team in place to manage the software after the vendor's implementation team has left. (See 'Integrated software platform eludes many owners/operators' in face=+Bold; POWER,face=-Bold; September 2007.) In fact, these are only two of the many life-cycle software issues facing plant managers. Others include:

Cyber security--from mundane patches for the latest viruses to new code and logic to protect against criminal or terrorist activity.

Personnel training.

Tuning, calibration, and retraining of model-based software, collectively called configuration control.

Consistency in software tools.

Although software life-cycle management may seem like yet another paper-trail-creation exercise or an otherwise additional nuisance for a plant, the consequences of not thinking in terms of the bigger picture are real. Here's just one example: Twice in the same year at one utility plant, software systems were responsible for safety and reliability impacts during plant start-up simply because the staff could not find the current version of the system software.

face=+Bold; Like any other componentface=-Bold;

One way to think about the software life cycle is to treat a piece of software just as you would a piece of equipment in the physical plant. Software should be purchased, designed, integrated (with the computer hardware and other software), and maintained to satisfy a specific set of functions.

During the 'design' phase, you define the functionality required, write a specification, purchase or design the software, install and test it, and then turn it over to the plant. At this point, the software needs an 'owner,' just like any other plant component. The long-term care and feeding of software involves operating and maintenance considerations, as do physical components. Economic decisions about the level of maintenance for software will depend on its expected useful life. As with physical component maintenance, you will need some mix of corrective, preventive, and predictive software maintenance strategies, which will also require reviews, validation, and upkeep on defined, regular schedules.

At nuclear plants, where change and innovation only invites increased regulatory scrutiny and paperwork, software is generally expected to have a long life cycle. Nuclear facilities also have great difficulty managing things without paper. Even when they create an electronic document, they typically manage the information as electronic paper--as a simple electronic file. But it is simply too cumbersome to manage the life cycle of a digital product like software with paper. The volume and complexity of the information is too great.

Fossil plants are used to dealing with more frequent intervention in their software systems, frequently released new versions and revisions, enhancements (purportedly for efficiency and productivity), and even wholesale replacement after only a few years. Software suppliers issue service packs and revisions to add functionality to a device, to respond to customer requests, or to fix 'bugs' and flaws. Users also add or delete data points, change parameters, and reconfigure systems regularly. Plant safety, reliability, and performance are at stake if revisions and changes are not formally documented and managed (see sidebar).

Even when life-cycle management processes are implemented, owner/operators invariably underestimate the complexity of digital systems. The processes for dealing with software in the field either tend to be underdesigned or are overwhelmed and out of date shortly after rollout.

face=+Bold; 21st-century toolboxface=-Bold;

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,' face=+Bold; POWER,face=-Bold; 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.