meta data for this page
lamaPLC: Automation!
Old School Automation
Technologies come and go.
Who remembers the solutions that were popular a few years ago that are now completely obsolete? And a relatively significant part of the solutions that are still considered extraordinary breakthroughs today will only be mentioned a few years later on the internet, after a long search. There is nothing wrong with this; this is the way of the world: development sweeps away a good part of the old solutions (apart from a few eternal survivors, but more on that later), and newer, more efficient, and faster applications take their place. That is, there is just a problem: if this process is too fast (and I think it is a bit fast), there will be victims.
Let's say we want to modernize our house; solar cells on the roof, a heat pump in the basement, an energy storage system in the corner, with inverters. Each from a different manufacturer and not installed at the same time, because who has that much money? A separate application for each that provides all the information on your mobile phone: excellent.
Of course, the first problems are recognizable almost immediately; the applications do not communicate with each other, or if they do, the connection is unstable and dies after each update. Of course, we know, each one is from a different manufacturer – that's the way it is. Then the years pass, manufacturers cease to exist, merge, transform, product tracking, well, there is not much of that.
There we are, a few years later, with expensively installed equipment, trying to parameterize them on their small display, since their application has long since stopped working, and we are wondering if we really need to throw out the entire system and buy a new one, because they were shot for communication?
It is surprising, but even in this cavalcade, there are timeless communication solutions. I will list a few: Ethernet (TCP/IP, UDP, Telnet), RS-232, RS-485, UART, and Modbus. Let's look at the latter, Modbus, for example:
The protocol was developed by Modicon in 1979. The manufacturer has since ceased to exist (merged into Schneider Electric), but the communication solution has proven to be an eternal survivor, for almost 50 years now. Modbus is virtually unavoidable in industrial automation solutions. A lot has been developed around it; there are also “copper wire” and “Ethernet” versions. It is surprising, but almost every inverter manufacturer, for example, either uses it publicly or just like that, there is the characteristic A+, B-, GND connector row on the motherboards.
Old School Automation (OSA) offers solutions based on these old-fashioned methods, primarily for building automation systems, since industrial automation is based mainly on them. On this page, I summarize and describe these solutions.
UDP
UDP (User Datagram Protocol) is a fast, lightweight internet protocol used for time-sensitive applications like video streaming and online gaming because it doesn't require a connection to be established first. While this makes it efficient, it also means that UDP is unreliable, does not guarantee packet delivery, and is more susceptible to data loss and attacks than protocols like TCP.
UDP broadcast is a method of sending a single UDP packet to a special broadcast address, which is then delivered to all devices on the local network. This is an efficient way to send data to multiple recipients without needing to know their individual IP addresses. Because UDP is a connectionless protocol, it is suitable for applications where some data loss is acceptable in exchange for faster, more efficient transmission.
Another great advantage of UDP broadcast in building automation systems is that it does not require “knowing” the IP addresses of the participating units; each sub-unit simply “scatters” measurements and messages across the network. Not every telegram reaches its destination, and many end up in places where they are not needed, but despite these inaccuracies, the information still gets through. The sub-units do not need to “know” the network; the data exchange is built up almost spontaneously.
UDP is often prohibited in many networks, especially industrial ones, because it can cause overload by flooding the network due to its properties. This issue can be avoided by reducing message transmission frequency to about 1–5 seconds. Building automation systems typically do not need high-speed (e.g., isosynchronous) data exchange.
UDP works well with DHCP (Dynamic Host Configuration Protocol) address allocation. It doesn't “require” precise knowledge of IP addresses like TCP/IP because it distributes information across the network almost like a shotgun; what it finds is what it sees. This protocol was really designed for simple, decentralized, and efficient IoT solutions.