Episode 17: Unveiling Runtime Execution Engine V24.1 | UAO Goes Live: The Future of Automation

Description

In this episode of UAO Goes Live, our Chief Architect unveils Runtime Execution Engine V24.1.

New capabilities include Modbus explicit read/write, updated third‑party libraries and an OPC UA stack upgrade, improved WebSocket and MQTT connection management, and enhancements for PROFINET acyclic and alarm exchange.

Fixes address Ethernet/IP explicit messaging, MQTT stability and throughput, Modbus register handling, and mixed Ethernet/IP + PROFINET deployments.

We also preview the roadmap (hardware‑configuration online change, LLVM compiler, PROFINET CCA work, Modbus TCP server for HA, EtherCAT, UTF‑8 strings, and an Open Adapter concept) and clarify how UAO technology differs from virtual PLCs while supporting Open Software Defined Automation.

About UniversalAutomation.org (UAO)

UniversalAutomation.org (UAO) is an independent non-profit organization dedicated to transforming industrial automation through open standards and shared source technology. The association manages the reference implementation of a shared runtime execution engine based on the IEC 61499 standard, enabling true interoperability between hardware from multiple vendors and portability of automation software applications.

By providing a ready-to-use, vendor-neutral runtime environment, UniversalAutomation.org empowers companies to build flexible Industry 4.0 architectures, accelerate digital transformation, and maximize return on investment (ROI) through software reusability and hardware independence.

The development of this runtime is governed by shared source principles, ensuring long-term compatibility and collaborative innovation. Members—including end users, OEMs, system integrators, and technology vendors—work collectively to create a global ecosystem for plug-and-produce automation solutions.

UniversalAutomation.org is growing rapidly as more organizations adopt open automation to overcome vendor lock-in, enable IT/OT convergence, and support greenfield and brownfield projects. Academic institutions are also leveraging this technology to train the next generation of automation engineers.

Companies and institutions that want to lead the future of industrial automation, develop next-generation control systems, and participate in a global open automation community are invited to join UniversalAutomation.org.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Transcription

