TRUST in software engineering

It seems that every generation needs to relearn the lessons of previous generations. This is equally true in manufacturing, where older engineers are retiring and must pass on knowledge to younger engineers. Unfortunately for manufacturing software, there are actually few lessons that can be passed on.


It seems that every generation needs to relearn the lessons of previous generations. This is equally true in manufacturing, where older engineers are retiring and must pass on knowledge to younger engineers.

Unfortunately for manufacturing software, there are actually few lessons that can be passed on. Much of the knowledge required for robust manufacturing software development is not known to older engineers. The languages, tools, and methodologies for software development have been continually evolving and changing during their careers.

Manufacturing software lessons must come from outside manufacturing disciplines and should come from the software engineering discipline. Many of software engineering’s lessons were acquired through the development of large systems that had lifetimes of dozens of years. This is a familiar situation in manufacturing, even as it is becoming increasingly rare in modern non-manufacturing and non-regulated software systems. Many modern systems are designed for short lifetimes—five years at most before replacement—and it is assumed that the original programmers will be available for maintenance. Fortunately, developers of manufacturing software can learn from traditional software engineering rules.

One of the harsh truths about manufacturing software is that is it not developed by software engineers or computer science majors. We would not regularly ask an electrical engineer to design a mechanical system, or a chemical engineer to design an electrical system, but we often ask mechanical, electrical, and chemical engineers to design and develop software systems. If you are in this situation, you should TRUST software engineering methods.

The “T” represents try-outs and prototypes. Engineering disciplines use physical or mathematical models to understand the basic concepts and relationships of a system. Prototypes perform the same role for software. Prototypes can be throw away try-outs or incremental design elements, depending on your development methodology. However, they should be a common starting point for all projects.

Just because someone has a good concept for a software project does not mean the project is doable. A try-out confirms that the concept is technically feasible. By analogy, in automotive engineering, just because someone imagines a car that gets 300 mpg does not mean that it is feasible. Prototypes prove or disprove the feasibility.

The “R” represents requirements. Once you know that the project is technically feasible, you can write the user, functional, and design requirements. These requirements document what must be done and how the final system must operate in your manufacturing environment.

The “U” represents use cases. While requirements documents are important, they do not document how the software is to be used by the end user. The use cases define normal operating methods, and expected error conditions and responses. The use cases are designed to help the end user understand what will be provided.

The “S” represents source code, standards, and build scripts. Source code should be developed only after you understand the requirements and use cases. It can be developed in small chucks if you follow an agile project methodology, or in large chunks if you follow an iterative or waterfall methodology. Commenting, configuration management, and copyright standards must be applied to all generated code and documentation. Build scripts allow for daily or weekly automated recreation of the project software on a fresh system, eliminating manual errors and configuration issues.

Control Engineering software
The “T” stands for test cases and test scripts. These are the detailed definitions that are used to verify that the software operates as specified under normal and error conditions. Software is not ready for deployment until it has successfully run the test cases. These are the final proofs of correctness.

TRUST in the lessons learned from software engineering and apply them to your projects.

Author Information

Dennis Brandl is president of BR&L Consulting in Cary, NC, .

No comments
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
A cool solution: Collaboration, chemistry leads to foundry coat product development; See the 2015 Product of the Year Finalists
Raising the standard: What's new with NFPA 70E; A global view of manufacturing; Maintenance data; Fit bearings properly
Sister act: Building on their father's legacy, a new generation moves Bales Metal Surface Solutions forward; Meet the 2015 Engineering Leaders Under 40
Cyber security cost-efficient for industrial control systems; Extracting full value from operational data; Managing cyber security risks
Drilling for Big Data: Managing the flow of information; Big data drilldown series: Challenge and opportunity; OT to IT: Creating a circle of improvement; Industry loses best workers, again
Pipeline vulnerabilities? Securing hydrocarbon transit; Predictive analytics hit the mainstream; Dirty pipelines decrease flow, production—pig your line; Ensuring pipeline physical and cyber security
Upgrading secondary control systems; Keeping enclosures conditioned; Diagnostics increase equipment uptime; Mechatronics simplifies machine design
Designing positive-energy buildings; Ensuring power quality; Complying with NFPA 110; Minimizing arc flash hazards
Building high availability into industrial computers; Of key metrics and myth busting; The truth about five common VFD myths

Annual Salary Survey

After almost a decade of uncertainty, the confidence of plant floor managers is soaring. Even with a number of challenges and while implementing new technologies, there is a renewed sense of optimism among plant managers about their business and their future.

The respondents to the 2014 Plant Engineering Salary Survey come from throughout the U.S. and serve a variety of industries, but they are uniform in their optimism about manufacturing. This year’s survey found 79% consider manufacturing a secure career. That’s up from 75% in 2013 and significantly higher than the 63% figure when Plant Engineering first started asking that question a decade ago.

Read more: 2014 Salary Survey: Confidence rises amid the challenges

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.