Idekit - your automation SW development solution

Today, virtually every complex technical device or functional unit uses a microprocessor unit for its control. Its development and production has some specific characteristics compared to the machine part, which can pose risks for the manufacturer. In recent years, this area has been affected by the price and unavailability of microprocessors, the shortage of programmers is a permanent problem, the time to market is continuously shortening, custom modifications have to be made... therefore, Domat Control System offers Idekit. It is a set of tools that allows to separate the runtime (the basic software that handles inputs, outputs, communications, display, etc.) from the application software (i.e. the program that controls the machine technology according to the customer's or client's requirements).

Fig. Separation of runtime and application in a programmable control system

Especially for less computationally intensive equipment such as a heat pump, wastewater treatment plant, irrigation system or air conditioning unit, software development is usually carried out in one of the lower programming languages. In principle, this would not matter so much. But what is important: everything from low-level communication with the hardware (physical inputs and outputs) to program recording and the actual functions of the technology to user interfaces such as operating the LCD display or the web server is handled in one code - albeit in different libraries. This approach carries certain risks. The first is in the programmer himself.

Programming embedded devices is a highly specialised activity. A programmer is highly skilled, difficult to find and not cheap. Therefore, it is necessary to use his time to the maximum and not to let him travel around realizations, where he often solves operational problems that are not related to his work. He should be able to concentrate on his work and not act as a technical support, as is often the case (even if he can give advice because he knows the code in detail). He should not be forced to deal with controlled technology; it is a huge advantage to understand the technology, and "at first approximation" it speeds up development because this versatile programmer does not have to negotiate with anyone. But at the same time, we take another risk - a personnel risk - because the entire function of the technology stands and falls with one software engineer. So the solution offers itself: separate hardware-specific programming (let's call it system programming) from application programming, that is, that which directly relates to the functions of the controlled technology and the user interface. Application programming is then done in one of the languages according to IEC EN 61131-3, typically using function blocks or structured text, or a combination of both.

Why would we want that?

Better staff management, worker substitutability

Instead of a group of generalist programmers, we will have system programmers and application programmers. It is useful if they partially overlap each other, both for the sake of substitutability and to increase motivation. It is good if the tasks are not too abstract and the programmer can see what his work looks like in practical deployment. Application programmers don't have to deal with the concept of hardware, they deal with the functions of the technology and try to work with marketing and sales to develop software that best meets the user's expectations. In contrast, system programmers ensure that the development environment and runtime are tailored to a particular hardware platform (i.e., the processor used in a particular circuit, with inputs, outputs, and communication interfaces). There are even cases where a visit by a programmer to a customer may be counterproductive from a business perspective.

Detailed and truthful documentation

One of the significant risks in combined development is that the programmer is left with code that is poorly documented or not documented at all. There is no time to write documentation during development, and documentation is hastily created for the end user when the contract is executed so that the device can be handed over at all.

Separating the application from the system, however, means that application engineers must be given predefined access to inputs and outputs, even with the name of the data point. Such documentation is actually a prerequisite for developing an application program. Therefore, we can be sure that it will be created and that it will be available in two places - at the developer's and at the application programmer's. In addition, for more complex systems, several people must be involved in the development at the same time, otherwise it would be impossible to meet the deadlines. A well-described control system is therefore a necessary condition for the successful completion of the action.

Reducing personnel and operational risks

The last two years have shown how important it is to take into account the situation where a key person is suddenly unavailable. A documented and easy-to-read program allows the substitutability of both software and service technicians. It should not happen that a customer has to wait two weeks or more before the know-how can be transferred.

Easier hardware redesign

This point has also proved crucial in recent times. Due to the unavailability of components and their increasing prices, which often completely upset the economic calculation of the control unit, it was (and still is) necessary to react flexibly to changes in the product range and redesign the hardware of the control boards so that more affordable processors can be deployed. Domat's experience is clear: in the last three years, ten platforms have had to be redesigned due to a complete lack of processors in use or discontinuation. Ideally, the customer should not even notice, as any changes externally have a significant impact on design and service. With the separation of the runtime and the application, the advantage is that the applications (which can be multiple over the same hardware when one board is used in multiple types of devices) no longer need to be tested in any particular way, it is proven code, and we can concentrate on getting the runtime working properly. This means an easier and faster transition to new - more accessible, cheaper or just more powerful - hardware.

A number of add-on functions are already ready

Today, the control system is not just an isolated island of technology. Communication capabilities are also an important part of it. It's not just about the local user interface, such as a control panel with keyboard and display, but also about connectivity to visualization (preferably using an open protocol such as Modbus or BACnet), a web server, an OPC server, connectivity to the cloud, an API (open data interface for easy integration into foreign systems) or sending historical data to a powerful database. Idekit includes all of these features - and like a control program, creating menus on a dashboard or web pages is a matter of application programming, not low-level development.

Convenient prototyping

It doesn't pay to develop cost-optimized hardware for small-volume production or technology trials. If one of the already developed control boards is not sufficient for the new model, we can use a versatile, readily available platform such as a Raspberry Pi or even a Linux or Windows PC and supplement it with I/O modules. The application can then be transferred relatively easily to the final device, which will be more robust and cheaper. Let's not let the difficulties in developing the control system affect the time-to-market of the whole technology.

Excellent diagnostics

It is not only during the development of a control system, but also during the commissioning of the technology that problems occur. When diagnosing it, it is good to look "inside the system", both at the values of the variables and at the data flow on the communication lines. For this purpose, a comfortable debugging environment including a serial communication scanner, the so-called port monitor, is used. It is possible to trace a program, create backups of set parameters, sample immediate and long-term history online and offline, etc., all remotely over the network, without interfering with the control board and various programming adapters. For example, it is only a matter of minutes to find out that the meter is responding at a different address than agreed with the supplier.

So what does Idekit consist of?

Basically, it consists of two basic programs: Idekit Studio, which is an application development environment, and Idekit Runtime, or the program that runs on the target hardware and allows you to load and run the developed application. These two programs are complemented by a number of other optional modules for communication with peripherals and higher-level systems, for operating the device via a mobile phone or web browser, etc. The specific functions depend on the customer's requirements, but also on the performance capabilities of the hardware used.

Fig. Programming in function block language in Idekit Studio

Independence from the supplier

A common argument against the use of various paid frameworks, libraries and environments is the financial and strategic dependence of their users on the vendor. However, even this may not be a problem with Idekit. Interfaces between companies can be determined by the competencies and needs of the customer. There are a range of scenarios, from ongoing support to just sales and training. If a customer opts for ongoing support, they can be assured that they will be able to focus just on application programming - and all the work required to implement and maintain the runtime is supplied by Domat. However, if he has his own development team of system programmers, he can modify and develop Idekit according to his own needs and priorities after purchasing the license. Once it has acquired the know-how, it achieves vendor independence and benefits from Idekit without additional external costs. However, Domat Control System is still available to assist with any future implementations, extensions or upgrades.

History has shown that the actual development of a similar system by a number of companies has ended in failure or has been stopped due to unsustainable cost growth. The time factor is also an important consideration - any delay in the development of a control system can jeopardise the delivery of technology at orders of magnitude higher financial volumes, not to mention the impact on the company's reputation. Idekit is based on the Merbon process station programming package, has been in development since 2012 and the runtime has been running since 2014 on thousands of substations worldwide. Today, the Idekit brand offers the power of a proven system not only to programmers of building control systems, but also to suppliers of specialized process equipment such as air conditioning units, heat pumps, air handling units, etc.

Fig. Some of the platforms run by Idekit