Web-based device parameterization

M&M Software has many years of extensive experience in the field of device parameterization. For a long time, device parameterization was realized with standards such as FDT/DTM, EDD or even in proprietary Windows applications. This has resulted in the development of components, which (usually) occur in some form in all these solutions. These devices will be described here.

The starting point is a device to be parameterized. A device logic is implemented in this device. The device has, for example, parameters, services (functions), measured values, etc. The device also contains a communication stack that enables it to communicate with the outer world.

The counterpart is the parameterization tool, which contains a communication provider for exchanging information with the device.

Inside the parameterization tool you will find a device model. It represents the device logic, i.e. it contains a model of the parameters, services, measured values etc. actually implemented in the device. The device model also has a bus mapping. The bus mapping defines how certain information is exchanged with the physical device (e.g. the HART command that can read or write a certain parameter).

Thus, the device model can translate a request for a certain parameter into the necessary bus communication and process it via the Communication Provider.

Different views can now be operated from the device model. One such view would be a GUI that displays the parameters in an editable form. The data exchange between GUI and device model takes place via a proprietary exchange format such as XML, JSON or also via serialized objects. Other views, such as an OPC-UA data interface, are conceivable.

If the parameterization tool is also to function offline (i.e. without a physical connection to the device), it must still be connected to a persistence mechanism.

The final piece in the puzzle is the question of how the device model is created. There is a device description as source and a generator. There are different possibilities for the device description and the generator. For example, the device model can simply be coded in a high-level language like C#. In this case the source would be the C# source code and the generator would be the corresponding compiler. The device description can also be an EDD, such as an IO-Link DD. In this case, the generator would then be a DD interpreter, which builds up the device model accordingly. The generation of the device model can only take place during runtime of the parameterization tool, or the device model is generated once and then installed in executable form on the target system.

When designing a web-based parameterization tool, one must deal with how these building blocks are distributed on the system and how they are actually implemented. There is no "one standard solution" that fits every application. In fact, the opposite is true: You have to take a close look at the concrete requirements and the existing infrastructure and adapt the solution accordingly. A selection of such scenarios is described below.

Everyone who operates a cable modem or similar at home knows a variant of web-based parameterization and configuration. Using a browser in the home network, one calls up the IP address of the device and logs in with access to the cable modem. A (more or less complex) web page is displayed, where you can change the settings of the cable modem. The web server and the web pages are located directly on the device.

Often the firmware of the controllers of different manufacturers also contains a web-based management. In this case, the web server, which is part of the firmware, delivers dynamic HTML pages to the client (browser), which can be used to view or change basic settings of the controller. In these solutions, the communication provider and the device model merge with the logic implemented in the device but are still conceptually present. There is still the option of implementing a (partial) device model in JavaScript and executing it in the client. This allows you to use the computing power of the clients (for example, a tablet) and reduce the load on the device itself.

Especially when the available hardware only has limited resources and computing power, a lot can be achieved with a clever distribution of the components. For example, it is possible to move the device model completely including the generator to the client. In this case a device description would be interpreted at runtime on the client (in a web browser). This can be useful if the interpretation of a device description at runtime is required by the application case but cannot be executed on the existing device hardware for performance reasons.

The examples described are only an excerpt from the treasure trove of technical possibilities. We support you with our comprehensive know-how in developing your own device configuration strategy - based on the latest technologies and established industry standards.