At the moment, many companies in the manufacturing industry are in the same situation as IT was 15 years ago. As a result, many companies are turning their attention to IT project methods. Scrum is certainly the best-known method in this respect. However, the author is not aware of a single company in the OT world that made a complete switch to Scrum immediately. The companies always decided to implement individual parts of it step by step. The reasoning: The team wants to try to switch to more agile methods in order to save itself the long planning at the beginning and thus be able to start implementation more quickly, but management insists on a fixed completion date, fixed scope of functions and the availability of support.

The problem is that you either work agile or not. There is no such thing as semi-agile, because agile projects are based on many techniques and methods, all of which have their raison d'être. If you leave some of them out, the whole concept no longer works.

Typical sprint when tasks are added.

© Christofer Dutz /Timecho Europe GmbH

The difficulty here is that sprint planning is actually carried out to plan exactly what the team should implement in the upcoming sprint. The sprint is then frozen and the team can concentrate on implementation. Adding tasks to an ongoing sprint is considered a "mortal sin". The Scrum method for dealing with serious problems that arise at short notice is to cancel the current sprint, plan a new one and then start it. The usual way to deal with less urgent changes would be to schedule the items into the next sprint. Now there are always reasons why tasks have to be added. Usually it is: "The system is ready, we need to fix the problems now." A justification that is perfectly understandable and highlights the fundamental problem, namely that Scrum may be the wrong methodology for this task. Scrum is generally not suitable for areas of application such as support. Other agile methodologies such as Kanban are much more suitable here. On the other hand, Kanban certainly has major weaknesses in the classic project business.

One possible solution in such cases is to have two projects carried out simultaneously by one team - product development using Scrum and support using Kanban. The project team members are sometimes active in both projects at the same time and are assigned to the respective project on the basis of their usual workload percentage. So if a colleague usually works two days a week in support, they are scheduled to work 40% in the Kanban support project and 60% in the Scrum project. This gives the development project a certain degree of predictability without having to worry about system downtimes.

Automated tests and simulation

© Christofer Dutz /Timecho Europe GmbH

When it comes to testing, the automation world is by far the furthest behind the IT world - OT is estimated to be 15 to 20 years behind. The main problem with OT is that it usually relies on real hardware; in some cases, systems have to be built first. The tool manufacturers - i.e. the large automation companies - were also "asleep" until very recently and there are simply no established tools for the automated testing and simulation of systems. The author is not aware of any engineering environment in which "testing" is a fundamental component. Although there are approaches that allow rudimentary testing, their level of maturity is usually still a long way from that of solutions in the IT world, where testing is one of the most important pillars of quality assurance and this is reflected above all in the development tools and the number of tools available.

A lot is already happening in this area and there are initial solutions where a simulated PLC can be tested with a simulated system, but they are not yet in use. One of the most common arguments is that we don't have the time, money or both for testing.

A common experience in practice is that, with a lot of luck, it is possible to get hold of a PLC that can be used for testing. However, these are always the first devices to be taken away from the project engineers if there are delivery problems with the hardware and they are therefore needed more urgently elsewhere. This kind of prioritization illustrates the importance of testing in the world of automation. It is still the case that testing is usually always carried out on the real system; ideally scheduled during a shutdown or as part of commissioning, but unfortunately often also during ongoing operation at the weekend when the system is not in permanent operation. If something does not work as planned, this can cost a few working days or even the weekend that is needed to track down and rectify problems so that production can start up again.

The use of the cloud

© Christofer Dutz /Timecho Europe GmbH

Another trend that is currently spilling over from IT into the world of automation is the urge to migrate to the cloud. However, this does not apply to all aspects of automation. There is now often talk of cloud MES or cloud PLCs. However, such concepts have not yet been seen in practice. Although storage and computing capacity are both theoretically available in the cloud to an almost unlimited extent, they are by no means free of charge. Nevertheless, such a solution is tempting for some users. Presumably because the skillset that employees would need to operate a local big data and machine learning cluster is simply not available in the company. When using the cloud, there are several cost factors to consider that are important in contrast to traditional data processing:

• Internet or cloud connection costs: Not infrequently, it is important to block initiatives early on that want to bring all production data into the cloud. The reason for this is a simple calculation that shows that it would often not even be possible to provide the necessary internet connection or that the costs for this would be disproportionately high.
• Costs for storage and operation: If a company rents a computer from any cloud provider and operates it 100% of the time, this will always be more expensive than operating the same computer locally. The only exceptions are probably virtual servers, where several virtual servers share the capacity of a real server. Here, companies can save money with the cloud, as they can save on the procurement and development of specially trained personnel.
• Transfer costs: Cloud providers usually charge money for the transfer of data. If a company works a lot with its data, the transfer costs also increase. What many forget, however, is that the longer a company pumps data into the storage of a cloud provider, the more expensive it becomes to switch providers. If the company decides to change providers in the future, this can be very expensive under certain circumstances. How this will develop in the future remains to be seen: just a few weeks ago, Google made headlines with the marketing coup that the transfer costs for cloud transfer had been abolished.

What we are currently seeing in the world of IT is that some companies are in over their heads when it comes to cloud costs and are in the process of bringing their data centers back in-house. There are now also IT service providers who specialize in optimizing cloud costs for companies. But actions such as those taken by Microsoft are also ensuring that companies are taking a close look at the cloud issue: A few weeks ago, for example, Microsoft's discontinuation of its Azure IoT Central offering caught some companies thoroughly unprepared. At first, it looked as if they would have been forced to redevelop an essential part of their solutions within two months. In this case, Microsoft has probably rowed back and described the official announcement as a hoax. However, this has shown many companies how dependent they have become on cloud providers. It is therefore always advisable to ensure that you do not become too dependent on the offerings of a cloud provider. Only then can you react flexibly in such situations. It is therefore foreseeable that a certain cloud sobering up will also set in in automation and that the storage and processing of data will definitely find its way back into the company, at least in part.

The consequence

The upheavals that are currently shaking up the world of automation are mostly nothing new; other industries - especially IT - have largely already gone through them. Unfortunately, we are currently seeing many automation projects that are making exactly the same mistakes that we saw in IT years ago. Automation could therefore learn from another industry - it just needs to do so. Two examples:

The topic of agility: in order to avoid costly and lengthy mistakes, it is often advisable for those responsible to take a close look at the multitude of options. This is where IT consultants come in: Their useful contribution could be to develop a customized solution based on the current situation in the company and offer suitable training.

The author: Christofer Dutz is a Solutions Consulting Expert at Timecho Europe.

© Timecho Europe GmbH

Testing: There is a lot of catching up to do here. First of all, it would be important for the manufacturers of automation devices to offer appropriate solutions. As in the world of IT, open source could be an alternative. However, the industry itself would have to show more initiative in this respect. Open source offers a wide range of opportunities to work together with competitors on solutions that benefit everyone and that would not be feasible for one company alone.