Within manufacturing IT and OT systems, we often forget that there is a world of IT out there that could help us in many ways.
I was reminded of this a few weeks ago when chatting on the golf course. My playing partner works for NATO on very large distributed systems across Europe for ground based early warning. He said the biggest problem they have is the software release process. My reaction at the time was, “With systems that big, are you surprised?”
As you can gather from my writing, the thought never really went away. I started thinking about industrial products and plants, and their software from ERP to plant floor controls. Is software release a problem for us? Do we have huge complexity, geographically distributed systems, and a multitude of different software platforms? Well...yes, we do. Keeping all this stuff up to date is a major nightmare, one that is not going to get any easier as software becomes ever more distributed in our Internet of Things (IoT) world. In this blog post we will take a brief look at software in the plant, and running in the product.
Software as part of a product has been around for some time. The first computer in a car was in the 1970s. In the next few years we will see the processing power of our cars far outstrip the power and complexity of the device on which I am currently typing. When you take your car for a service, the most likely modifications are software upgrades. Indeed, Tesla sends software releases directly to its cars via the built-in Internet connection. However, it is not how we get software into our cars, but instead which software that really matters. The challenge for manufacturers of complex products is the management of software across the whole product and its lifecycle.
During product development hardware and software are developed in parallel. There should be a clear process for software release that includes various classic software development phases, such as alpha and beta test and final release of the software. In our example of a car, software testing will take place before and during the testing of the car itself, as one would expect. At some point, a software version is released for production. Normally, it will then go in the PLM system, possibly as a part or document, and be loaded into the correct microprocessor in the car. This release cycle should be fairly mature for many manufacturers today, but what happens next is more interesting.
In recent weeks there have been some very high profile stories of cars being hacked over the Internet. This should hardly come as a surprise given the nature of hackers,, whether with good or evil intentions, and their penchant for dramatic stories. What came as a great surprise to me was that control and entertainment networks were insecurely linked in at least one case. On a more positive note we see great headlines from Tesla carrying out major functionality updates over wireless networks while its customers' cars are parked. Other manufacturers are starting to experiment with live updates on a smaller scale. As confidence in the security of communication increases, the upgrade of functionality by download will become the norm.
Software release and tracking of updates will need a wholly new approach. First, the need to keep an “as sold” and “as maintained” record for all cars is imperative. So that way you know what has been uploaded, what options are live (options including performance are only disabled in software rather than having specific hardware), and what version of all relevant components are installed. Software updates, whether done over the air or in the garage, will include appropriate software versions along with configuration files, potentially for every vehicle to be upgraded or fixed. Software lifecycle management will need to become a part of every complex manufacturing company and indeed to those who sell control and management systems to such discrete manufacturers.
While managing software out in the field seems like a fairly daunting prospect, I would expect software release for factory control systems to be straightforward. This is something that all control system companies plan and execute with their customers. Unfortunately, we all know this is not the case. Most industrial control systems get upgraded very rarely, if ever, and often interface to obsolete hardware and operating systems, which can result in causing all sorts of security, reliability and usability issues. The reasons for this have been discussed many times before, and change is needed.
It is not quite the cavalry on its way, but there is hope for both scenarios. One of the fundamental promises of IoT based solutions is self-contained distributed systems and smart connected devices, with the Internet connecting them together. These dispersed solutions with their own built-in intelligence will allow a more controlled process for software release. Intelligent devices will be able to communicate with systems before software is released to production. The capabilities will be pre-defined and if these are changing, the effect on other smart devices can be controlled. So, we have another thing that needs to be put on the long list of “Getting ready for IoT.” Address your software development and release processes, and bring them up to a level that will enable you to support your end consumer and business customers in an IoT distributed world.
Research Fellow Dan Miklovic explains how the pace of technology change is turning standardization in the industrial automation world upside down
LNS Research Principal Analyst, Dan Miklovic, details the recent LNS event, the Smart Manufacturing Roundtable.
LNS Research Principal Analyst, Andrew Hughes details the importance of security in MES.