1 November 2003

Living documents

Guidelines for control software organization and development.

By Marco A. Rodriguez

As no two painters paint with the same style, no two software programmers write code the same way. The primary goal of a painter is to produce a piece of art admired as a unique expression of the time and the moment. In the case of a software programmer, the primary goal is to write a piece of software that users will utilize, modify, debug, propagate, copy, and paste. An artist's painting is the product of the painter's inspiration. Software code is the product of functional specifications, hardware requirements, and validation criteria.

You always hear software programmers complain about the bad code they just had to debug. But you never hear a software programmer say he or she just finished writing a bad, unorganized, spaghetti-style piece of code.

There is vast agreement among control software developers about the characteristics of good software. Good control software is:

Structured: It flows in a logical way. It contains clear boundaries. Each section has a clear scope.

Modular: Each routine and program file is self-contained. Program blocks are as independent as they can be from the rest of the software. Modules configure as object-oriented pieces of software with handles to interact with other software modules.

Reusable: A by-product of modularity is the ability to reuse the software in other software applications. You can copy and paste program modules with minimal or no additional modifications.

Portable: The software is independent of the hardware in which it resides. You can reconfigure I/O with minimal effort.

Based on a known standard : The adoption of the IEC 61131-3 by many customers has created the need to base software on one of the several software control languages. This will enhance the chances of software portability, not only within a specific brand of technology, but to other brands and types of control systems.

Uniform: The programming style must be uniform, and transitions must be seamless. The software must look as if one person has written it.

Maintainable: A user should be able to make additions and modifications to the code with minimal effort.

Well documented : A user must document the scope and use of programming blocks, variables, and algorithms.

Well formatted : Indentations, capitalization, and spacing should make the software easy to read. This also translates to uniform location of variable definition and program blocks.

Robust: The software program should come with good exception-handling procedures. The program should be able to conduct a scheduled shutdown in case of a safety interlock event. The program should be able to recover after a power outage or an e-stop event. It should also be able to avoid unknown system states.

Reliable: The software should behave in the same way all the time.

Safe: Safety must be the top priority of every control software developer.

ORGANIZING SOFTWARE

Good and Bad Today's corporate environment is plagued with rapid employee turnover, furiously paced technology advancements, and a drive for flexible manufacturing schemes. Control software developers must make a conscientious effort to maximize the return on the investment. Cutting corners by implementing poor software development practices can only ensure headaches in terms of extended troubleshooting time, additional training requirements, frequent support calls, and expensive upgrades. All these headaches can go away by following good software development guidelines with a drop of old-fashioned common sense.

The task of writing software requires thorough planning of the software organization. The main objective is to provide a piece of software that satisfies the customer's requirements and meets all the characteristics of good software. In an effort to facilitate the development of control software, many companies document their programming philosophies and standardize software organization and implementation. This documentation becomes a part of the guidelines that represent a collection of common practices and proven techniques for control software development. Guidelines take into consideration the already installed control base and public standards developed by organizations such as IEEE, ISA, and IEC. Control systems integrators from all over the U.S. are adopting this approach. These guidelines address issues such as:

Operating system platform : Several operating systems are available in the market: Windows NT, Windows 95/98, Windows XP, DOS, Unix, and Linux, among others. Operating system specification should include version, service pack, and software patches when applicable.

Control platform : Define which control platform the guidelines apply to. Control platforms come in many different styles, including programmable logic controllers, PC-based, embedded control, and distributed control systems.

Control programming package : Every control equipment vendor has a suite of programming packages available to the user. New versions and revisions come as often as every six months. The specification of the control programming package must include version and revision numbers.

Control programming language : You should designate one or several of the IEC 1131-3 programming control languages as the preferred programming languages. The IEC 1131-3 standard defines the following set of programming languages: instruction list assembler-type language, ladder diagram, function block diagram, sequential function charts, and structure text. Using control programming software compliant to the IEC 1131-3 standard will guarantee future support and portability and will avoid obsolescence.