Speaker #0
Hi everyone and welcome to this newest session of UAO Goes Live. Today, very interesting topic, we'll go towards a new and discover a new version of the UAO runtime execution engine, the v24.1. You surely remember as we released the latest runtime version, it was last December, the v24.0, and we've made some demonstrations about it and so on. And now we want to bring to you the newest features, which are... coming with this newest version. But to talk a bit more details about it, I want to welcome on the stage, Sarath. Hi, Sarath. Hi, David.
Speaker #1
Hi, Greg. I'm doing good. Thank you. How are you?
Speaker #0
Yeah, doing good. Thanks. So, Sarath, you are our chief architect officer, so you have the honor and the privilege to show us a bit more about the runtime execution engine, but can you introduce yourself maybe shortly to the audience?
Speaker #1
Yes. Hello. A warm welcome to you all. Myself, Sarath Kumar Reddy Malakasima, the Chief Architect for Universal Automation. I'm here to present you the new version of the Universal Automation runtime that we are bringing to you this month. Thank you.
Speaker #0
Great. So maybe, Sarath, we can jump on to, I think you have a presentation for us.
Speaker #1
we can maybe share the presentation on the stage and uh yeah so here we go thank you all again a warm welcome to you all uh today i'm here to present you about the new version of the universal automation runtime uh which is the version 24.1 this goes live this month i will now take you into the details of this runtime so This new release is based on the EcoStruxure Automation Expert 24.1. I will talk a bit about what are these new features and what enhancements are done and also what fixes are done. And what could you expect going forward in the future release? So these are the three major topics that I'm going to talk about. Let's say the first bullet is just an information.
Speaker #0
Just before we jump to the explanation about the feature, can you? shortly explain what is EcoStruxure Automation Expert for the viewers who don't really know a bit, a lot about Universal Automation and technology?
Speaker #1
Yes, so EcoStruxure Automation Expert is a product or offering from Schneider Electric which is based on the Universal Automation Runtime. This comes with two major components. The Runtime component is based on the Universal Automation Runtime reference implementation and a build time tool. called as eae ide integrated development environment which allows you to program the runtime and develop the control application and deploy that to the runtime thank you greg for reminding me of that okay so now i move on to the features enhancements and fixes which are part of this new release so let's start with the new features a new set of function blocks add are added to support Modbus explicit reads and writes. If you are wondering what is an explicit read and write, in general to communicate with the Ivo subsystem which is Modbus based, you end up creating a bus master and then creating several hardware cats under the bus master in order to cyclically read this Ivo at specified scan rate. Now as part of your application development, you encounter a situation wherein apart from the cyclic scan maybe there is a specific register based on which you want to run your remaining application logic and you don't want this register to be read cyclically so in such a scenario you could use an explicit read to read this register value and then based on the value you could build your application logic on what exactly you want to do there and same is the case with write there will be there are scenarios wherein you want to update a register value in the device which then triggers something else in the operation side you could use an explicit write from application but you want to do this right only based on your application logic then you use this explicit right so this brings in lot of flexibility in application development especially in cases where you are trying to build an application logic that is based on what is happening in the field in the plant or in the process Then comes the other one, which is the update of third-party libraries to newer versions. This is something which is a very constant effort that continues to happen over releases. Always, it's advantageous and good to use the latest version of libraries because most of the versions contain fixes for cybersecurity issues and other things, even from a cybersecurity standpoint audit. it's important that you keep upgrading your library versions to the newer versions. In the same line, there is also an update to the OPCUS stack to version 1.8.x which has some bug fix patches as part of this version of the stack. There is also constant ongoing effort in reducing the technical depth which is doing code refactoring to improve the performance, to improve the reliability of the runtime and the stability of the runtime. So there has been a significant code refactoring done. SDL improvements, yes, secure development lifecycle improvements, especially fixing issues identified in penetration testing or different types of cybersecurity testing. They are also part of this release. There also have been some improvements to the WebSocket server, which is part of the runtime. And this WebSocket server is the core to the runtime responsible for accepting all the other requests like deployment, watch and debug and most of these core functionalities. There has been a significant enhancement to the way the MQTT connection is managed. You can manage it much better now. There have been certain connection drops in the previous implementation. They are being addressed to this enhanced connection management mechanism. With respect to PROFINET, There has been an enhancement for our cyclic messages and alarm data exchange. Let me remind you all, in order to use PROFINET, you need to use the softing stack, which is license-based. So as a vendor who is using UAO Runtime in your offer, you need to get access to this PROFINET license and the stack to use it.
Speaker #0
And the PROFINET implementation? was done with the last version, the V24.0, no?
Speaker #1
It came into, the first version was in 23.1, but not through the full functionality, but 24.0 did bring some additional functions. And now in 24.1, whatever was existing in 23.1 and 24.0, this isoclic messaging part and the alarm data exchange has been greatly improved. and this is done specifically to get the CCA level certification as well. There is also support for function code 43 which is and subcode 14 for the Modbus server security improvement. As you all know the Modbus spec has been updated to introduce some cyber security parts. There also has been some improvement done in terms of the making OPCS server and client more responsive. this basically is again a bit of code refactoring and clearing of the technical debt so this is what is uh there as new feature set available to you in the new release that that we are going to do this month it's already available in github you can go and download it and use it and on the fixes side again as you can see most of the work has been done on ethernet ip explicit part as i explained in case of modbus the explicit messaging or explicit possibility to read and write I-O values, you have the same possibility on the EIP side. There have been some issues on that and they are being addressed and fixed. There were some similar issues on the MQTT side, they too are addressed. Modbus slave, there was a intelligent function introduced to reduce the configuration effort to auto-calculate the register addresses there has been some issue with it and that's that is being fixed uh there was also situations where a segmentation fault used to occur when uh application uh were using ethernet ip and profinet together if they were used uh on different controllers there was no issue but if the same thing was used on the same controller there were issues and that is being address and a behavioral improvement is done. in the NetIvo block to deal with the secure TCP using the certificate mechanism. That's one improvement, especially towards making the NetIO communication secure. Again, there was a segmentation fault with MQTT in some specific scenarios, especially in an overloaded situation. That also is addressed and a great improvement is done in terms of number of MQTT message exchanges that could be done in a specified period of time. Again, some specific fixes were done in Modbus library and Modbus registers, Modbus implementation to address some of the bugs that were noticed either during testing or at later stages coming from the customers. So this is what you see as the new release of UAO Runtime. We urge you to quickly upgrade your offers to this newest release to leverage the new features and also to make the runtime more reliable and stable with all these fixes now i am going to move on to presenting you what could you expect in the future release of the runtime hardware configuration online change as you all know if you want to add new io points under a bus master today you have to restart the runtime to bring in the new configuration to work there is an effort in progress to allow this change without the need to really restart the runtime 64-bit runtime we have been mentioning this for a long long time i would say but again it's complex it's not so easy so this is being worked out especially to deal with the complex situations like you have a system with a 32-bit runtime or now you are bringing 64-bit runtime into place adding new controllers you want them to interoperate work together and all this so it's a bit complex so it's taking a bit of time same is the case with llvm compiler if you are if you're going to use a new system probably it's quite easy to use devices which are 64-bit and use llvm compiler but this is not let's say the most common scenario the most common scenario is all you always have a mix up of things and that's what is pulling back bringing these two features into the runtime time. in a quicker time then as i mentioned in the new features enhancements are done in profinet for cca compliance preparation this effort will continue and you will see more changes and enhancements done on the profinet side in order to qualify the solution for cca certification modbus tcp server for high available ua ort is is another important feature There have been requests from members who are using the high availability version of the runtime to have the Modbus TCP server added to the high availability part. This effort is in progress and this is something that you could expect end of this year or beginning of next year. EtherCAT, there has been a significant effort put into this to build a proof of concept and do the performance evaluation to make sure when it is brought into Thank you. the runtime, it is able to deliver the similar performance or even better performance when it is put to use in real-time projects. The UTF-8 string encoding support, this effort was also started. You can expect this sometime this year or next year. This is a very important item for IT-OT integration. Then there is an effort that got started for OpenAdapter. but i would say it will take a bit of time before you could see come into existence because this is having a very broad scope to be covered uh to be able to get devices from different solutions to talk to each other to be able to get devices talk to external services uh in an open way and all this so this this is more a long-term effort but you will see bits and pieces of it available in the runtime which you could use uh based on what it can provide So this is what you could expect in the future releases of the Universal Automation runtime. This is all I have packed for you today. And if any one of you has any question, I'm happy to answer it.
Speaker #0
Thank you, Sarath. So, yeah, let's see with the audience if there are any other questions coming. One question from my side. You are talking about that the audience should upgrade their, let's say, runtime to the newest version. task that is for the user of automation, like user of any, let's say, product on which a runtime is running, or is it something for the vendor of automation?
Speaker #1
So it starts with the vendor. The vendors have to regenerate or recompile the image for their device using the new version of the runtime, and then give it to the end users, and then end users will upgrade their system to use. this new image so it does involve both of them but it starts with the vendors who have offers in the market with our runtime to upgrade their images images and then share it with the end users to to let them upgrade their systems to use the new image good
Speaker #0
okay thank you for for making it clear. I would say since they are so okay, I see now Some questions coming from the chat. Let me read that for you. In terms of open adapters in the future, would that be for 649 or also for 61131? Question from Pierre.
Speaker #1
Okay, great. A very interesting question. Yes, the purpose of open adapter here is to really keep it open, which means it welcomes our... it encourages the idea of integrating desperate systems. When I say desperate systems, a system which is using 61499 and a system which is not 61499. Here in this case, it could be 61131. There is effort from our side to make sure we define and implement this open adapter in an open way that other systems can easily embrace and implement it to see this open connection between the two systems. Sure, we are representatives of the Universal Automation and 61499. So we are creating the possibility from this end. At the same time, it is for the vendors to encourage adopting it on the other end so that the systems can be seamlessly integrated and talking to each other.
Speaker #0
On taking that question as well, Sarath, can you explain to the audience the concept of adapters, maybe? Before we turn to open adapters.
Speaker #1
Yeah. So adapter is a object which binds together multiple data items. For example, let's say you're trying to transfer three data variables or multiple data variables from one block to the other block. In order to reduce the engineering effort, in order to make it simple to configure and connect, you could pack in this data variables data items into one adapter and then it's a single line connection going from one block to the other block which makes the life of the application developer much simple and use it easy to use for example if i have to take it into the context of for example let's say opaf and opas you could use adapter to define an opcus signal an opa signal And this signal can be a single line going from one OPAS block to the other OPAS block. I'm just trying to throw an idea at you, but that's what is the importance of the adapter.
Speaker #0
So it's kind of what is called as well the single line engineering, you know? Exactly. One single line, engineering data, I mean, communication plus events.
Speaker #1
Yeah, together.
Speaker #0
In one line. Okay, just to make it clear, because we have sometimes some viewers who are new to the 6479 world, so all those concepts need to be clear. I don't see any other questions from the chat right now, so maybe I go on with my other question, which is, I hear a lot lately, especially about those virtual PLCs. I take the opportunity that we have you on stage to talk a bit about that topic. Because I also hear, yeah, now that we have virtual PSCs on the market, I mean, why do we need universalautomation.org? That's one of the questions that comes as well to me. So maybe you can explain to the audience a bit more about, yeah, what is virtual PSC, what we do at universalautomation.org and so on.
Speaker #1
Excellent question, Greg, I would say. Yeah, sure, it's not directly connected to the runtime release, but I think it's a very, very important topic that needs to be clear to everyone. What is a virtual PLC and how does it compare to what Universal Automation is doing and what Universal Automation runtime is meant for? Thank you for asking this question. Let me quickly bring up one slide that I have that I will use as an aid to explain this. Okay?
Speaker #0
Yeah.
Speaker #1
Okay, so yes, breaking the vendor lock, of course, is important, but it is not a single lock that is responsible for this vendor locking of the system. Actually, there are multiple locks at multiple levels that needs to be unlocked if you want to break the vendor lock completely. Okay, so as you can see here, there are three different approaches that are taken today. for example the classic plc where the hardware is proprietary the platform is proprietary the control runtime is proprietary and then the control application is proprietary which means each of these layers are locked together you cannot use a different control application with the same control runtime you cannot use a different control runtime with the platform you cannot use this platform on a different hardware which kind of makes it a full lock that means If you go with this approach, you are completely locked to the vendor of the PLC. Now, the next step is something which, in a way, was already used largely in the IT industry. Let's say industrial automation, in a sense, is running behind here. The IT brought in this possibility of virtualizing the hardware. In technical terms, it's called a Type 1 hypervisor. So if you use this hypervisor. it kind of virtualizes the hardware and gives you the ability to run the same software on multiple hardware or you can also kind of share the hardware across multiple software multiple different types of software right so this is one level of virtualization which gives you freedom to build a software which you could run on any hardware provided you have the same hypervisor available this kind of largely Hmm. started i mean or created the opportunity to come up with this virtual plc then there is an another layer of abstraction or virtualization if you want to call it which is on top of the platform which is the operating system here and again a parallel to what is happening in the it world you you have windows operating system running on the hardware and this operating system acts as a host and lets you run multiple guest operating systems like you can run linux you can write different other types of operating systems on top of the existing operating system. This also gives you leverage to build something, a control runtime or a virtual PLC, which kind of gives you freedom in terms of, okay, my virtual PLC can be now deployed and run on different hardware and can also be deployed and run different operating system. But the lock between the control runtime and the control application still exists, which means if you are going with taking one of the solution virtual PLC from a particular vendor. Yes, you could run this virtual PLC on ARM, you could run this virtual PLC on x86, you could run this virtual PLC on Windows, you could run this virtual PLC on Linux, but still the control application what you created to run on this control runtime can only be run on this control runtime. It cannot be run on any other virtual PLC. So, there is still a lock which is unlocked here. Now How do we address this? How does what kind of approach that universal automation take here in comparison to virtual PLC? So, the universal automation here what we do is instead of creating a binary contract to break this lock, we have embraced the model of shared control runtime source code which is very similar to the way the Linux kernel works. If you look at the existing Linux operating systems most of them they use the same kernel so and then this kernel is an open source so every every linux since it is using the same kernel most of the software applications built for one linux are compatible to the other linux especially if you are not using vendor specific functions and features which are built on the built on top of the core runtime so the same principle applies here now with this approach we are able to unlock the possibility to develop control applications that can now be deployed onto different devices, irrespective of the hardware, irrespective of the operating system. They can now run on multiple vendor devices and multiple vendor solutions. Again, because it's a shared source model, we are not dictating the actual deployment model, which means do you want to run it like a classical PLC? Do you want to run it as a virtual PLC, leveraging the hardware virtualization? Do you want to run it as a Docker container, leveraging the OS level abstraction and virtualization? We don't dictate anything. We say, we enable you to do what you want. And this is one big differentiation that universal automation brings to the industry. I hope I'm very clear in explaining all this.
Speaker #0
Makes sense. Makes sense. And at least it's, let's say, shed some lights on the topics because... for sure especially right now we see a lot of companies coming up with virtual psc's let's say systems or or solutions or offers and yeah it comes often to the question yeah what's then if we have that why do we need why do we need universal automation and but actually Another question to you, because, yeah, since you're here, this UAO runtime that we have, for sure, this shared source code, can I still have it run on the server? Can I still have it run, or am I kind of still obliged to use a typical traditional PLC to use this runtime?
Speaker #1
Yeah, that's, I think. A very, very basic question that comes to everyone's mind. Where can I run this? Can I run it on my personal computer? Can I run it on Raspberry Pi? Can I run it on a rack server? Can I run it on a cloud? Yes, you can run anywhere you want to. However, you need to be calculative about the resources available and what services and functions you enable in the runtime. For example, you want to use OPC UA. which kind of consumes quite amount of resources, both in terms of memory and processing power. Probably if you try to run it on a simple controller with less than gigahertz processing power and very mean RAM like 256 MB or so on and so forth, that could be a bit challenging. So if you are taking care of this balance between which services you are enabling in the runtime, and on which resource you are trying to run it, you could run it anywhere.
Speaker #0
So it makes, okay, then it gives us a complete picture on where to use and how to use the whole thing in the runtime. So I don't see any other question from the chat or from the audience. So thank you, Sarath, for sharing your knowledge. sharing about the v24.1 version. I see your contact details are just shown on the bottom inside of the screen, so people can contact you if they need to.
Speaker #1
Yeah, definitely.
Speaker #0
I thank our viewers and wish them a very good summertime because the summer season has already well started. So I'm sure some of them are... maybe watching us from the beach and uh and enjoying this uh this this session and uh we'll come back in uh september with our newest sessions and and newest information about what is happening within euros automation.org and um which what are the the vendors doing the the users doing and so on before i forget Just one reminder, we are co-organizing an event, let's say two days, as part of the IEEE ETF 2025 in Porto. And as part of these two days, we are co-organizing on the 9th of September. a workshop which will be dedicated to the 649 technology. So quite informative sessions, a lot of good presentations. So we invite everyone to join that and you can see the events and get some more information by registering on the events on the LinkedIn event of universeautomation.org. Same on the 10th, which will be the industry day. during the IEEE ETFA event, where there will be some quite interesting panels with a lot of people coming from members, coming from different sides of the member base of the association. So for sure, we will have people coming from the academia, the SI, the vendors, and so on. Very interesting sessions. And we invite you all to have a look into that and to come and join us in Porto. So that's the end of this session, Saad. Thank you again for making it.
Speaker #1
Yeah, I just want to add that I'm available at the event. I'm present on day one and first half of the day, day two. So if anyone is interested in sideline conversations, discussing something.
Speaker #0
i'm available good thank you sarat thank you everyone and see you in september see you bye bye see you bye

