Ten control system programming best practices

Best practices for programmers include defining their structure, knowing the system resources and tools, consistency, and keeping track of changes during a project.


Courtesy: Cross CompanyControl system programming is an art and a science. Utilizing multiple tools, languages, and functions allow engineers to produce a creative solution. However, due to the multiple methods and tools available, the road to success can vary greatly depending path chosen. Programming standards are methods of coding that have been declared acceptable and are typically defined and supported by control system vendors.

Closely tied to programming standards are "best practices," which outline recommended methods and strategies to follow when applying and deploying programming standards. Best practices may also involve the addition of extra code segments and/or removal of redundant or dead code that are not used. Best practices are recommended ways of writing a segment of code, whereas programming standards are a specific set of rules to apply to coding style and techniques. These 10 best practices can help provide a baseline to help ensure consistent success for the programmer.

1. Define the structure

When developing a program from scratch or augmenting an existing program, the programmer must step back from the details and define a structure. This provides a clear plan of how to divide up the functions, variables, and provide a logical arrangement. Segmentation of functions allows for a design that can easily be expanded and followed by other programmers.

Start by developing a visual diagram of how the code will be structured. In some cases, the programmer can clearly outline this structure within the actual code. This is comparable to building a legend table within a drawing and it should provide a map of how the program will be structured and/or any segmentation and development notes to clearly outline so the next programmer will be able to follow the same methods. This structure should include both the controller code as well as the HMI programming.

2. Supporting documentation for developing functions

Supporting documentation of functional requirements and/or specifications is essential to allow developing functions.

Just as important are supporting documentation of the programming standards that will be used to achieve the objectives defined in the specifications. Most distributed control systems (DCSs) have a standard library that outlines how each functional element will be configured, such as a valve, motor, PID, etc. that has supporting documentation. However, in other applications like PLCs, the structure does not exist and must be documented and developed.

The supporting documentation does not require a lengthy formal document but it must clearly outline the structure and programming standards that will be followed. A simple spreadsheet can be used to relay this information. However, the ideal location for this information is the actual program itself to ensure the standards are always coupled with the code and not misplaced.

Image courtesy: Bob Vavra, CFE Media3. Plan for change

When developing a system, it is important to plan for future expansion, changes, and reductions. When the programmer is defining the structure, they should always be aware of potential changes and ensure that they do not paint themselves into a corner. Do not outline limited strategies that could potentially cause a change in strategy. For example, if the programmer segments the memory locations for each data type, be sure to have plenty of room for changes and/or expansions of the system in the years to come.

In addition, it is always a good idea to outline the structure on paper to visually identify how the code will be segmented and introduce some potential changes to test the organizational structure of the design. Planning for change is difficult because you don't know what you don't know. It is always recommended to review the concept with other more experienced engineers to ensure the obvious is not being overlooked. There is a balance here between planning for extra-scope future expansions and meeting the requirements. Allow for future expansion, but do not devote significant resources to out-of-scope development.

4. Know the system resources

System resources are a vital part of what makes software run efficiently and the last thing the programmer wants to do is overburden the system's capabilities, which could cause latency or even crash the system. This issue was more prevalent in years past due to memory and processing speed limitations. Technology has advanced and the programmer now has much greater capabilities within a system to provide a more structured and organized code. However, the resources are not unlimited and it is always good practice to understand where the limitations are and how the structure is impacting those resources.

This is accomplished by performing a loading test, which will help the programmer get a feel for where the limitations are. To do this, create an application with extensive loading using additional structure and routines that are far outside of the existing scope that is trying to be achieved. Not doing this is irresponsible. The programmer would be blindly adding structure and overhead processing requirements without knowing how much room you have to grow the application. A resource test may require multiple application expansions, but finding the limit is crucial for success.

5. Reuse code

The easy part of control systems is that we continually reuse of the same functions to achieve the logic task at hand. The programmer does not want to hard-code the same functions over and over, which would incur additional costs such as increased memory, processing speed, and extra time to make changes to an application that is programmed not utilizing function calls.

By separately coding common code, the programmer also introduces an opportunity for error down the road because changes to one instance must be accurately copied to all other instances by hand—an invitation for human error. All functions that are used should be referenced from a single sources library and called when needed. This will require the programmer to code the functions on a general level and, in some cases, they may want to include additional parameters or variable to help the function account for different or additional attributes. This will allow the management of these functions to be common instead of isolated by system requirements. Meaning, you do not want to create a library of existing functions and end up managing an unmanageable library.

<< First < Previous Page 1 Page 2 Next > Last >>

click me