As consultants/system integrators, we spend a lot of time working to bridge the gaps between technology on the plant floor and technologies used throughout the enterprise. Keeping abreast of technology trends, we see the adoption of technologies trickle from the web, into the enterprise, and eventually to the plant floor. The adoption rate for manufacturing software vendors and solution providers can, at times, be painfully slow.
Some of this conservatism is very necessary as the lifecycle of solutions can be much longer than the latest web craze. Add to that the inherent risks to life, safety, and business inherent in manufacturing systems, making a conservative approach wise. However, there are a few technology trends that I feel are ripe to be introduced in manufacturing systems.
This is not intended to be a complete list, but a starter for a larger discussion on the adoption rate in our industry and what is and should be appropriate.
In case you missed it, open source software is running the world. Open source is no longer the land of alternate software developed on the fringes of the real businesses. Leading technology companies are not only sharing the source code to some of their core products, but they are also opening up their whole software development life cycle to the community, accepting contributions and deliberating the merits of features for the world to participate. This has increased the pace of innovation substantially.
The results are compelling. We see Microsoft adopting and supporting software developed by Google (AngularJS). Google, likewise, has adopted Microsoft’s typescript language as the foundation for some of its projects. Each company benefits as they all use and contribute to these open source projects.
In the world of open source, companies are finding success in contributing to the whole software community. We often see the “freemium” business model where core technologies are released as open source products, while additional components like support, advanced features, management tools, etc. are sold to enhance the core product. You can see this at work with Oracle’s MySQL, HortonWorks and their solutions around Hadoop and data analytics, among others.
In the automation world, we are great at defining standards, but the software vendors develop their solutions based on the standards independently. This results in many different interpretations of the standard and often fails to interoperate with any other solutions outside of that particular vendor. In order for open source to take hold in manufacturing, one of the major vendors is going to need to lead, following the examples of other technology companies like Microsoft, Oracle, Salesforce, and IBM that are not only using open source products, but they are also creating and contributing to open source projects.
Desired State Configuration
In another case of the web scale driving technology, we come to the concept of managing infrastructure as code. As companies develop software for mobile and the web, they find that the need to scale their infrastructure to grow and/or shrink with demand is essential to keeping their businesses viable. Lead times in weeks or months to provision and commission new servers is unacceptable where the opportunity to grow the business expires in hours.
Desired state configuration seeks to shrink this lead time to minutes by allowing an architect or IT professional to define all of the configuration for a system, including any operating system settings, software to be installed, required configuration for applications, etc. The technology also can be used to manage deploying configuration changes as needs change and to ensure that deployed systems stay configured as required.
In industrial automation technology, desired state configuration could greatly simplify the validation process for controlled industries and provide that much-needed bridge to enable end users to keep up with updates and security patches. Besides the obvious benefits in upgrading as existing infrastructure ages. If employed, it could remove the upgrade barrier seen all too frequently on the plant floor.
Unit Testing Frameworks
In traditional software development environments, the concept of automated unit testing is commonplace. The concept is that in addition to writing application code, testing code is written based on the requirements to exercise the code and determine if the requirements are satisfied or not. The benefits of testing like this are huge. First, the requirements are codified, and results are verifiable. Second, as the software matures, new features are added (along with new tests), bugs are fixed, and the unit tests are there to continue evaluating the software to flag for any regression. Finally, automated testing can be used as a defense against the tendency to gold-plate applications, adding features and complexity that is not needed. If the unit tests only cover the required functionality, then the software developer should only write enough code to pass the tests.
In manufacturing, especially in regulated industries, requirements and quality control are critical. Having the ability to verify the functionality of an SCADA or MES System against user requirements in quickly, in an automated way, would revolutionize our ability to rapidly iterate and deliver value to our customers quickly and with confidence. It also allows customers to put up their own safeguards to protect their operations from losses incurred during lengthy system commissioning.
The wide array of open source libraries has brought on lots of package management tools like NPM, bower, NuGet, etc. that allow a developer to specify the package dependencies for their application. Each package specifies any other packages it depends on and the versions it is compatible with. The package manager handles the mapping of all of the project dependencies, determining what versions will work for the specified packages and downloads all of the required files.
In whole, these tools allow a solution architect to compose their solution of best of class tools, tools that fit the project requirements without accepting compromises because we are locked into one companies application framework.
In the manufacturing space, it is much more common for one technology decision to bring compromises in other technology choices. For example, if I choose Vendor A’s MES solution because it offers best in class quality management, then I may be forced to accept the authentication methods supported by that vendor, even though they may not work as needed. Likewise, I may be forced to buy additional software from Vendor A because another vendor’s solution may provide best in class inventory management but cannot be integrated to work alongside the Vendor A solution.
Over the past 12 years, we have seen server and client virtualization technology adopted in the manufacturing industry. Clients are much less likely to limp along with old hardware, risking serious downtime because the software and systems installed on that machine are too complex and risky to attempt to replace. Virtualization solved the aging hardware problem by separating the operating system from the hardware via hardware virtualization. However, the problem with overly complex installations and risky upgrades is still a deterrent preventing system owners from upgrading, applying security patches, etc.
Containerization technologies like Docker are the next stage of virtualization technology, allowing the application to be virtualized independently of the operating system. In a docker container configuration, the application and its execution environment are defined, along with mapping how the application can access other systems, persistent storage, and hardware.
With containers, a solution architect is free to define a solution based on the applications required, how they interoperate, and how they can be scaled. What hardware platform they are running on is inconsequential to how the applications function.
In manufacturing, a containerized architecture would simplify upgrades, security patches, maintenance, and deployment of new features and services.
While I say that the technologies mentioned above are missing from our industry, I am sure there are companies out there leveraging them. However, the larger players in the market don’t seem to be making much progress toward any of these areas. I will continue to lobby for these in my conversations with partners and at industry events. In the end, our customers and our solutions will benefit as we see these technologies adopted.
What is your experience? Are you seeing any evidence of these technologies on the plant floor? What other technologies do you feel were left out?