About UAO Goes Live: The Future of Automation

UAO Goes Live brings the conversations from our popular LinkedIn Live series directly to your favorite podcast platform. Each episode explores the world of open, interoperable automation powered by IEC 61499. Join industry leaders, innovators, and experts as they share real-world applications, success stories, and insights that are shaping the future of industrial automation.

Whether you are an engineer, a technology leader, or simply passionate about the next wave of automation, this podcast is your go-to source for cutting-edge discussions, practical knowledge, and thought leadership.

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

About UAO Goes Live: The Future of Automation

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Description

In this episode of UAO Goes Live, our Chief Architect unveils Runtime Execution Engine V24.1.

Fixes address Ethernet/IP explicit messaging, MQTT stability and throughput, Modbus register handling, and mixed Ethernet/IP + PROFINET deployments.

About UniversalAutomation.org (UAO)

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Transcription

Speaker #0
Hi everyone and welcome to this newest session of UAO Goes Live. Today, very interesting topic, we'll go towards a new and discover a new version of the UAO runtime execution engine, the v24.1. You surely remember as we released the latest runtime version, it was last December, the v24.0, and we've made some demonstrations about it and so on. And now we want to bring to you the newest features, which are... coming with this newest version. But to talk a bit more details about it, I want to welcome on the stage, Sarath. Hi, Sarath. Hi, David.
Speaker #1
Hi, Greg. I'm doing good. Thank you. How are you?
Speaker #0
Yeah, doing good. Thanks. So, Sarath, you are our chief architect officer, so you have the honor and the privilege to show us a bit more about the runtime execution engine, but can you introduce yourself maybe shortly to the audience?
Speaker #1
Yes. Hello. A warm welcome to you all. Myself, Sarath Kumar Reddy Malakasima, the Chief Architect for Universal Automation. I'm here to present you the new version of the Universal Automation runtime that we are bringing to you this month. Thank you.
Speaker #0
Great. So maybe, Sarath, we can jump on to, I think you have a presentation for us.
Speaker #1
we can maybe share the presentation on the stage and uh yeah so here we go thank you all again a warm welcome to you all uh today i'm here to present you about the new version of the universal automation runtime uh which is the version 24.1 this goes live this month i will now take you into the details of this runtime so This new release is based on the EcoStruxure Automation Expert 24.1. I will talk a bit about what are these new features and what enhancements are done and also what fixes are done. And what could you expect going forward in the future release? So these are the three major topics that I'm going to talk about. Let's say the first bullet is just an information.
Speaker #0
Just before we jump to the explanation about the feature, can you? shortly explain what is EcoStruxure Automation Expert for the viewers who don't really know a bit, a lot about Universal Automation and technology?
Speaker #1
Yes, so EcoStruxure Automation Expert is a product or offering from Schneider Electric which is based on the Universal Automation Runtime. This comes with two major components. The Runtime component is based on the Universal Automation Runtime reference implementation and a build time tool. called as eae ide integrated development environment which allows you to program the runtime and develop the control application and deploy that to the runtime thank you greg for reminding me of that okay so now i move on to the features enhancements and fixes which are part of this new release so let's start with the new features a new set of function blocks add are added to support Modbus explicit reads and writes. If you are wondering what is an explicit read and write, in general to communicate with the Ivo subsystem which is Modbus based, you end up creating a bus master and then creating several hardware cats under the bus master in order to cyclically read this Ivo at specified scan rate. Now as part of your application development, you encounter a situation wherein apart from the cyclic scan maybe there is a specific register based on which you want to run your remaining application logic and you don't want this register to be read cyclically so in such a scenario you could use an explicit read to read this register value and then based on the value you could build your application logic on what exactly you want to do there and same is the case with write there will be there are scenarios wherein you want to update a register value in the device which then triggers something else in the operation side you could use an explicit write from application but you want to do this right only based on your application logic then you use this explicit right so this brings in lot of flexibility in application development especially in cases where you are trying to build an application logic that is based on what is happening in the field in the plant or in the process Then comes the other one, which is the update of third-party libraries to newer versions. This is something which is a very constant effort that continues to happen over releases. Always, it's advantageous and good to use the latest version of libraries because most of the versions contain fixes for cybersecurity issues and other things, even from a cybersecurity standpoint audit. it's important that you keep upgrading your library versions to the newer versions. In the same line, there is also an update to the OPCUS stack to version 1.8.x which has some bug fix patches as part of this version of the stack. There is also constant ongoing effort in reducing the technical depth which is doing code refactoring to improve the performance, to improve the reliability of the runtime and the stability of the runtime. So there has been a significant code refactoring done. SDL improvements, yes, secure development lifecycle improvements, especially fixing issues identified in penetration testing or different types of cybersecurity testing. They are also part of this release. There also have been some improvements to the WebSocket server, which is part of the runtime. And this WebSocket server is the core to the runtime responsible for accepting all the other requests like deployment, watch and debug and most of these core functionalities. There has been a significant enhancement to the way the MQTT connection is managed. You can manage it much better now. There have been certain connection drops in the previous implementation. They are being addressed to this enhanced connection management mechanism. With respect to PROFINET, There has been an enhancement for our cyclic messages and alarm data exchange. Let me remind you all, in order to use PROFINET, you need to use the softing stack, which is license-based. So as a vendor who is using UAO Runtime in your offer, you need to get access to this PROFINET license and the stack to use it.
Speaker #0
And the PROFINET implementation? was done with the last version, the V24.0, no?
Speaker #1
It came into, the first version was in 23.1, but not through the full functionality, but 24.0 did bring some additional functions. And now in 24.1, whatever was existing in 23.1 and 24.0, this isoclic messaging part and the alarm data exchange has been greatly improved. and this is done specifically to get the CCA level certification as well. There is also support for function code 43 which is and subcode 14 for the Modbus server security improvement. As you all know the Modbus spec has been updated to introduce some cyber security parts. There also has been some improvement done in terms of the making OPCS server and client more responsive. this basically is again a bit of code refactoring and clearing of the technical debt so this is what is uh there as new feature set available to you in the new release that that we are going to do this month it's already available in github you can go and download it and use it and on the fixes side again as you can see most of the work has been done on ethernet ip explicit part as i explained in case of modbus the explicit messaging or explicit possibility to read and write I-O values, you have the same possibility on the EIP side. There have been some issues on that and they are being addressed and fixed. There were some similar issues on the MQTT side, they too are addressed. Modbus slave, there was a intelligent function introduced to reduce the configuration effort to auto-calculate the register addresses there has been some issue with it and that's that is being fixed uh there was also situations where a segmentation fault used to occur when uh application uh were using ethernet ip and profinet together if they were used uh on different controllers there was no issue but if the same thing was used on the same controller there were issues and that is being address and a behavioral improvement is done. in the NetIvo block to deal with the secure TCP using the certificate mechanism. That's one improvement, especially towards making the NetIO communication secure. Again, there was a segmentation fault with MQTT in some specific scenarios, especially in an overloaded situation. That also is addressed and a great improvement is done in terms of number of MQTT message exchanges that could be done in a specified period of time. Again, some specific fixes were done in Modbus library and Modbus registers, Modbus implementation to address some of the bugs that were noticed either during testing or at later stages coming from the customers. So this is what you see as the new release of UAO Runtime. We urge you to quickly upgrade your offers to this newest release to leverage the new features and also to make the runtime more reliable and stable with all these fixes now i am going to move on to presenting you what could you expect in the future release of the runtime hardware configuration online change as you all know if you want to add new io points under a bus master today you have to restart the runtime to bring in the new configuration to work there is an effort in progress to allow this change without the need to really restart the runtime 64-bit runtime we have been mentioning this for a long long time i would say but again it's complex it's not so easy so this is being worked out especially to deal with the complex situations like you have a system with a 32-bit runtime or now you are bringing 64-bit runtime into place adding new controllers you want them to interoperate work together and all this so it's a bit complex so it's taking a bit of time same is the case with llvm compiler if you are if you're going to use a new system probably it's quite easy to use devices which are 64-bit and use llvm compiler but this is not let's say the most common scenario the most common scenario is all you always have a mix up of things and that's what is pulling back bringing these two features into the runtime time. in a quicker time then as i mentioned in the new features enhancements are done in profinet for cca compliance preparation this effort will continue and you will see more changes and enhancements done on the profinet side in order to qualify the solution for cca certification modbus tcp server for high available ua ort is is another important feature There have been requests from members who are using the high availability version of the runtime to have the Modbus TCP server added to the high availability part. This effort is in progress and this is something that you could expect end of this year or beginning of next year. EtherCAT, there has been a significant effort put into this to build a proof of concept and do the performance evaluation to make sure when it is brought into Thank you. the runtime, it is able to deliver the similar performance or even better performance when it is put to use in real-time projects. The UTF-8 string encoding support, this effort was also started. You can expect this sometime this year or next year. This is a very important item for IT-OT integration. Then there is an effort that got started for OpenAdapter. but i would say it will take a bit of time before you could see come into existence because this is having a very broad scope to be covered uh to be able to get devices from different solutions to talk to each other to be able to get devices talk to external services uh in an open way and all this so this this is more a long-term effort but you will see bits and pieces of it available in the runtime which you could use uh based on what it can provide So this is what you could expect in the future releases of the Universal Automation runtime. This is all I have packed for you today. And if any one of you has any question, I'm happy to answer it.
Speaker #0
Thank you, Sarath. So, yeah, let's see with the audience if there are any other questions coming. One question from my side. You are talking about that the audience should upgrade their, let's say, runtime to the newest version. task that is for the user of automation, like user of any, let's say, product on which a runtime is running, or is it something for the vendor of automation?
Speaker #1
So it starts with the vendor. The vendors have to regenerate or recompile the image for their device using the new version of the runtime, and then give it to the end users, and then end users will upgrade their system to use. this new image so it does involve both of them but it starts with the vendors who have offers in the market with our runtime to upgrade their images images and then share it with the end users to to let them upgrade their systems to use the new image good
Speaker #0
okay thank you for for making it clear. I would say since they are so okay, I see now Some questions coming from the chat. Let me read that for you. In terms of open adapters in the future, would that be for 649 or also for 61131? Question from Pierre.
Speaker #1
Okay, great. A very interesting question. Yes, the purpose of open adapter here is to really keep it open, which means it welcomes our... it encourages the idea of integrating desperate systems. When I say desperate systems, a system which is using 61499 and a system which is not 61499. Here in this case, it could be 61131. There is effort from our side to make sure we define and implement this open adapter in an open way that other systems can easily embrace and implement it to see this open connection between the two systems. Sure, we are representatives of the Universal Automation and 61499. So we are creating the possibility from this end. At the same time, it is for the vendors to encourage adopting it on the other end so that the systems can be seamlessly integrated and talking to each other.
Speaker #0
On taking that question as well, Sarath, can you explain to the audience the concept of adapters, maybe? Before we turn to open adapters.
Speaker #1
Yeah. So adapter is a object which binds together multiple data items. For example, let's say you're trying to transfer three data variables or multiple data variables from one block to the other block. In order to reduce the engineering effort, in order to make it simple to configure and connect, you could pack in this data variables data items into one adapter and then it's a single line connection going from one block to the other block which makes the life of the application developer much simple and use it easy to use for example if i have to take it into the context of for example let's say opaf and opas you could use adapter to define an opcus signal an opa signal And this signal can be a single line going from one OPAS block to the other OPAS block. I'm just trying to throw an idea at you, but that's what is the importance of the adapter.
Speaker #0
So it's kind of what is called as well the single line engineering, you know? Exactly. One single line, engineering data, I mean, communication plus events.
Speaker #1
Yeah, together.
Speaker #0
In one line. Okay, just to make it clear, because we have sometimes some viewers who are new to the 6479 world, so all those concepts need to be clear. I don't see any other questions from the chat right now, so maybe I go on with my other question, which is, I hear a lot lately, especially about those virtual PLCs. I take the opportunity that we have you on stage to talk a bit about that topic. Because I also hear, yeah, now that we have virtual PSCs on the market, I mean, why do we need universalautomation.org? That's one of the questions that comes as well to me. So maybe you can explain to the audience a bit more about, yeah, what is virtual PSC, what we do at universalautomation.org and so on.
Speaker #1
Excellent question, Greg, I would say. Yeah, sure, it's not directly connected to the runtime release, but I think it's a very, very important topic that needs to be clear to everyone. What is a virtual PLC and how does it compare to what Universal Automation is doing and what Universal Automation runtime is meant for? Thank you for asking this question. Let me quickly bring up one slide that I have that I will use as an aid to explain this. Okay?
Speaker #0
Yeah.
Speaker #1
Okay, so yes, breaking the vendor lock, of course, is important, but it is not a single lock that is responsible for this vendor locking of the system. Actually, there are multiple locks at multiple levels that needs to be unlocked if you want to break the vendor lock completely. Okay, so as you can see here, there are three different approaches that are taken today. for example the classic plc where the hardware is proprietary the platform is proprietary the control runtime is proprietary and then the control application is proprietary which means each of these layers are locked together you cannot use a different control application with the same control runtime you cannot use a different control runtime with the platform you cannot use this platform on a different hardware which kind of makes it a full lock that means If you go with this approach, you are completely locked to the vendor of the PLC. Now, the next step is something which, in a way, was already used largely in the IT industry. Let's say industrial automation, in a sense, is running behind here. The IT brought in this possibility of virtualizing the hardware. In technical terms, it's called a Type 1 hypervisor. So if you use this hypervisor. it kind of virtualizes the hardware and gives you the ability to run the same software on multiple hardware or you can also kind of share the hardware across multiple software multiple different types of software right so this is one level of virtualization which gives you freedom to build a software which you could run on any hardware provided you have the same hypervisor available this kind of largely Hmm. started i mean or created the opportunity to come up with this virtual plc then there is an another layer of abstraction or virtualization if you want to call it which is on top of the platform which is the operating system here and again a parallel to what is happening in the it world you you have windows operating system running on the hardware and this operating system acts as a host and lets you run multiple guest operating systems like you can run linux you can write different other types of operating systems on top of the existing operating system. This also gives you leverage to build something, a control runtime or a virtual PLC, which kind of gives you freedom in terms of, okay, my virtual PLC can be now deployed and run on different hardware and can also be deployed and run different operating system. But the lock between the control runtime and the control application still exists, which means if you are going with taking one of the solution virtual PLC from a particular vendor. Yes, you could run this virtual PLC on ARM, you could run this virtual PLC on x86, you could run this virtual PLC on Windows, you could run this virtual PLC on Linux, but still the control application what you created to run on this control runtime can only be run on this control runtime. It cannot be run on any other virtual PLC. So, there is still a lock which is unlocked here. Now How do we address this? How does what kind of approach that universal automation take here in comparison to virtual PLC? So, the universal automation here what we do is instead of creating a binary contract to break this lock, we have embraced the model of shared control runtime source code which is very similar to the way the Linux kernel works. If you look at the existing Linux operating systems most of them they use the same kernel so and then this kernel is an open source so every every linux since it is using the same kernel most of the software applications built for one linux are compatible to the other linux especially if you are not using vendor specific functions and features which are built on the built on top of the core runtime so the same principle applies here now with this approach we are able to unlock the possibility to develop control applications that can now be deployed onto different devices, irrespective of the hardware, irrespective of the operating system. They can now run on multiple vendor devices and multiple vendor solutions. Again, because it's a shared source model, we are not dictating the actual deployment model, which means do you want to run it like a classical PLC? Do you want to run it as a virtual PLC, leveraging the hardware virtualization? Do you want to run it as a Docker container, leveraging the OS level abstraction and virtualization? We don't dictate anything. We say, we enable you to do what you want. And this is one big differentiation that universal automation brings to the industry. I hope I'm very clear in explaining all this.
Speaker #0
Makes sense. Makes sense. And at least it's, let's say, shed some lights on the topics because... for sure especially right now we see a lot of companies coming up with virtual psc's let's say systems or or solutions or offers and yeah it comes often to the question yeah what's then if we have that why do we need why do we need universal automation and but actually Another question to you, because, yeah, since you're here, this UAO runtime that we have, for sure, this shared source code, can I still have it run on the server? Can I still have it run, or am I kind of still obliged to use a typical traditional PLC to use this runtime?
Speaker #1
Yeah, that's, I think. A very, very basic question that comes to everyone's mind. Where can I run this? Can I run it on my personal computer? Can I run it on Raspberry Pi? Can I run it on a rack server? Can I run it on a cloud? Yes, you can run anywhere you want to. However, you need to be calculative about the resources available and what services and functions you enable in the runtime. For example, you want to use OPC UA. which kind of consumes quite amount of resources, both in terms of memory and processing power. Probably if you try to run it on a simple controller with less than gigahertz processing power and very mean RAM like 256 MB or so on and so forth, that could be a bit challenging. So if you are taking care of this balance between which services you are enabling in the runtime, and on which resource you are trying to run it, you could run it anywhere.
Speaker #0
So it makes, okay, then it gives us a complete picture on where to use and how to use the whole thing in the runtime. So I don't see any other question from the chat or from the audience. So thank you, Sarath, for sharing your knowledge. sharing about the v24.1 version. I see your contact details are just shown on the bottom inside of the screen, so people can contact you if they need to.
Speaker #1
Yeah, definitely.
Speaker #0
I thank our viewers and wish them a very good summertime because the summer season has already well started. So I'm sure some of them are... maybe watching us from the beach and uh and enjoying this uh this this session and uh we'll come back in uh september with our newest sessions and and newest information about what is happening within euros automation.org and um which what are the the vendors doing the the users doing and so on before i forget Just one reminder, we are co-organizing an event, let's say two days, as part of the IEEE ETF 2025 in Porto. And as part of these two days, we are co-organizing on the 9th of September. a workshop which will be dedicated to the 649 technology. So quite informative sessions, a lot of good presentations. So we invite everyone to join that and you can see the events and get some more information by registering on the events on the LinkedIn event of universeautomation.org. Same on the 10th, which will be the industry day. during the IEEE ETFA event, where there will be some quite interesting panels with a lot of people coming from members, coming from different sides of the member base of the association. So for sure, we will have people coming from the academia, the SI, the vendors, and so on. Very interesting sessions. And we invite you all to have a look into that and to come and join us in Porto. So that's the end of this session, Saad. Thank you again for making it.
Speaker #1
Yeah, I just want to add that I'm available at the event. I'm present on day one and first half of the day, day two. So if anyone is interested in sideline conversations, discussing something.
Speaker #0
i'm available good thank you sarat thank you everyone and see you in september see you bye bye see you bye

