Open interfaces enable the integration of operating devices of the future - such as the Microsoft Hololens.

© Inosoft

If you program yourself, you have complete freedom to implement your operating concepts and application ideas - as long as the associated costs are economically justifiable. All technical doors are also open during implementation, for example when it comes to programming languages or development frameworks. This is relevant insofar as the interfaces for new devices, for example for data glasses such as Microsoft's Hololens, can only be implemented in current environments. The demands on programmers are correspondingly high: they must be fit in the latest programming languages and tools.

Those who cannot or do not want to make this effort will opt for a ready-made solution that can be easily adapted to their own requirements - at least within the scope of the predefined functions. You may also be subject to certain restrictions when it comes to the graphic design of the interface. In this case, machine manufacturers are dependent on the provider implementing all the necessary options or providing corresponding APIs and interfaces that allow additional products to be added or new operating devices and operating concepts to be integrated.

The requirements for ease of use, functionality and design of HMI surfaces are increasing. On the other hand, high-quality surfaces give machine manufacturers a competitive advantage.

© Inosoft

The numerous solutions available on the market differ, sometimes significantly. It is important to take a close look at which manufacturer you commit to - both in terms of the current technology and the development path that is mapped out for future versions. It is also important to check which interfaces to applications outside the HMI/SCADA world a solution supports - such as ERP systems and cloud applications - and which protocols are available for data exchange. Depending on the strategy being pursued, it is important to check very carefully whether the intended solution can achieve the goal at all.

However, it is not only the solutions themselves that differ greatly - development and maintenance also have a completely different character depending on the strategy chosen. If you develop your HMI application yourself, you need highly qualified developers. These are not easy to find on the market - larger companies that can offer attractive conditions therefore often have an advantage. The 'side effects' of a self-programmed application should not be underestimated: Adaptation to new hardware as well as updated operating systems and frameworks. This can be a strength if the self-developed solution can take advantage of technical innovation and generate added value for the user. Particular attention must be paid to version management of the in-house code and the third-party libraries used. In addition, security must be guaranteed throughout the life of the system.

If you rely on a purchased solution, you do not have to worry about such problems - that is the responsibility of the provider. However, the provider must also fulfill its obligations reliably and promptly. Purchased solutions are often proprietary, i.e. not based on common open standards, but use manufacturer-specific data and interface formats. This ties you closely to the HMI provider, sometimes not only for the software but also for the hardware. As long as the manufacturer regularly adapts its product to new computer and output technologies, the OEM has saved a lot of effort. If, on the other hand, the product remains at a development stage with increasingly outdated hardware, the machine manufacturer cannot rectify this himself. In the worst case scenario, the only option is to switch providers - and thus make a costly new start on the next platform.

The middle way

In addition to these two 'ideal-typical' strategies - programming or parameterization - there is a middle way that combines the advantages of both worlds. On the one hand, such systems offer a wide range of standard functions that can be easily set up using parameterization. On the other hand, complex functions can be retrofitted using object-oriented programming languages and the professional tools available for this purpose, while ready-made solutions can only be modified to a limited extent using scripting languages.

The idea behind such solutions is that the 'mandatory program' of the HMI can be created with little effort. This task can be performed by experienced automation specialists. Software experts only come into play for additional extensions. Functions that are not available on the market as ready-made solutions, special applications and services from the machine manufacturer and the consideration of customer-specific technologies and requirements are just a few examples of such additions.

Another important aspect is the design of the interface, for example in the machine manufacturer's design or according to the customer's wishes. The decisive factor here is that the programmed extensions fit seamlessly into the parts of the HMI that are based on parameterization.

One example of such an open system is VisiWin from Inosoft. This solution is deeply embedded in the Microsoft ecosystem for developing graphical systems. This includes Visual Studio, the Blend design tool and the .Net framework including Windows Forms and the GUI framework WPF (Windows Presentation Foundation). This integration ensures continuous further development and adaptation to current Windows operating system versions and modern PC technology.

A large developer community and numerous download platforms offer extensive opportunities to obtain support even outside the largely free manufacturer service, including in the form of ready-made function modules that are available for download. The risk of a 'manufacturer lock-in' is therefore very low with this solution.

If you want to program additional functions for VisiWin yourself, you can fall back on various technologies and languages. The focus is on C# and VB.NET (Visual Basic.NET) from Microsoft as well as web technologies such as HTML5, CSS, XAML and Javascript. Of course, current communication protocols such as OPC UA are also integrated.

In summary, it can be said: Every solution has its justification, but each application must be considered individually. The basis for a decision is a thorough weighing up of the advantages and disadvantages as well as the available skills in the company.

Author:
Stefan Niermann is Sales Manager at Inosoft.