The Device Chronicle interviews Konrad Heidrich, Group Leader and Senior IoT Solution Architect, netAUTOMATION, Hilscher on edge gateways and remote management.
Hilscher has an established record offering edge gateways to industrial manufacturers and as such the company’s experts understand deeply the needs on the production shop floor. Early on in the digital age, the company built up deep domain expertise and knowledge – the culmination of which is an edge platform called netFIELD. This platform helps to remote manage the edge gateways. iT started with Hilscher edge gateways but support has also been expanded to virtual machines and a toolkit is offered that can be installed on other 3rd party gateways that are used by the factory operators. Konrad is a key technology strategist at Hilscher and is an active leader and contributor in the technical working groups of the cross industry implementation group Open Industry 4.0 Alliance.
Remote management of edge gateways
Konrad explains that Hilscher developed the NetFIELD remote management solution based on very specific requirements and feedback from the market. Konrad says that “it is not possible to be successful in the industrial market by just offering the edge hardware, a solution for the remote control and management of that hardware must be offered as well. He says “Everyone that has devices in the field somewhere in the world, they must have some form of remote management.”
This remote solution mainly caters for machine builders where Hilscher has its largest market share. Konrad explains that the solution is not designed to remote manage one machine or several machines as a subset within that shop floor production environment. “The machine builder wants to be able to offer services to their factory customers for their machine and they need the remote control capabilities to deliver and support those services.”
Founding members of the Open Industry 4.0 Alliance
Hilscher is a founding member of the OI4 Alliance: Konrad explains that the idea for the OI4 was based on co-operation and openness to solve problems in the market. He says “Industry players may have had successful proof of concepts but then some of these POCs never came to wide scale successful roll outs. The reason for this was because the shop floor tends to be a brownfield environment with many different vendors, many different production machines and many different programmable logic controllers (PLCs) and so many different communication technologies and protocols to talk to all these different machines. Konrad elaborates that “It was better to have one concept but it could not be covered by one company but by an alliance of vendors with different domain expertises to use the right standards in the right ways to put the bricks together between vendors to come up with an optional solution for the customer who has to deal with a heterogeneous technology environment.” As Konrad describes it “Combining the building bricks from different vendors together can create better solutions and really drive the market in a way a single company cannot do on its own.”
Another important point for Konrad is that one vendor could be a leader in one specific field but the customer does not want a vendor lock-in where they take everything from one specific provider. For example, Hilscher is a specialist leader in Field Bus technology and so would be the optimal company where a PROFINET-compatible solution is needed. But then if there is another requirement at the same customer for a wireless HART solution, then may be there is another provider who has the specialist expertise there. But then if the customers want to leverage all these expertise individually, they will have to deal with different vendor APIs. And then a lot of projects probably never get off the ground due to the overwhelming complexity. The answer to this, Konrad believes, is for each vendor to focus on their specialist expertise and agree on open interfaces or microservices available so that these specialisms are combined for the greater benefit of the customer.
Edge gateway use cases
Konrad begins by saying that gateways should be manageable for security reasons as they are connected to the cloud and IT services. “We must take care of that backdoor, and it has to be done in factories all over the world. Special skills and roles are needed to manage these machines, not always available in the local factories so the expertise has to be made available through a remote interface.”
Konrad explains that the host systems and the applications need updating. And you must also update the roles and user management. Employees change and this must be reflected in the production environment. “New rules, procedures, new parts in the shop floor area also may require the edge gateway to be adapted.”
The volume of edge gateways is growing because the shopfloor is based on real time communication, and the communication is very different from the IT and cloud and there is a need for a gateway to the shop floor.
With regards to software updates on the shopfloor, Konrad says that the shop floor has maintenance windows anyway. “Operators don’t want to stop the machine so automatic software updates in the background is something we will not see for at least 10 years in production areas.” Production shop floors have maintenance slots and will do the updates within those slots so the software does not break the machines.” Konrad says that time-driven or trigger-driven updates within maintenance slots are the standard practice. Authorized personnel have to push the button, always supervised: “Factory operators are afraid that if the machine turns off in the wrong 5 minutes, that type of event can cost millions of euros in lost production.”
OI4 working groups
Konrad leads the edge computing working group in the OI4: they discuss what constitutes a good microservice, how microservices should communicate with each other and how a microservice should live in a docker container. And importantly, what security requirements it should meet. Remote device management and application management are also in focus: different applications available from a marketplace and installable on different gateways from different interfaces from different providers. Konrad adds “We try to decide how the interfaces should look from gateway provider to marketplace and from marketplace to edge gateway. In device management, the OI4-compliant gateway should provide a subset of functions to update, restart and maintain the device.” Konrad further explains that “Traditionally each gateway provider would have done it differently with their interfaces but now we want to come to a standard interface, working with labs and test centers group LNI 4.0. In the end one gateway provider may be able to manage the gateway of another provider in a single solution if it makes sense from a vendor and customer perspective.”
Edge gateway and PLC
Edge gateway and PLC may exist in the same device. PLCs can be loaded as a Docker container and depends on the quality of real time communication. There are also PLCS that have Docker components to run certain edge tasks. PLCs will have more computational power but their task remains real time control for the programming, the gateway is still being a buffer between the real time tasks and the IT Cloud world. In unsecured brownfield shop floors with legacy equipment, the gateway will remain an important bridge.
We wish Konrad and his colleagues at Hilscher and Open Industry Alliance 4.0 well in their pursuit of improving edge gateway management.