About UAO Goes Live: The Future of Automation

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

About UAO Goes Live: The Future of Automation

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Embed

You may also like

Description

In this episode of UAO Goes Live, our Chief Architect unveils Runtime Execution Engine V24.1.

Fixes address Ethernet/IP explicit messaging, MQTT stability and throughput, Modbus register handling, and mixed Ethernet/IP + PROFINET deployments.

About UniversalAutomation.org (UAO)

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Transcription

Speaker #0
Hi everyone and welcome to this newest session of UAO Goes Live. Today, very interesting topic, we'll go towards a new and discover a new version of the UAO runtime execution engine, the v24.1. You surely remember as we released the latest runtime version, it was last December, the v24.0, and we've made some demonstrations about it and so on. And now we want to bring to you the newest features, which are... coming with this newest version. But to talk a bit more details about it, I want to welcome on the stage, Sarath. Hi, Sarath. Hi, David.
Speaker #1
Hi, Greg. I'm doing good. Thank you. How are you?
Speaker #0
Yeah, doing good. Thanks. So, Sarath, you are our chief architect officer, so you have the honor and the privilege to show us a bit more about the runtime execution engine, but can you introduce yourself maybe shortly to the audience?
Speaker #1
Yes. Hello. A warm welcome to you all. Myself, Sarath Kumar Reddy Malakasima, the Chief Architect for Universal Automation. I'm here to present you the new version of the Universal Automation runtime that we are bringing to you this month. Thank you.
Speaker #0
Great. So maybe, Sarath, we can jump on to, I think you have a presentation for us.
Speaker #1
we can maybe share the presentation on the stage and uh yeah so here we go thank you all again a warm welcome to you all uh today i'm here to present you about the new version of the universal automation runtime uh which is the version 24.1 this goes live this month i will now take you into the details of this runtime so This new release is based on the EcoStruxure Automation Expert 24.1. I will talk a bit about what are these new features and what enhancements are done and also what fixes are done. And what could you expect going forward in the future release? So these are the three major topics that I'm going to talk about. Let's say the first bullet is just an information.
Speaker #0
Just before we jump to the explanation about the feature, can you? shortly explain what is EcoStruxure Automation Expert for the viewers who don't really know a bit, a lot about Universal Automation and technology?
Speaker #1
Yes, so EcoStruxure Automation Expert is a product or offering from Schneider Electric which is based on the Universal Automation Runtime. This comes with two major components. The Runtime component is based on the Universal Automation Runtime reference implementation and a build time tool. called as eae ide integrated development environment which allows you to program the runtime and develop the control application and deploy that to the runtime thank you greg for reminding me of that okay so now i move on to the features enhancements and fixes which are part of this new release so let's start with the new features a new set of function blocks add are added to support Modbus explicit reads and writes. If you are wondering what is an explicit read and write, in general to communicate with the Ivo subsystem which is Modbus based, you end up creating a bus master and then creating several hardware cats under the bus master in order to cyclically read this Ivo at specified scan rate. Now as part of your application development, you encounter a situation wherein apart from the cyclic scan maybe there is a specific register based on which you want to run your remaining application logic and you don't want this register to be read cyclically so in such a scenario you could use an explicit read to read this register value and then based on the value you could build your application logic on what exactly you want to do there and same is the case with write there will be there are scenarios wherein you want to update a register value in the device which then triggers something else in the operation side you could use an explicit write from application but you want to do this right only based on your application logic then you use this explicit right so this brings in lot of flexibility in application development especially in cases where you are trying to build an application logic that is based on what is happening in the field in the plant or in the process Then comes the other one, which is the update of third-party libraries to newer versions. This is something which is a very constant effort that continues to happen over releases. Always, it's advantageous and good to use the latest version of libraries because most of the versions contain fixes for cybersecurity issues and other things, even from a cybersecurity standpoint audit. it's important that you keep upgrading your library versions to the newer versions. In the same line, there is also an update to the OPCUS stack to version 1.8.x which has some bug fix patches as part of this version of the stack. There is also constant ongoing effort in reducing the technical depth which is doing code refactoring to improve the performance, to improve the reliability of the runtime and the stability of the runtime. So there has been a significant code refactoring done. SDL improvements, yes, secure development lifecycle improvements, especially fixing issues identified in penetration testing or different types of cybersecurity testing. They are also part of this release. There also have been some improvements to the WebSocket server, which is part of the runtime. And this WebSocket server is the core to the runtime responsible for accepting all the other requests like deployment, watch and debug and most of these core functionalities. There has been a significant enhancement to the way the MQTT connection is managed. You can manage it much better now. There have been certain connection drops in the previous implementation. They are being addressed to this enhanced connection management mechanism. With respect to PROFINET, There has been an enhancement for our cyclic messages and alarm data exchange. Let me remind you all, in order to use PROFINET, you need to use the softing stack, which is license-based. So as a vendor who is using UAO Runtime in your offer, you need to get access to this PROFINET license and the stack to use it.
Speaker #0
And the PROFINET implementation? was done with the last version, the V24.0, no?
Speaker #1
It came into, the first version was in 23.1, but not through the full functionality, but 24.0 did bring some additional functions. And now in 24.1, whatever was existing in 23.1 and 24.0, this isoclic messaging part and the alarm data exchange has been greatly improved. and this is done specifically to get the CCA level certification as well. There is also support for function code 43 which is and subcode 14 for the Modbus server security improvement. As you all know the Modbus spec has been updated to introduce some cyber security parts. There also has been some improvement done in terms of the making OPCS server and client more responsive. this basically is again a bit of code refactoring and clearing of the technical debt so this is what is uh there as new feature set available to you in the new release that that we are going to do this month it's already available in github you can go and download it and use it and on the fixes side again as you can see most of the work has been done on ethernet ip explicit part as i explained in case of modbus the explicit messaging or explicit possibility to read and write I-O values, you have the same possibility on the EIP side. There have been some issues on that and they are being addressed and fixed. There were some similar issues on the MQTT side, they too are addressed. Modbus slave, there was a intelligent function introduced to reduce the configuration effort to auto-calculate the register addresses there has been some issue with it and that's that is being fixed uh there was also situations where a segmentation fault used to occur when uh application uh were using ethernet ip and profinet together if they were used uh on different controllers there was no issue but if the same thing was used on the same controller there were issues and that is being address and a behavioral improvement is done. in the NetIvo block to deal with the secure TCP using the certificate mechanism. That's one improvement, especially towards making the NetIO communication secure. Again, there was a segmentation fault with MQTT in some specific scenarios, especially in an overloaded situation. That also is addressed and a great improvement is done in terms of number of MQTT message exchanges that could be done in a specified period of time. Again, some specific fixes were done in Modbus library and Modbus registers, Modbus implementation to address some of the bugs that were noticed either during testing or at later stages coming from the customers. So this is what you see as the new release of UAO Runtime. We urge you to quickly upgrade your offers to this newest release to leverage the new features and also to make the runtime more reliable and stable with all these fixes now i am going to move on to presenting you what could you expect in the future release of the runtime hardware configuration online change as you all know if you want to add new io points under a bus master today you have to restart the runtime to bring in the new configuration to work there is an effort in progress to allow this change without the need to really restart the runtime 64-bit runtime we have been mentioning this for a long long time i would say but again it's complex it's not so easy so this is being worked out especially to deal with the complex situations like you have a system with a 32-bit runtime or now you are bringing 64-bit runtime into place adding new controllers you want them to interoperate work together and all this so it's a bit complex so it's taking a bit of time same is the case with llvm compiler if you are if you're going to use a new system probably it's quite easy to use devices which are 64-bit and use llvm compiler but this is not let's say the most common scenario the most common scenario is all you always have a mix up of things and that's what is pulling back bringing these two features into the runtime time. in a quicker time then as i mentioned in the new features enhancements are done in profinet for cca compliance preparation this effort will continue and you will see more changes and enhancements done on the profinet side in order to qualify the solution for cca certification modbus tcp server for high available ua ort is is another important feature There have been requests from members who are using the high availability version of the runtime to have the Modbus TCP server added to the high availability part. This effort is in progress and this is something that you could expect end of this year or beginning of next year. EtherCAT, there has been a significant effort put into this to build a proof of concept and do the performance evaluation to make sure when it is brought into Thank you. the runtime, it is able to deliver the similar performance or even better performance when it is put to use in real-time projects. The UTF-8 string encoding support, this effort was also started. You can expect this sometime this year or next year. This is a very important item for IT-OT integration. Then there is an effort that got started for OpenAdapter. but i would say it will take a bit of time before you could see come into existence because this is having a very broad scope to be covered uh to be able to get devices from different solutions to talk to each other to be able to get devices talk to external services uh in an open way and all this so this this is more a long-term effort but you will see bits and pieces of it available in the runtime which you could use uh based on what it can provide So this is what you could expect in the future releases of the Universal Automation runtime. This is all I have packed for you today. And if any one of you has any question, I'm happy to answer it.
Speaker #0
Thank you, Sarath. So, yeah, let's see with the audience if there are any other questions coming. One question from my side. You are talking about that the audience should upgrade their, let's say, runtime to the newest version. task that is for the user of automation, like user of any, let's say, product on which a runtime is running, or is it something for the vendor of automation?
Speaker #1
So it starts with the vendor. The vendors have to regenerate or recompile the image for their device using the new version of the runtime, and then give it to the end users, and then end users will upgrade their system to use. this new image so it does involve both of them but it starts with the vendors who have offers in the market with our runtime to upgrade their images images and then share it with the end users to to let them upgrade their systems to use the new image good
Speaker #0
okay thank you for for making it clear. I would say since they are so okay, I see now Some questions coming from the chat. Let me read that for you. In terms of open adapters in the future, would that be for 649 or also for 61131? Question from Pierre.
Speaker #1
Okay, great. A very interesting question. Yes, the purpose of open adapter here is to really keep it open, which means it welcomes our... it encourages the idea of integrating desperate systems. When I say desperate systems, a system which is using 61499 and a system which is not 61499. Here in this case, it could be 61131. There is effort from our side to make sure we define and implement this open adapter in an open way that other systems can easily embrace and implement it to see this open connection between the two systems. Sure, we are representatives of the Universal Automation and 61499. So we are creating the possibility from this end. At the same time, it is for the vendors to encourage adopting it on the other end so that the systems can be seamlessly integrated and talking to each other.
Speaker #0
On taking that question as well, Sarath, can you explain to the audience the concept of adapters, maybe? Before we turn to open adapters.
Speaker #1
Yeah. So adapter is a object which binds together multiple data items. For example, let's say you're trying to transfer three data variables or multiple data variables from one block to the other block. In order to reduce the engineering effort, in order to make it simple to configure and connect, you could pack in this data variables data items into one adapter and then it's a single line connection going from one block to the other block which makes the life of the application developer much simple and use it easy to use for example if i have to take it into the context of for example let's say opaf and opas you could use adapter to define an opcus signal an opa signal And this signal can be a single line going from one OPAS block to the other OPAS block. I'm just trying to throw an idea at you, but that's what is the importance of the adapter.
Speaker #0
So it's kind of what is called as well the single line engineering, you know? Exactly. One single line, engineering data, I mean, communication plus events.
Speaker #1
Yeah, together.
Speaker #0
In one line. Okay, just to make it clear, because we have sometimes some viewers who are new to the 6479 world, so all those concepts need to be clear. I don't see any other questions from the chat right now, so maybe I go on with my other question, which is, I hear a lot lately, especially about those virtual PLCs. I take the opportunity that we have you on stage to talk a bit about that topic. Because I also hear, yeah, now that we have virtual PSCs on the market, I mean, why do we need universalautomation.org? That's one of the questions that comes as well to me. So maybe you can explain to the audience a bit more about, yeah, what is virtual PSC, what we do at universalautomation.org and so on.
Speaker #1
Excellent question, Greg, I would say. Yeah, sure, it's not directly connected to the runtime release, but I think it's a very, very important topic that needs to be clear to everyone. What is a virtual PLC and how does it compare to what Universal Automation is doing and what Universal Automation runtime is meant for? Thank you for asking this question. Let me quickly bring up one slide that I have that I will use as an aid to explain this. Okay?
Speaker #0
Yeah.
Speaker #1
Okay, so yes, breaking the vendor lock, of course, is important, but it is not a single lock that is responsible for this vendor locking of the system. Actually, there are multiple locks at multiple levels that needs to be unlocked if you want to break the vendor lock completely. Okay, so as you can see here, there are three different approaches that are taken today. for example the classic plc where the hardware is proprietary the platform is proprietary the control runtime is proprietary and then the control application is proprietary which means each of these layers are locked together you cannot use a different control application with the same control runtime you cannot use a different control runtime with the platform you cannot use this platform on a different hardware which kind of makes it a full lock that means If you go with this approach, you are completely locked to the vendor of the PLC. Now, the next step is something which, in a way, was already used largely in the IT industry. Let's say industrial automation, in a sense, is running behind here. The IT brought in this possibility of virtualizing the hardware. In technical terms, it's called a Type 1 hypervisor. So if you use this hypervisor. it kind of virtualizes the hardware and gives you the ability to run the same software on multiple hardware or you can also kind of share the hardware across multiple software multiple different types of software right so this is one level of virtualization which gives you freedom to build a software which you could run on any hardware provided you have the same hypervisor available this kind of largely Hmm. started i mean or created the opportunity to come up with this virtual plc then there is an another layer of abstraction or virtualization if you want to call it which is on top of the platform which is the operating system here and again a parallel to what is happening in the it world you you have windows operating system running on the hardware and this operating system acts as a host and lets you run multiple guest operating systems like you can run linux you can write different other types of operating systems on top of the existing operating system. This also gives you leverage to build something, a control runtime or a virtual PLC, which kind of gives you freedom in terms of, okay, my virtual PLC can be now deployed and run on different hardware and can also be deployed and run different operating system. But the lock between the control runtime and the control application still exists, which means if you are going with taking one of the solution virtual PLC from a particular vendor. Yes, you could run this virtual PLC on ARM, you could run this virtual PLC on x86, you could run this virtual PLC on Windows, you could run this virtual PLC on Linux, but still the control application what you created to run on this control runtime can only be run on this control runtime. It cannot be run on any other virtual PLC. So, there is still a lock which is unlocked here. Now How do we address this? How does what kind of approach that universal automation take here in comparison to virtual PLC? So, the universal automation here what we do is instead of creating a binary contract to break this lock, we have embraced the model of shared control runtime source code which is very similar to the way the Linux kernel works. If you look at the existing Linux operating systems most of them they use the same kernel so and then this kernel is an open source so every every linux since it is using the same kernel most of the software applications built for one linux are compatible to the other linux especially if you are not using vendor specific functions and features which are built on the built on top of the core runtime so the same principle applies here now with this approach we are able to unlock the possibility to develop control applications that can now be deployed onto different devices, irrespective of the hardware, irrespective of the operating system. They can now run on multiple vendor devices and multiple vendor solutions. Again, because it's a shared source model, we are not dictating the actual deployment model, which means do you want to run it like a classical PLC? Do you want to run it as a virtual PLC, leveraging the hardware virtualization? Do you want to run it as a Docker container, leveraging the OS level abstraction and virtualization? We don't dictate anything. We say, we enable you to do what you want. And this is one big differentiation that universal automation brings to the industry. I hope I'm very clear in explaining all this.
Speaker #0
Makes sense. Makes sense. And at least it's, let's say, shed some lights on the topics because... for sure especially right now we see a lot of companies coming up with virtual psc's let's say systems or or solutions or offers and yeah it comes often to the question yeah what's then if we have that why do we need why do we need universal automation and but actually Another question to you, because, yeah, since you're here, this UAO runtime that we have, for sure, this shared source code, can I still have it run on the server? Can I still have it run, or am I kind of still obliged to use a typical traditional PLC to use this runtime?
Speaker #1
Yeah, that's, I think. A very, very basic question that comes to everyone's mind. Where can I run this? Can I run it on my personal computer? Can I run it on Raspberry Pi? Can I run it on a rack server? Can I run it on a cloud? Yes, you can run anywhere you want to. However, you need to be calculative about the resources available and what services and functions you enable in the runtime. For example, you want to use OPC UA. which kind of consumes quite amount of resources, both in terms of memory and processing power. Probably if you try to run it on a simple controller with less than gigahertz processing power and very mean RAM like 256 MB or so on and so forth, that could be a bit challenging. So if you are taking care of this balance between which services you are enabling in the runtime, and on which resource you are trying to run it, you could run it anywhere.
Speaker #0
So it makes, okay, then it gives us a complete picture on where to use and how to use the whole thing in the runtime. So I don't see any other question from the chat or from the audience. So thank you, Sarath, for sharing your knowledge. sharing about the v24.1 version. I see your contact details are just shown on the bottom inside of the screen, so people can contact you if they need to.
Speaker #1
Yeah, definitely.
Speaker #0
I thank our viewers and wish them a very good summertime because the summer season has already well started. So I'm sure some of them are... maybe watching us from the beach and uh and enjoying this uh this this session and uh we'll come back in uh september with our newest sessions and and newest information about what is happening within euros automation.org and um which what are the the vendors doing the the users doing and so on before i forget Just one reminder, we are co-organizing an event, let's say two days, as part of the IEEE ETF 2025 in Porto. And as part of these two days, we are co-organizing on the 9th of September. a workshop which will be dedicated to the 649 technology. So quite informative sessions, a lot of good presentations. So we invite everyone to join that and you can see the events and get some more information by registering on the events on the LinkedIn event of universeautomation.org. Same on the 10th, which will be the industry day. during the IEEE ETFA event, where there will be some quite interesting panels with a lot of people coming from members, coming from different sides of the member base of the association. So for sure, we will have people coming from the academia, the SI, the vendors, and so on. Very interesting sessions. And we invite you all to have a look into that and to come and join us in Porto. So that's the end of this session, Saad. Thank you again for making it.
Speaker #1
Yeah, I just want to add that I'm available at the event. I'm present on day one and first half of the day, day two. So if anyone is interested in sideline conversations, discussing something.
Speaker #0
i'm available good thank you sarat thank you everyone and see you in september see you bye bye see you bye