Major software logical modules : These software logical modules should be modular and reusable in other software projects. For example, the ANSI/ISA-S88.01 Batch Control standard provides a set of models and terminology for the development of logical groupings in batch applications. Software modules should be self-contained and independent of each other. Modules developed to control shared pieces of equipment (for example, a water header servicing several tanks) must include handshaking features to allocate the equipment software module to only one client. You must spell out the relationship between the major software modules. Other standards such as IEC 61499 and IEC 61804 describe techniques for implementation of function blocks in discrete control and process industries, respectively.

Programs memory allocation : Define memory allocation for each program file or subroutine if required. Nowadays, control software vendors are providing dynamic memory allocation. Program routines organize in a nested arrangement of folders. The guidelines should specify the major components of the control software such as initialization, recipe management, analog data acquisition, scaling, simulation modules, human-machine interface communication modules, exception-handling sections, and fault handling.

Variables memory allocation : Control software guidelines should cover the definition of variable data types and their grouping based on functionality. For instance, all data types related to digital outputs should get adjacent addresses. It is the same with digital inputs, analog I/O, alarms variables, operator interface data, proportional, integral, derivative (PID) instruction variables, recipe management variables, and motion control and motor operation variables. In control packages where the memory allocation of variables is dynamic, naming convention becomes the primary tool for allocating variables in an organized manner. Design a naming convention that organizes related variables in a continuous order in the database. Avoid storing all variables as global variables. A user should define subroutine variables as local if possible.

Documentation: Include a listing of the kind of software documentation, variable descriptions, and program comments expected at the end of the project.

Process/machine state diagram : De-scribe the acceptable process/machine states and transitions, and their relationship. Describe the conditions that will drive the system from one state to another.

Recipe management procedures : De-scribe how to manage recipes within the control system. Describe what privileges you must satisfy before accepting a recipe input, how recipe parameters should be validated, and how recipes are paused, resumed, and aborted. If an external supervisory control and data acquisition (SCADA) or manufacturing execution system conducts recipe management, specify which software package is running it, the communication network used by the recipe manager, and any communication constraints that must be satisfied.

Alarm handling features : Specify if the control system handles alarms or if an external SCADA system takes that duty. Describe how the system goes into alarm mode and out of alarm. Define if alarms latch until the operator acknowledges them or if they reset automatically after the alarm condition disappears. Define how the software acknowledges and resets the alarms. Define the actions the control system must execute when an alarm goes off.

Initialization and exception handling : Define the philosophy around initialization and exception handling. Ensure the software programmers include initialization and exception-handling routines in their software. Initialization must include the definition of initial state of equipment, motion axes, process set points, and operator defaults.

Routine execution frequency : Not all routines have to scan at the same frequency. For instance, some PID loops can scan as infrequently as every thirty seconds. You should configure these tasks as continuous, periodic, or event based. Make sure the software programmer is aware of optimizing the scan rate of the software.

Advanced control techniques : You should cover implementation of techniques such as cascade, ratio, and fuzzy logic control if required. Describe how to implement the technique within the software, along with addressing routine decomposition and routine allocation.

Control software guidelines should take into consideration the already installed control base in the factory. Reproducing the best-organized software will reduce the learning curve of maintenance personnel as well as reinforce software development practices within the company.

Companies have experimented with software module libraries. The intention is to create a collection of software modules that the company can implement in future applications. A user can encapsulate years of experience in software modules, allowing less experienced programmers to implement them with minimal difficulty. Unfortunately, this practice has not been widely accepted by the very same people that could benefit from it. Incorporate links to your software library in the software guidelines. Reinforce the practice of reusing software.

Software guidelines are living documents that must undergo revision every now and then. The basis of updates should be new technology developments. Moreover, companies ought to recognize that a unique guideline cannot fit all the software applications that they will encounter. Recognizing the value of following a structured approached to developing control software will translate into cost savings, software development cycle-time reduction, and easier troubleshooting. IT

Behind the byline

Marco A. Rodriguez, P.E., is a senior engineer at Corning Inc. His twelve years of electrical and control engineering began with Eastman Kodak Co. in Rochester, N.Y. Rodriguez holds an M.S. degree in electrical engineering from The Ohio State University and a B.S. degree in computer engineering from the University of Puerto Rico.

Return to Previous Page