Estimated reading time: 10 minutes

If It's My Data, I Can Do What I Want, Right?

The trend today for consumers is clearly moving away from mass produced goods to personalized goods made in a mass-produced way. The sheer number of variants and options in current products is testament to the expectations that modern consumers have. This applies to software as well as hardware, as “users” expect many options to tweak how applications look and operate. Often however, the available options or configuration doesn’t go far enough. Opening systems up for direct data access risks reliability and security as customers of sophisticated manufacturing systems want to integrate and customize their solutions by going directly to system databases. Hearing from suppliers that the certain data is not available for external use is not well received. The risk versus flexibility argument needs to be resolved, with a fresh approach.

A couple of years ago, I spec'd a new car, something reliable to get me to the airport on time, every time, and something that I could enjoy. Having chosen the model, there were the optional extras to choose from, which together created literally millions of different specification combinations. Being from a tech background, I was tempted by a few of the cleverer yet reasonably priced features on offer. Here is where I then learned that even the best-in-class automotive manufacturers in Europe don’t have a truly Lean business. It took many weeks for my car to be scheduled into production, and a few more after that to be delivered. Sure, the final assembly line itself is Lean; we know the suppliers of the electronic sub-assemblies are Leaner than ever before, but the customer ordering process is anything but Lean. Here is where the waste is cleverly hidden, having customers on the hook for payment, paying for the impression of Lean. How many people choose instead to go for an alternative simpler and quicker process? Many, I suspect.

A few weeks of life with my new car, with no major disappointments, though one thing did start to get annoying. Equipped with the latest LED technology headlights, brake-lights, and turn-signals, most other lights in the car utilized the old technology, heating up a thin brittle piece of wire until it is white hot within a vacuum inside a glass bubble. Fire and gasoline: a great combination. The waste of energy, the massive localized heat produced all around the car, just did not appeal to the engineer in me. A quick look on some Chinese websites revealed some amazing new LED technology to replace pretty much every old-school bulb in the car, without a significant cost. Now, with my car more fresh-looking and energy efficient, I wonder why car makers choose to save a few cents, if anything, to make my car look as though it was lit with feeble little wicks from lanterns dating back to the early part of the last century rather than going for a modern look. I was tinkering with options that were not a part of the car makers’ option list.

Replacing some internal bulbs in a car is one thing. I also read in forums that some owners of cars similar to mine were also changing the vehicle operating software. While some of these changes seem minor, such as to make the car default, to not cutting the engine when waiting at traffic signals, which seems (in my mind) to save a tiny amount of fuel compared to the wear and potential damage to the engine and related equipment. It opens up a couple of tricky issues. First of all, how do we know that the modified software is legitimate, that it is based on the latest official version from the car maker, and that it will work perfectly, given the plethora of connected software-driven devices in the car? What is the motivation of the person providing this "fix"? Have they introduced a "back-door" into the software with some ulterior and potentially deadly motive? The car manufacturer will surely cancel any warranty on finding out that such changes have been made, as the car maker can no longer be responsible for the behavior of the vehicle. Servicing and support costs, the fixing issues within the warranty period of cars could get prohibitively expensive very quickly, plus of course, the potential liability in the case of a serious accident. Then there is the insurance company, who most likely will feel the same way as the manufacturer, especially where cars today provide more and more aids through hardware / software technology. And that people are very likely to take for granted, after a very short time, their ability to decouple their thoughts from the actual driving. This whole area is an absolute minefield.

The risks associated with changing the software of a car are not too dissimilar to changing or "hacking" software on the shop-floor. Looking around a system database, there are many files, often with what may seem like meaningful file names, some which are human readable, such as in XML format. It can even be seen when these files are updated. This apparent simplicity however is just the "tip of the iceberg" of the layers of data storage and management within a manufacturing system. Most files within the system structure contain more data than is immediately obvious, with data fields that have inter-dependencies with other files. An XML file may sound quite standard these days, but the content itself is not standardized in any way. Take for example the import of design data. There may be a file created that appears to contain a list of reference designators, including such things as XY position etc. The file is likely to contain additional data, such as fiducial information, and also links to dependent information such as internal part numbers; material shape codes; vendor profiles; approved vendor lists; MSD profiles; etc., and in fact, potentially any information that could be needed to generate optimized machine programs. The file may appear to be the converted contents from design, but may in fact be a critical intermediate file in the engineering process of the information. Reading the data is not so simple, as not all records may be equally valid, with logical deletion being a common part of such formats. Changing, adding, or deleting records within the file is extremely likely to create corruption in the system as dependent links are not established correctly, or are broken.

