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.

06/01/2009


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.

www.controleng.com


Author Information

Dennis Brandl is president of BR&L Consulting in Cary, NC, dbrandl@brlconsulting.com .




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 Leaders Under 40 program features outstanding young people who are making a difference in manufacturing. View the 2013 Leaders here.
The new control room: It's got all the bells and whistles - and alarms, too; Remote maintenance; Specifying VFDs
2014 forecast issue: To serve and to manufacture - Veterans will bring skill and discipline to the plant floor if we can find a way to get them there.
2013 Top Plant: Lincoln Electric Company, Cleveland, Ohio
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.

Bring focus to PLC programming: 5 things to avoid in putting your system together; Managing the DCS upgrade; PLM upgrade: a step-by-step approach
Balancing the bagging triangle; PID tuning improves process efficiency; Standardizing control room HMIs
Commissioning electrical systems in mission critical facilities; Anticipating the Smart Grid; Mitigating arc flash hazards in medium-voltage switchgear; Comparing generator sizing software

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

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.