About UAO Goes Live: The Future of Automation

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

About UAO Goes Live: The Future of Automation

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Description

In this episode of UAO Goes Live, our Chief Architect unveils Runtime Execution Engine V24.1.

Fixes address Ethernet/IP explicit messaging, MQTT stability and throughput, Modbus register handling, and mixed Ethernet/IP + PROFINET deployments.

About UniversalAutomation.org (UAO)

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Transcription

Speaker #0
Hi everyone and welcome to this newest session of UAO Goes Live. Today, very interesting topic, we'll go towards a new and discover a new version of the UAO runtime execution engine, the v24.1. You surely remember as we released the latest runtime version, it was last December, the v24.0, and we've made some demonstrations about it and so on. And now we want to bring to you the newest features, which are... coming with this newest version. But to talk a bit more details about it, I want to welcome on the stage, Sarath. Hi, Sarath. Hi, David.
Speaker #1
Hi, Greg. I'm doing good. Thank you. How are you?
Speaker #0
Yeah, doing good. Thanks. So, Sarath, you are our chief architect officer, so you have the honor and the privilege to show us a bit more about the runtime execution engine, but can you introduce yourself maybe shortly to the audience?
Speaker #1
Yes. Hello. A warm welcome to you all. Myself, Sarath Kumar Reddy Malakasima, the Chief Architect for Universal Automation. I'm here to present you the new version of the Universal Automation runtime that we are bringing to you this month. Thank you.
Speaker #0
Great. So maybe, Sarath, we can jump on to, I think you have a presentation for us.
Speaker #1
we can maybe share the presentation on the stage and uh yeah so here we go thank you all again a warm welcome to you all uh today i'm here to present you about the new version of the universal automation runtime uh which is the version 24.1 this goes live this month i will now take you into the details of this runtime so This new release is based on the EcoStruxure Automation Expert 24.1. I will talk a bit about what are these new features and what enhancements are done and also what fixes are done. And what could you expect going forward in the future release? So these are the three major topics that I'm going to talk about. Let's say the first bullet is just an information.
Speaker #0
Just before we jump to the explanation about the feature, can you? shortly explain what is EcoStruxure Automation Expert for the viewers who don't really know a bit, a lot about Universal Automation and technology?
Speaker #1
Yes, so EcoStruxure Automation Expert is a product or offering from Schneider Electric which is based on the Universal Automation Runtime. This comes with two major components. The Runtime component is based on the Universal Automation Runtime reference implementation and a build time tool. called as eae ide integrated development environment which allows you to program the runtime and develop the control application and deploy that to the runtime thank you greg for reminding me of that okay so now i move on to the features enhancements and fixes which are part of this new release so let's start with the new features a new set of function blocks add are added to support Modbus explicit reads and writes. If you are wondering what is an explicit read and write, in general to communicate with the Ivo subsystem which is Modbus based, you end up creating a bus master and then creating several hardware cats under the bus master in order to cyclically read this Ivo at specified scan rate. Now as part of your application development, you encounter a situation wherein apart from the cyclic scan maybe there is a specific register based on which you want to run your remaining application logic and you don't want this register to be read cyclically so in such a scenario you could use an explicit read to read this register value and then based on the value you could build your application logic on what exactly you want to do there and same is the case with write there will be there are scenarios wherein you want to update a register value in the device which then triggers something else in the operation side you could use an explicit write from application but you want to do this right only based on your application logic then you use this explicit right so this brings in lot of flexibility in application development especially in cases where you are trying to build an application logic that is based on what is happening in the field in the plant or in the process Then comes the other one, which is the update of third-party libraries to newer versions. This is something which is a very constant effort that continues to happen over releases. Always, it's advantageous and good to use the latest version of libraries because most of the versions contain fixes for cybersecurity issues and other things, even from a cybersecurity standpoint audit. it's important that you keep upgrading your library versions to the newer versions. In the same line, there is also an update to the OPCUS stack to version 1.8.x which has some bug fix patches as part of this version of the stack. There is also constant ongoing effort in reducing the technical depth which is doing code refactoring to improve the performance, to improve the reliability of the runtime and the stability of the runtime. So there has been a significant code refactoring done. SDL improvements, yes, secure development lifecycle improvements, especially fixing issues identified in penetration testing or different types of cybersecurity testing. They are also part of this release. There also have been some improvements to the WebSocket server, which is part of the runtime. And this WebSocket server is the core to the runtime responsible for accepting all the other requests like deployment, watch and debug and most of these core functionalities. There has been a significant enhancement to the way the MQTT connection is managed. You can manage it much better now. There have been certain connection drops in the previous implementation. They are being addressed to this enhanced connection management mechanism. With respect to PROFINET, There has been an enhancement for our cyclic messages and alarm data exchange. Let me remind you all, in order to use PROFINET, you need to use the softing stack, which is license-based. So as a vendor who is using UAO Runtime in your offer, you need to get access to this PROFINET license and the stack to use it.
Speaker #0
And the PROFINET implementation? was done with the last version, the V24.0, no?
Speaker #1
It came into, the first version was in 23.1, but not through the full functionality, but 24.0 did bring some additional functions. And now in 24.1, whatever was existing in 23.1 and 24.0, this isoclic messaging part and the alarm data exchange has been greatly improved. and this is done specifically to get the CCA level certification as well. There is also support for function code 43 which is and subcode 14 for the Modbus server security improvement. As you all know the Modbus spec has been updated to introduce some cyber security parts. There also has been some improvement done in terms of the making OPCS server and client more responsive. this basically is again a bit of code refactoring and clearing of the technical debt so this is what is uh there as new feature set available to you in the new release that that we are going to do this month it's already available in github you can go and download it and use it and on the fixes side again as you can see most of the work has been done on ethernet ip explicit part as i explained in case of modbus the explicit messaging or explicit possibility to read and write I-O values, you have the same possibility on the EIP side. There have been some issues on that and they are being addressed and fixed. There were some similar issues on the MQTT side, they too are addressed. Modbus slave, there was a intelligent function introduced to reduce the configuration effort to auto-calculate the register addresses there has been some issue with it and that's that is being fixed uh there was also situations where a segmentation fault used to occur when uh application uh were using ethernet ip and profinet together if they were used uh on different controllers there was no issue but if the same thing was used on the same controller there were issues and that is being address and a behavioral improvement is done. in the NetIvo block to deal with the secure TCP using the certificate mechanism. That's one improvement, especially towards making the NetIO communication secure. Again, there was a segmentation fault with MQTT in some specific scenarios, especially in an overloaded situation. That also is addressed and a great improvement is done in terms of number of MQTT message exchanges that could be done in a specified period of time. Again, some specific fixes were done in Modbus library and Modbus registers, Modbus implementation to address some of the bugs that were noticed either during testing or at later stages coming from the customers. So this is what you see as the new release of UAO Runtime. We urge you to quickly upgrade your offers to this newest release to leverage the new features and also to make the runtime more reliable and stable with all these fixes now i am going to move on to presenting you what could you expect in the future release of the runtime hardware configuration online change as you all know if you want to add new io points under a bus master today you have to restart the runtime to bring in the new configuration to work there is an effort in progress to allow this change without the need to really restart the runtime 64-bit runtime we have been mentioning this for a long long time i would say but again it's complex it's not so easy so this is being worked out especially to deal with the complex situations like you have a system with a 32-bit runtime or now you are bringing 64-bit runtime into place adding new controllers you want them to interoperate work together and all this so it's a bit complex so it's taking a bit of time same is the case with llvm compiler if you are if you're going to use a new system probably it's quite easy to use devices which are 64-bit and use llvm compiler but this is not let's say the most common scenario the most common scenario is all you always have a mix up of things and that's what is pulling back bringing these two features into the runtime time. in a quicker time then as i mentioned in the new features enhancements are done in profinet for cca compliance preparation this effort will continue and you will see more changes and enhancements done on the profinet side in order to qualify the solution for cca certification modbus tcp server for high available ua ort is is another important feature There have been requests from members who are using the high availability version of the runtime to have the Modbus TCP server added to the high availability part. This effort is in progress and this is something that you could expect end of this year or beginning of next year. EtherCAT, there has been a significant effort put into this to build a proof of concept and do the performance evaluation to make sure when it is brought into Thank you. the runtime, it is able to deliver the similar performance or even better performance when it is put to use in real-time projects. The UTF-8 string encoding support, this effort was also started. You can expect this sometime this year or next year. This is a very important item for IT-OT integration. Then there is an effort that got started for OpenAdapter. but i would say it will take a bit of time before you could see come into existence because this is having a very broad scope to be covered uh to be able to get devices from different solutions to talk to each other to be able to get devices talk to external services uh in an open way and all this so this this is more a long-term effort but you will see bits and pieces of it available in the runtime which you could use uh based on what it can provide So this is what you could expect in the future releases of the Universal Automation runtime. This is all I have packed for you today. And if any one of you has any question, I'm happy to answer it.
Speaker #0
Thank you, Sarath. So, yeah, let's see with the audience if there are any other questions coming. One question from my side. You are talking about that the audience should upgrade their, let's say, runtime to the newest version. task that is for the user of automation, like user of any, let's say, product on which a runtime is running, or is it something for the vendor of automation?
Speaker #1
So it starts with the vendor. The vendors have to regenerate or recompile the image for their device using the new version of the runtime, and then give it to the end users, and then end users will upgrade their system to use. this new image so it does involve both of them but it starts with the vendors who have offers in the market with our runtime to upgrade their images images and then share it with the end users to to let them upgrade their systems to use the new image good
Speaker #0
okay thank you for for making it clear. I would say since they are so okay, I see now Some questions coming from the chat. Let me read that for you. In terms of open adapters in the future, would that be for 649 or also for 61131? Question from Pierre.
Speaker #1
Okay, great. A very interesting question. Yes, the purpose of open adapter here is to really keep it open, which means it welcomes our... it encourages the idea of integrating desperate systems. When I say desperate systems, a system which is using 61499 and a system which is not 61499. Here in this case, it could be 61131. There is effort from our side to make sure we define and implement this open adapter in an open way that other systems can easily embrace and implement it to see this open connection between the two systems. Sure, we are representatives of the Universal Automation and 61499. So we are creating the possibility from this end. At the same time, it is for the vendors to encourage adopting it on the other end so that the systems can be seamlessly integrated and talking to each other.
Speaker #0
On taking that question as well, Sarath, can you explain to the audience the concept of adapters, maybe? Before we turn to open adapters.
Speaker #1
Yeah. So adapter is a object which binds together multiple data items. For example, let's say you're trying to transfer three data variables or multiple data variables from one block to the other block. In order to reduce the engineering effort, in order to make it simple to configure and connect, you could pack in this data variables data items into one adapter and then it's a single line connection going from one block to the other block which makes the life of the application developer much simple and use it easy to use for example if i have to take it into the context of for example let's say opaf and opas you could use adapter to define an opcus signal an opa signal And this signal can be a single line going from one OPAS block to the other OPAS block. I'm just trying to throw an idea at you, but that's what is the importance of the adapter.
Speaker #0
So it's kind of what is called as well the single line engineering, you know? Exactly. One single line, engineering data, I mean, communication plus events.
Speaker #1
Yeah, together.
Speaker #0
In one line. Okay, just to make it clear, because we have sometimes some viewers who are new to the 6479 world, so all those concepts need to be clear. I don't see any other questions from the chat right now, so maybe I go on with my other question, which is, I hear a lot lately, especially about those virtual PLCs. I take the opportunity that we have you on stage to talk a bit about that topic. Because I also hear, yeah, now that we have virtual PSCs on the market, I mean, why do we need universalautomation.org? That's one of the questions that comes as well to me. So maybe you can explain to the audience a bit more about, yeah, what is virtual PSC, what we do at universalautomation.org and so on.
Speaker #1
Excellent question, Greg, I would say. Yeah, sure, it's not directly connected to the runtime release, but I think it's a very, very important topic that needs to be clear to everyone. What is a virtual PLC and how does it compare to what Universal Automation is doing and what Universal Automation runtime is meant for? Thank you for asking this question. Let me quickly bring up one slide that I have that I will use as an aid to explain this. Okay?
Speaker #0
Yeah.
Speaker #1
Okay, so yes, breaking the vendor lock, of course, is important, but it is not a single lock that is responsible for this vendor locking of the system. Actually, there are multiple locks at multiple levels that needs to be unlocked if you want to break the vendor lock completely. Okay, so as you can see here, there are three different approaches that are taken today. for example the classic plc where the hardware is proprietary the platform is proprietary the control runtime is proprietary and then the control application is proprietary which means each of these layers are locked together you cannot use a different control application with the same control runtime you cannot use a different control runtime with the platform you cannot use this platform on a different hardware which kind of makes it a full lock that means If you go with this approach, you are completely locked to the vendor of the PLC. Now, the next step is something which, in a way, was already used largely in the IT industry. Let's say industrial automation, in a sense, is running behind here. The IT brought in this possibility of virtualizing the hardware. In technical terms, it's called a Type 1 hypervisor. So if you use this hypervisor. it kind of virtualizes the hardware and gives you the ability to run the same software on multiple hardware or you can also kind of share the hardware across multiple software multiple different types of software right so this is one level of virtualization which gives you freedom to build a software which you could run on any hardware provided you have the same hypervisor available this kind of largely Hmm. started i mean or created the opportunity to come up with this virtual plc then there is an another layer of abstraction or virtualization if you want to call it which is on top of the platform which is the operating system here and again a parallel to what is happening in the it world you you have windows operating system running on the hardware and this operating system acts as a host and lets you run multiple guest operating systems like you can run linux you can write different other types of operating systems on top of the existing operating system. This also gives you leverage to build something, a control runtime or a virtual PLC, which kind of gives you freedom in terms of, okay, my virtual PLC can be now deployed and run on different hardware and can also be deployed and run different operating system. But the lock between the control runtime and the control application still exists, which means if you are going with taking one of the solution virtual PLC from a particular vendor. Yes, you could run this virtual PLC on ARM, you could run this virtual PLC on x86, you could run this virtual PLC on Windows, you could run this virtual PLC on Linux, but still the control application what you created to run on this control runtime can only be run on this control runtime. It cannot be run on any other virtual PLC. So, there is still a lock which is unlocked here. Now How do we address this? How does what kind of approach that universal automation take here in comparison to virtual PLC? So, the universal automation here what we do is instead of creating a binary contract to break this lock, we have embraced the model of shared control runtime source code which is very similar to the way the Linux kernel works. If you look at the existing Linux operating systems most of them they use the same kernel so and then this kernel is an open source so every every linux since it is using the same kernel most of the software applications built for one linux are compatible to the other linux especially if you are not using vendor specific functions and features which are built on the built on top of the core runtime so the same principle applies here now with this approach we are able to unlock the possibility to develop control applications that can now be deployed onto different devices, irrespective of the hardware, irrespective of the operating system. They can now run on multiple vendor devices and multiple vendor solutions. Again, because it's a shared source model, we are not dictating the actual deployment model, which means do you want to run it like a classical PLC? Do you want to run it as a virtual PLC, leveraging the hardware virtualization? Do you want to run it as a Docker container, leveraging the OS level abstraction and virtualization? We don't dictate anything. We say, we enable you to do what you want. And this is one big differentiation that universal automation brings to the industry. I hope I'm very clear in explaining all this.
Speaker #0
Makes sense. Makes sense. And at least it's, let's say, shed some lights on the topics because... for sure especially right now we see a lot of companies coming up with virtual psc's let's say systems or or solutions or offers and yeah it comes often to the question yeah what's then if we have that why do we need why do we need universal automation and but actually Another question to you, because, yeah, since you're here, this UAO runtime that we have, for sure, this shared source code, can I still have it run on the server? Can I still have it run, or am I kind of still obliged to use a typical traditional PLC to use this runtime?
Speaker #1
Yeah, that's, I think. A very, very basic question that comes to everyone's mind. Where can I run this? Can I run it on my personal computer? Can I run it on Raspberry Pi? Can I run it on a rack server? Can I run it on a cloud? Yes, you can run anywhere you want to. However, you need to be calculative about the resources available and what services and functions you enable in the runtime. For example, you want to use OPC UA. which kind of consumes quite amount of resources, both in terms of memory and processing power. Probably if you try to run it on a simple controller with less than gigahertz processing power and very mean RAM like 256 MB or so on and so forth, that could be a bit challenging. So if you are taking care of this balance between which services you are enabling in the runtime, and on which resource you are trying to run it, you could run it anywhere.
Speaker #0
So it makes, okay, then it gives us a complete picture on where to use and how to use the whole thing in the runtime. So I don't see any other question from the chat or from the audience. So thank you, Sarath, for sharing your knowledge. sharing about the v24.1 version. I see your contact details are just shown on the bottom inside of the screen, so people can contact you if they need to.
Speaker #1
Yeah, definitely.
Speaker #0
I thank our viewers and wish them a very good summertime because the summer season has already well started. So I'm sure some of them are... maybe watching us from the beach and uh and enjoying this uh this this session and uh we'll come back in uh september with our newest sessions and and newest information about what is happening within euros automation.org and um which what are the the vendors doing the the users doing and so on before i forget Just one reminder, we are co-organizing an event, let's say two days, as part of the IEEE ETF 2025 in Porto. And as part of these two days, we are co-organizing on the 9th of September. a workshop which will be dedicated to the 649 technology. So quite informative sessions, a lot of good presentations. So we invite everyone to join that and you can see the events and get some more information by registering on the events on the LinkedIn event of universeautomation.org. Same on the 10th, which will be the industry day. during the IEEE ETFA event, where there will be some quite interesting panels with a lot of people coming from members, coming from different sides of the member base of the association. So for sure, we will have people coming from the academia, the SI, the vendors, and so on. Very interesting sessions. And we invite you all to have a look into that and to come and join us in Porto. So that's the end of this session, Saad. Thank you again for making it.
Speaker #1
Yeah, I just want to add that I'm available at the event. I'm present on day one and first half of the day, day two. So if anyone is interested in sideline conversations, discussing something.
Speaker #0
i'm available good thank you sarat thank you everyone and see you in september see you bye bye see you bye

About UAO Goes Live: The Future of Automation

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

About UAO Goes Live: The Future of Automation

Tune in and discover how UniversalAutomation.org and its ecosystem are transforming industries, one open standard at a time.

Hosted on Ausha. See ausha.co/privacy-policy for more information.

Embed