We were recently contracted to automate and integrate data collection for an inspection process. Like so many systems, the majority of the data was already being collected by the control system, but then recorded manually by an operator and handed off to yet another person to be entered into an enterprise resource planning (ERP) system.
As part of our solution, we created a data structure, included additional data as requested, and created a unique identifier for the record set. However—despite the manual data collection process having been accurate for a number of years—the data being collected by the automated system was being reported as inaccurate.
Initially, the communication within the control system came under suspicion, but we were able to prove the communications reliable. Our evaluation then turned to the existing programming logic that was collecting the data, and what we discovered was a textbook example of “spaghetti code.” What seemed to be a simple data integration project had now turned into a costly rewrite.
Programming methodologies and design practices matter; not all are created equal. Good practices do not just happen. In his book “Professional Software Development,” Steve McConnell makes note of the expectation that there is an even distribution of effective and ineffective organizations. In actuality, he has observed a 10:1 ratio of ineffective to effective organizations, which he credits with the slow adoption of effective software development practices.
McConnell’s observations and studies have focused on the software development community, not controls and automation. However, for a number of years, programmable logic/automation controllers (PLCs/PACs) have been incorporating traditional software development capabilities. This includes some level of support for object-oriented programming practices. Adoption of effective software development practice has been equally slow within the system integration community. All of this contributes to a degree of customer skepticism as to whether they can expect things to be better anywhere. Yes they can, and should.
Effective software development methodologies will incorporate some level of object-oriented programming and abstraction, being both modular and scalable. The extent to which these practices are applied is very important, especially to the initial design. It is important to understand the goals and objectives of the customer in order to develop a representative scope of work. The higher degree of abstraction, modularity and scalability will result in more design time and be reflected in the cost. Future revisions, however, which are likely to happen over time, will be much less involved. Though these practices are foundational, not every solution has to be carried out to the same degree.
We can apply these principles to a simple fictional example: Line 1 at a bakery plant. In the design phase, Mixer 1 was identified as a module. Through abstraction, we create a generic Mixer object. We consider other mixers and look for common properties shared by all, including options such as start, stop, forward, reverse, discharge, mix time, etc. The functions remain encapsulated in the object while the properties are exposed and available to be called by the program logic. Objects are then named as specific instances in the program.
A pseudocode example:
Mixer1 = Mixer Object
Mixer1.Start
Mixer1.MixTime = 40
Mixer1.Discharge
After some time passes, Line 1 is modified to include an additional mixer to handle increased production requirements. With the Mixer object already defined, the modification becomes much easier to handle. This demonstrates a level of scalability. All of the same properties are now available to Mixer 2.
Mixer2 = Mixer Object
Mixer2.Start
Mixer2.MixTime = 20
Mixer2.Discharge
Additional functionality is also handled much easier; the customer determines a dwell time is required. The generic mixer object is then modified to include the Dwell Time property and then it becomes available to the specific instances referencing the object.
Mixer1.DwellTime = 10
Mixer2.DwellTime = 15
Real-world solutions are much more complex and involve other disciplines that contribute to the overall success of a project, with a well-defined project management methodology being essential. This post focuses on certain aspects of software development that apply equally to traditional software application development and program logic for contemporary controls solutions.
Because it’s intangible, the value of a well-developed software design process might be easy to discount. But a poor design process has the potential to be much more costly over time.
Larry Asher is director of operations at Bachelor Controls Inc., a certified member of theControl System Integrators Association (CSIA). For more information about Bachelor Controls, visit its profile on the Industrial Automation Exchange.
