The interview was conducted by Stefan Kuppinger. It was published in IEE issue 07/18.
The key points in 20 seconds
- CODESYS Automation Server brings transparency to controller landscape
- Web-based tool allows for SW backups and downloads
- Central instance for security patches and firmware updates of the machine park
- Compatible with CODESYS V3 and V2 (with some exceptions)
- Linking of external controllers planned
- Web-based programming to be followed up in stages
Mr. Hess, Mr. Werner, you seem so relaxed so soon after the Technology Day. What's your verdict?
Manfred Werner: We're happy that so many people came. It's definitely not a given that 400 people from all over the world make their way to Kempten in the Allgäu region. Obviously, we've hit a nerve with our topics.
CODESYS isn't just any engineering system. As a consequence, automation specialists are undoubtedly curious when there is an outlook on the upcoming technology version 4 of CODESYS. ((question modified))
Manfred Werner: The current version is CODESYS 3.5 – and we'll continue this version for a very long time. Version 4.0 is not required in order to use new base concepts such as web technologies. A brand new version would usually be accompanied by incompatibilities. We can dispense with that in this case.
Are web technologies a market requirement? And what do you actually mean by this?
Manfred Werner: The new capabilities of the CODESYS Automation Server, which we will talk about later, are demanded by the market, as is OPC UA as an interface. The same applies to extended operation via web technologies. We have established our web visualization for some years already. Now it will experience an extension, including HTML5. Web elements from other providers can also be integrated in the future.
Dieter Hess: The entire user interface of the Automation Server is designed as a web interface. In the future, engineering will also develop in the direction of web technology. For an established system, this is a novel approach with many solid advantages.
Would you please outline these advantages?
Manfred Werner: Programming a controller via web technologies has considerable advantages in project engineering, archiving, and maintenance, as well as for future extensions. This is because it is not only an implementation technology, but using web technologies also allows for new interesting use cases, such as small changes or rewiring per tablet.
And we see the chance of implementing this web programming without a technological shift from traditional desktop-oriented engineering. We have already started initial developments in this direction and presented them at the Technology Day.
What do the first steps look like?
Dieter Hess: As the first component, we have designed a topology editor that runs both in CODESYS on the desktop and remotely as a web editor. So we can gradually pull more editors from CODESYS and offer them as web editors for browsers. This is the path we want to take in the long term – and without any system disruption, simply as an additional option. The advantages of a central platform for CODESYS controllers, which the Automation Server will offer us, will take effect much earlier. The very idea of having a central tool that registers and manages all the controllers in a production plant and that I can use to update and back up data holds enormous savings potential.
The Technology Day was the kick-off for the migration project from CODESYS desktop to CODESYS web?
Manfred Werner: This is just one aspect that will not really take effect for a few years. Much more decisive is the aspect of controller landscape administration, which we address with the CODESYS Automation Server. In addition to the engineering tool and the CODESYS runtime, this will form the third pillar of our future product portfolio. In the future, this server will be used for networking all devices programmed with CODESYS, executing services on all these devices simultaneously, installing updates, installing backups after device exchange, or collecting live data centrally and making it available for other cloud services.
Of course we see security as an absolute must. If the controller world is to open up towards the cloud and the Internet of Things, this cannot be done without comprehensive security measures that can be applied in practice. We are therefore investing heavily in this area. .
Dieter Hess: By the way, the Automation Server is not primarily about engineering. Rather, you can imagine the server as a management layer to be able to conveniently manage and administer controllers in the network. And this also works with V2 controllers, although somewhat limited. Our long-term goal is that a program download will also work for third-party devices in the future, but certainly not to the extent that we can achieve with CODESYS-compatible devices.
To what extent did you involve your users in this strategic project?
Dieter Hess: We talk regularly and closely with our customers to find out which requirements they see in the future. However, we have developed the server on our own initiative. We had the CODESYS end users in mind, who prefer a manufacturer-independent solution because they usually use machines with controllers from different manufacturers in their production.
Can OEMs also label the CODESYS Automation Server as their own solution, as with PLC runtimes?
Manfred Werner: At the beginning of CODESYS, when the big brand labeling products were created, our platform was not quite perfect. You just have to admit it. As a result, the companies had to create additional functions. Therefore it is already quite legitimate that these tools received proper names. With the Automation Server, however, this will no longer be necessary, since it will be a well-rounded package right from the start.
Dieter Hess: The Automation Server is designed for operators of controllers. The fact that they all come from the same manufacturer would be rather uncommon. Therefore, unlike the CODESYS Development System, brand labeling makes no sense there. However, there are plans for a partner program in which third-party vendors or OEMs can provide their own functions for the Automation Server.
When did the conceptual considerations begin?
Dieter Hess: We started with the first drafts about three years ago.
If web programmability, then which programming languages will be available first?
Manfred Werner: In the next two or three years, the CODESYS Automation Server will not focus on web programmability, but on device management. "Webability" is only the second step.
Dieter Hess: A typical use case of device management is backup and restore. You have a machine that runs 15 years wonderfully, until the controller fails at some point. What are the automation specialists doing today? You usually first have to find an old laptop with the right programming system. And then you have to somehow get to the sequence program and get the machine up and running again. All this takes time that nobody has anymore.
This is done in five minutes via the Automation Server, since it stores everything in one central location. The right software version, the sequence program and all information about the PLC hardware. The server stores which controller is required. After hardware is exchanged, the application saved on the server is installed on the new hardware. This is a typical scenario that cannot be solved so quickly and easily right now.
Manfred Werner: Another example is security updates. On the web interface of the Automation Server, you can see immediately which robot or machine is equipped with which controller version and which security patch has been installed. If necessary, you can react immediately.
The requirement is that all machines and controllers are connected to the power mains. What is the reality for end customers?
Dieter Hess: There's an important point you're raising. Not all end customers want or are able to connect their applications to the network. After careful consideration, we therefore decided to offer the Automation Server in two variants: as a cloud service and as a local installation. With the cloud service version, all devices must be connected to the Internet via an edge device. If you don't want this because you have reservations about storing data in the cloud, then you can install the Automation Server on your own server in your factory and operate it locally.
That's why the effort concerning security is so high. What have you done in that respect?
Manfred Werner: In general, we comply with applicable standards such as IEC 62443. We must differentiate between the individual measures: There are the security measures for which we as the supplier of the development environment and the Automation Server are responsible, and additional IT security measures on the part of the operator. If we are using a cloud provider (we will be working with Amazon and Microsoft on this), then we rely on their security mechanisms. They will make sure that data is not lost or manipulated. These vendors are the largest cloud providers in the world and are at the cutting edge of data security.
Of course, safety precautions also have to be in place for the controller itself. In the factory, the devices are installed in a relatively protected area. The fact that in this environment a controller is directly connected to the Internet - without a firewall or such - does not happen very often. With decentralized installations such as wind turbines, pumping stations, or buildings, it is more common for a device to be connected directly to the Internet. Therefore we have invested a lot to encrypt the communication with the device and to improve the password mechanism. And we're working on making it easier to update the firmware if a vulnerability is detected.
For the future we imagine that the runtime of a controller is separated into two parts: a security-relevant part and the rest of the system. Then, as with Windows, we can install security patches while the system is running.
Without operating the run/stop switch?
Dieter Hess: That's the goal, because in practice users hardly react at all to security issues. After a security alert, we usually provide our customers with a patch within two days to resolve the vulnerability.
What do the users do with it?
Dieter Hess: This is exactly the question we asked at the Technology Day – whether anyone has already installed an update on their runtime system after receiving a security alert from us. The answer was sobering: not a single one!
Manfred Werner: Via the Automation Server, we want to notify users that a patch is available for their device with a certain firmware version. If they agree, then the update is installed automatically, if necessary also time-delayed in order to wait for a pause in production.
In a factory, there is never always just one type of controller. How do you portray this heterogeneous machine park?
Manfred Werner: We anticipate that there will also be more comprehensive interfaces for engineering, such as OPC UA. OPC UA is a standard that is manufacturer-independent and allows data exchange across manufacturer boundaries.
PLCopen currently has a team working on an Automation Administrative Shell. The goal is to use OPC UA to access standardized meta information and function blocks from the controller.
Will 3S deploy the Automation Server itself?
Manfred Werner: Certainly not. Three years ago, I would have answered that question differently. But we see that it is extremely complicated to operate a server landscape with many users. There are some big companies that initially ran a cloud and then went to Amazon or Microsoft. If other service providers in Germany or Europe become established, then it is easy for us to port our Automation Server there. That's a small step then.
There was talk of the Automation Server ultimately also acting as a data collection point – for operational data. How far has that progressed?
Dieter Hess: This can to a large degree be resolved in CODESYS by application, as we showed at the Technology Day for Amazon Web Services and Microsoft Azure. It is a desirable goal for our server to do the same in the long term, and we will also offer this.
Which interfaces do you support for cloud connectivity?
Dieter Hess:MQTT is available in the CODESYS Store. This allows users to communicate with Microsoft Azure and AWS. And via the web client protocol, which is also available in the Store, we can connect to clouds such as Thingspeak from Mathworks or Alibaba. In addition, we are gradually implementing other open, standardized protocols such as OPC Pub/Sub.
What time frame do you have in mind for the various topics?
Manfred Werner: This year, the Automation Server will be released at level 1, that is with functions such as application update and device swapping. Backup-and-restore and security updates of the runtime will follow later.
It will take a few years until the entire CODESYS will run completely on the web. The first services like the topology editor are available much earlier of course.
So one can assume that the next bang will be at the SPS IPC Drives?
Manfred Werner: So it is. In Nuremberg, visitors at the CODESYS booth can try out the Automation Server live.
Ganzer Artikel als PDF zum Download: Mehr Transparenz und Security