When was the idea for a programmable controller conceived, and why?

Lombello: Today, electronic controllers are either parametric or programmable. Parametric controllers are designed for vertical applications; they have multiple parameters to choose from (at times more than 200), and manufacturers can thus adapt them to suit their specific application. However, everything is predefined.
Programmable controllers, on the other hand, are typically used for more powerful, more complex and more expensive units, and allow manufacturers to fully define their own programming strategies. In the 1980s, the only controllers available in our sector were parametric.
We came up with a series of ideas that brought about a major innovation and determined our success as a company. It might sound simple, but it wasn’t: when the "visionaries" who came up with the ideas explained them to our engineers, they sounded crazy, as they had set a goal to be achieved regardless of the technological difficulties involved.
Yet it was this determination to not give up that was the key to our success.

Bianchini: As CAREL only had one customer at the time, we wanted to find a way out of this situation, and so were looking for innovative solutions that would let us supply several customers without needing to increase the number of designers needed to meet individual customer needs.

Lombello: Our main customer wanted controllers for complex units designed by CAREL engineers, with advanced skills, who worked using assembler, a machine code language. It therefore took many months’ work to write the programming code, and quite often, when the program was finished, they needed to start over again, because in the meantime the requirements had changed, and the customer’s needs had changed.
CAREL thus had the intuition of developing a controller that could be programmed directly by the customer, while however considering that customers had electrical, mechanical and thermodynamic engineering expertise, but were certainly not software programmers. We therefore decided to offer customers the possibility to develop software using the same type of CAD system they used to design electrical panels. This "CAD software" that we invented made it possible to control the unit by putting together a number of basic functions that customers could access from a CAREL library. In the exact same way as they were used to doing when selecting the electromechanical components to make an electrical panel.

What steps did CAREL need to take operationally to develop the first software for programmable controllers?

Bianchini: We created a programming environment with virtual software objects (even though we didn’t know they were called this at the time) that our customers, electrical/mechanical engineers, knew how to connect together because they already did so in other areas: this was the basis for the initial programming system.
As we had limited human resources at the time, we started by using structures and components that had been developed by others, such as electrical CAD. We developed a simple program that compiled the blocks the customer had selected and allowed debugging. This was back in 1988. The software was called EasyTools, and for the first few years it was only tested and used internally. Then, in the early 1990s, we started offering it to customers. It was quite innovative at the time, however it wasn’t very clear just exactly what we were doing at the beginning, as otherwise we would certainly have patented it.
Moreover, we had set ourselves an additional challenge: to make the software independent of the hardware, in other words, software that could be moved to different controllers, following technological evolutions; this meant customers could protect their investment even when the hardware changed. This extra challenge was certainly no minor task at the time. Yet it brought considerable advantages for both us and our customers.

Lombello: Hardware independence and simplicity of the development environment using CAD made knowledge of assembler language unnecessary, allowing customers to work autonomously even if they were not programmers: back then, this was totally innovative.

What were the market demands at the time? And what did CAREL do to respond effectively?

Lombello: The 1980s saw considerable growth in demand for electronic solutions, including in the sectors where CAREL operated, such as computer room air conditioning. Consequently, it was essential to offer solutions that were not only electronic, but also microprocessor-based. Every company operating in these sectors had developed an infinite number of custom products, and therefore each customer had their own specific solution.
Ours were vertical markets with limited volumes, and therefore there was the risk that custom solutions would only be implemented on a small number of units; the problems were consequently development times, quality control, and return on investment. EasyTool made it possible to reduce development times and increase quality, as the software used tried-and-tested elements made available in a library. This allowed us to increase our "firepower", and therefore our ability to develop new solutions. When we started offering these solutions outside of CAREL, we had to encourage customers to use them by developing new skills. It was then that Paolo Zama, a Software Solution designer who today is still involved in training, started offering his first training courses to customers.
However, we soon discovered that having a blank sheet of paper was a problem for customers, and so we began designing standard solutions. Customer could thus use the standard as the starting point, being able to easily choose what to keep and what to change.

Bianchini: Basically our strategy has never been to sell our software, rather we limited ourselves to selling licenses, which in actual fact were payment for the training courses.
Getting back to programmable controllers, it should be stressed that these were the response to the demand for differentiation from unit manufacturers.
Indeed, our customers all operated in the same sector, and the units risked all being alike: same compressor, same fan and same controller.

Lombello: CAREL’s response regarding controller differentiation was to allow easy customisation of the "visible" parts: user interface and software. Everything else, hidden inside the electrical panel and therefore "invisible" to the end user, was standard. This allowed CAREL to create economies of scale and economies of scope.
Common hardware made it possible to achieve high volumes and therefore economies of scale, with all the resulting advantages, from standardised production to improved quality and consequently lower costs. We also created economies of scope, i.e. we were able to spread the investments made into developing new hardware, programming tools, etc., across multiple applications, thanks to the flexibility of the software.
CAREL has always had expertise in managing systems that control refrigerant circuits, and therefore we were able to transfer our objects from industrial refrigeration and commercial refrigeration applications to industrial, commercial and residential air conditioning applications.

How has programming evolved over time?

Lombello: CAREL has changed the market dynamics in its sector, changing the work flows and roles of the different stakeholders. Specifically, we shifted the sale of control systems from being typically for installers (who purchased, installed and configured the controllers) to unit manufacturers, i.e. OEMs. In the past, OEMs were simply assemblers of components, mainly electromechanical components that were then controlled in the field. By having simplified the programming of electronic controllers, OEMs were able adopt what is known as downstream integration: they brought unit control in-house and therefore were able to start supplying the market with finished units that to be installed simply required connecting the electrical parts and fluid circuits. The development of technology over the years has also given programmable controllers another huge advantage. Air conditioning units in the 1980s were extremely simple and highly "electromechanical". While managed by electronic controllers, the components themselves were mechanical: on/off compressors, mechanical valves, on/off fans, etc.
Then, mirroring what had happened in the automotive sector, "smart" components came to the fore, with superior performance, higher reliability, capable of adapting to different operating conditions. This gave even greater importance to software tools that allowed users to easily install and manage complex devices. A bit like what we do at home when we connect a complex colour printer by simply downloading a software driver onto our PC. The next evolution will involve improvements in self-diagnostics and predictive management of unit failures.
The way forward is to connect more and more units, collect data, develop intelligent algorithms. CAREL currently has around one million units under supervision, at least 300,000 of which are connected to our cloud.

We’ll let you know the rest on our 100th anniversary.