In the early days of manufacturing and engineering systems in general, certain files, whether from solution providers or machine vendors, were shared with customers based on their demand. While this did make systems more flexible for the customer resolving immediate issues, it brought the risk that the operation could become unstable, as customers occasionally made mistakes with the reading, creation, or update of the files, causing data integrity issues, which lead to many bizarre and often urgent support issues, for which the system supplier faced additional support costs. This is one of the prime reasons that machine vendors and software providers usually charge for official supported interfaces, which have defined scopes and limitations. This is a technology issue, and also a business issue. No software supplier can accept changes introduced that may break the system which are not under their control.

In the light of the new IoT philosophies that are rapidly becoming the expectation, this problem of flexibility versus risk is resolved on the lower level, as IoT establishes the transfer and availability of data everywhere without the need for "hacking" into internal system database structures. This is a very good thing, as systems themselves can become more managed and secure. On higher levels however, risk can be expanded by at least an order of magnitude. The introduction of IoT technology is regarded by most already as a given, the only questions are how and when. Expected issues therefore need to be dealt with, two of which are:

1. Extent of IoT data exchange: If we pursue the course of the past in terms of data sharing, IoT data would be made up from simple messages, mainly as outputs, that would replace the vast array of made-to-order customer interfaces of all kinds that currently exist. Hardly a technical issue and it makes business sense, as long as a reasonable data standard definition, such as OML (Open Manufacturing Language) is used. The lesson learned, however from the past, is that information requirements from different customers in different situations varies considerably, and, it evolves. Looking at just one set of requirements, even for a major connected application, is not likely to reflect even a significant portion of the ultimate IoT data needs. Even with the ability of the IoT data exchange language such as OML being able to support the vast majority of requirements, each machine vendor, system provider, or local developer has to decide what data they want to share, and to what extent their solutions should interact on the IoT level. Whatever the data transport mechanism chosen, failure to disclose the extent of the IoT support to customers will result in disappointment where key expectations are not met, leading back to the situation where customized solutions are needed. Data output is just the start of the problem. When considering the data input aspect of IoT, that is the collection of data from other processes and/or site solutions, this becomes a far more complex issue as system or process operation may be asked to change, depending on the input data. This should be managed in a safe, efficient, and secure way an area, which is quite new for most machines and most software solutions such as ERP, traditional MES, etc. In this respect, apart from the output of a standard set of legacy data, we are at the start of understanding how IoT can and will impact our machine and system operations.

2. Security of IoT data: While data integrity within a stand-alone system can be managed and confirmed, once the data is sent outside, there will be additional security issues to manage. Of course, the IoT data transfer itself can easily be secured in a variety of different ways, many of which are available as part of the data exchange technology, and are proven. The more important factor in a controlled environment such as the factory, however, is what happens to the data once it is received by the intended party and is once more “open.” Few individual IoT messages in themselves will carry much importance. Together however, a great deal of information about the operation and products that are made can be gained. Information about performance of competitor systems may also now become freely available. Restrictions such as ITAR also still apply, so routing and utilization of information needs to be carefully managed, especially where data is stored in a cloud, which may physically reside across many different systems, and across continents. Though potentially more widespread with IoT, these issues are still similar to legacy issues of today. Once again, the real threat comes when we start to think about the true nature of IoT, where commands or requests may come in to processes and systems from outside, albeit over a secure interface, intended to control and manage the operation in a better way, which could also have been created by systems or flows that have been compromised.

It is like the "back-door" that may have been introduced into your car’s software through an innocent looking update. We hear already about cases where hackers have managed to get live access to a car as it is driving; to open windows, turn on lights, activate emergency braking, etc. The risk in this case is easy to understand. The same risks however, are there in manufacturing with IoT in the future. With machines, processes and systems now becoming dynamic, receiving live external communication that modifies their behaviour from outside, we face the same kinds of security concerns, except that with billions of IoT transactions potentially per day in a factory, it is going to be hard to track. The continued and professional management of IoT standards, as well as systems that adopt them, and environments that facilitate them, is critical. The IoT-based application layer is now more exposed and available to a wider range of solution providers as well as machine vendors, and so is the layer in which most risk will be faced. Many of these applications will be made by customer IT teams, bringing us back full circle to our original problem of data and system integrity issues where customers need to gain additional connectivity, flexibility, and control. The knowledge and understanding of IoT-related IT skills should grow alongside the technology, or all IoT solutions must be provided by trusted suppliers. Nothing in this regard has really changed, but the stakes are now far higher. It is time to take this seriously.