Part 1 of Software Standardization for OEMs
Standardization in general refers to the harmonization of interfaces, dimensions, and procedures.
In the context of software, standardization refers to the creation of reusable software objects with defined interfaces and an architecture that enables the use of standardized software modules across many projects.
If that definition sounds a bit abstract, don’t worry — throughout this series, we’ll be looking at concrete examples of how to apply the standardization process to a robotic palletizer cell. As we work through this example, the concept of standardization will become more clear.
Here’s the important part for OEMs:
The aim of software standardization is to increase engineering and commissioning efficiency by reusing software objects. For OEMs, this increase in efficiency manifests as reduced costs, reduced time to market, and increased software quality.
Before we dive into the standardization process, let’s take a minute to discuss why OEMs should invest in software standardization and to look at the current state of software standardization in the industry.
End-users are becoming more sophisticated. They want more intelligent machines delivered in less time with less cost. For OEMs to meet the demands of their end-users, they need to work efficiently.
And standardization is the key to working efficiently for OEMs.
By investing in standardization, OEMs gain many benefits. The most important benefits of standardization for machine builders include:
Standardized software is more transparent since it uses well-understood modules arranged in a well-defined architecture.
This generally leads to fewer mistakes in automation software and simplified diagnostics and troubleshooting of machines.
Standardized software provides well-defined interfaces for external systems like SCADA and MES.
This reduces the costs surrounding integrating your machines into a production line and adds value to your machines.
Since software modules are reused across projects, less engineering effort is spent on each project creating software objects.
This increase in efficiency manifests as reduced engineering and commissioning costs and reduced time to market for machines.
By reducing the costs for a machine, OEMs can grow their profit margins. By reducing the time to market for machines OEMs can grow their capacity without increasing the size of their team.
Once a strong software standard has been defined, it is possible to use tools like code generators to automate the process of creating automation software.
In general, code generation is faster than manually creating code and contains fewer defects since the code is created based on a set of rules provided by the user.
Automation is only possible once standardization is implemented.
Although many OEMs pay lip service to software standardization, very few OEMs that I work with have implemented software standardization in an efficient way.
When I talk about software standardization, OEMs show me how they copy and paste software objects between projects and adapt those objects on a project-specific basis.
With this way of working, each project becomes a Frankenstein monster made up of similar but not equal software objects modified to suit a project’s needs.
There are several problems with this approach to standardization. The most important issues are:
Software objects are copy-pasted between projects and adapted on the fly. This means that no one is sure what version of the software object is the leading version, there is no documentation defining what functionality the software objects should provide, and no one is performing functional tests on the objects to make sure that this functionality is realized.
In short, the quality of these software objects is not assured and time is wasted on every project re-engineering and re-testing the software object.
When software objects are copied between projects and modified, it is not possible to see what changes have been made to the software object or why.
It's difficult, if not impossible, to understand which version of the software object is the latest version and what changes have been made to that version. Since there is no explanation of the software object’s history, it's difficult to tell if the behavior of the object is a bug or a feature.
In short, without version control it's impossible to tell what version of a software object you are working with and what changes have been made to that software object.
This series of articles aims to show OEMs the right way to approach software standardization to create a software standard that can be used across many projects.
The series covers not only the process of creating a software standard but also the process of maintaining a software standard using unit tests for quality assurance and version control for traceability.
The parts of this series are:
The Standardization Series aims to show OEMs how to standardize their automation software to increase their engineering efficiency, therefore reducing costs and lead times.
Although the focus of the series is on standardizing automation software, these principles can, and should, be applied to all aspects of automation projects. You can use these same principles to standardize other areas of automation and machine builder including;
The next part of this series focuses on the process of analyzing existing machines to identify standard software modules and architectures. Sign up to the mailing list below to be notified when that part is available.
Learn Logix Part 4.5. In this article, we learn about the various operating modes available for Logix 5000 controllers and the programming operations available in each mode.
Learn Logix Part 4.4. In this article, we learn how to understand and fix abnormal device states in RSLinx Classic.