How close is PLC programming from a 'docker' moment
Hello,
Thank you for reading my latest article on the PLC programming. To read my future articles simply join my network here or click 'Follow'.
-----------------------------------------------------------------------------------------------------------
Industrial automation world has quite a few particularities as opposed to IT space. One of the specifics is that, when it comes to a new project, the manufacturer tends to purchase the same hardware that is well known from previous projects. This happens mainly because the end client does not want to diversify the skills within the maintenance department, but also doesn’t want to diversify the spare parts.
It makes sense, doesn’t it! But what if the spare parts are not the most affordable on the market or the skills related to hardware troubleshooting are hard to find? Then in this case, operating costs(OPEX) are not optimised and can be a bottleneck in the overall business performance.
Btw, when I say hardware I mainly mean PLC.
Recommended by LinkedIn
Photo credit: https://electrical-engineering-portal.com/
The solution would be the adoption of a standard able to generate software applications using a programming philosophy familiar to IT programmers and in the same time to decouple software applications from their hardware platform.
Myself I’m used with the good old IEC 61131-3 which is currently the standard implemented by almost all the hardware producers in the industry, but Schneider Electric is making quite a significant push in promoting IEC 61499, which addresses among other things, the 2 mentioned issues that the industry has when it comes to buy new hardware.
Because, unlike IEC 61131-3, IEC 61499 is an event based system, this makes it easier to use by the IT programmers. As an IT professional when you write a piece of code you don’t worry about the scan cycle because your application is an event based system. Now suddenly, if your asset is developed based on IEC 61499, when you’re looking to recruit for your maintenance team you’re not looking only for OT programmers available on the market, but also for IT specialists able to understand an event based system code. This obviously will give you more options and additional flexibility.
Another feature of IEC 61499 is that its software model is totally decoupled from its hardware model, which basically means that the software is independent from the PLC. In other words, same piece of code, can run in the same manner on 2 different types of PLC from different manufacturers. This will basically enable the end customer to optimise its costs by purchasing whatever hardware wants in terms of price and performance rather than being tied to a specific producer.
It remains to be seen how the adoption of IEC 61499 will take place in the coming years, especially knowing that this will disrupt the main hardware producers business models in a negative way.
Personally, I’m going to keep an eye on the evolution of IEC 61499 and I hope I will soon have the chance to be involved in automation projects based on this standard.
This article was first published on https://andreicazacu.substack.com/
Andrei Cazacu ⚙️ Interesting thoughts but it misses some major points. The goal of portability has been elusive and there is not yet a solution. Using a full IEC 61131-3 (in particular SFC) implementation (in particular SFC) users can drive things based on events but it must be used understanding real-time system dynamics and is not trivial. In either case as anyone that has implemented control with real-time operating systems knows event programming creates a significant higher level of complexity. This is particularly a challenge to guarantee proper sequencing of operations, proper sequencing and synchronizing sensor inputs and outputs with application logic, and easily overrunning system CPU and bandwidth capabilities. IT programmers typically have no concept for this since timing requirements are significantly different and input and output peripherals are not constantly changing and tightly coupled to application logic as is the case with industrial sensor inputs and outputs. Neither IEC 61131-3 nor IEC 61499 software models are totally decoupled from hardware models. The source code needs to be compiled based on specific syntax, the target runtime engine, and hardware sensor inputs and output hardware structure. This is similar to the situation with embedded JAVA runtime engines that need to be hardware specific. The same piece of code cannot run in the same manner on 2 different types of PLC from different manufacturers. Two groups are trying to change this but at this point do not have proven solutions. - Eclipse Foundation 4DIAC, details: https://www.automation.com/en-US/Articles/April-2021/IEC-61499-Programming-Standard-Become-mainstream - UniversalAutomation Organization: This group was just launched and is a work in progress. The concept is members can use an IEC- 61499 runtime code under strict configuration control with the UniversalAutomation Shared Source licensing agreement that, unlike open-source software, prohibits members from making changes independently. The initial UniversalAutomation.org runtime engine is the Schneider Electric nxtControl IEC 61499 Runtime Engine Code they have donated to the organization. Companies using this runtime either build their own IDE and compilers for this target runtime engine or Negotiate with Schneider for a purchasing license agreement for Schneider Electric EcoStruxure Automation Expert IDE. Details: https://www.automation.com/en-US/Articles/December-2021/UniversalAutomation-org-multivendor-industrial Neither of these groups currently have a certification standard for processes to guarantee uniform operation. (Think of the early days of C programs) The Missing ‘Industry 4.0/Digitalization’ Link – Open Programming Standard Conformance & Certification: https://www.automation.com/en-US/Articles/May-2020/Missing-Digitalization-Link-Open-Program-Standards The goal of portability has been elusive and there is not yet a solution and we all look forward to meeting the goal.