Transcription

• Speaker #0

  Hi everyone, and welcome to this Tuesday session of UAO Goes Live. I'm thrilled to have you here as we dive into an exciting topic, which is autodiscovery with IEC 649. In a world where systems need to be more flexible, more interoperable and autonomous, autodiscovery plays a critical role. Auto discovery. allowing devices and applications to find each other and communicate seamlessly. That's the role of autodiscovery, and that without manual configuration. Today, we'll explore this concept together with the technology, with the standard IEC 6.79, and why it's a game-changer for dynamic distributed automation system. So I'm happy to welcome on stage Dimitri Drozdov. Dimitri, from the company... FlexBridge and I would like Dimitri to explain us a bit more about his use case, what he has been using, what he has been developing together with the technology. Hi Dimitri

• Speaker #1

  Hi Greg and thank you a lot for inviting me today. So yeah, basically today I'm gonna talk about the use case. We've done a couple years ago with a company called Hovering Solutions and that leverages automatic discovery of IC689 based services.

• Speaker #0

  Let's start with your... tell us a bit more about FlexBridge and then let's dive into what you have to introduce us.

• Speaker #1

  Okay, yeah. Basically FlexBridge is a startup from northern Sweden. And we try to push forward highly decentralized automation systems based on IC6499 and small wireless controllers. Yeah, and I am a chief technology officer of FlexBridge, so I will talk about technology today. As I mentioned a few years ago, we worked on a project with a company called Hovering Solutions. And they use a swarm of autonomous drones for underground inspections. These drones inspect underground infrastructures like mines and tunnels and assess their safety for human entry. The drones explore the tunnels on their own, create a map and... identify potential hazards. Afterwards, they return to the operator and upload all the gathered information for further analysis. For this project, we designed the use case where CO2 sensors would be left in a tunnel to collect some gas measurements over extended periods of time when a drone flies over a sensor it would discover it connect and download the data and use that data to assess the environment gas sensors in this use case were equipped with flex bridge ice block controllers and the battery for autonomous operation one of the drones was also carrying ice block as a payload dynamic connector is the core concept of of the system handling discovery and data communication. It has two main functions, auto-discovery and data exchange. To achieve these functions, it leverages well-known application-level protocols such as MDNS and MQTT, along with related on-device software. And on this slide, you can see... diagram of this software architecture for this concept. This sequence diagram outlines discovery and data exchange process between a service provider and a service consumer. In our case, a gas sensor was a service provider and a drone is a service consumer, but I'd like to emphasize that this concept could be used to build much more complex industrial processes for example reconfigurable production lines or for hot swapping some mechatronic components in a running line. So the service provider in this process publishes its service by name or ID and creates an MQTT connection. The service provider's endpoint address and service ID are then multicast to you subscribers using a special software called Avahi. The service consumer subscribes to the service by its name or ID, discovers the provider via Avahi, and requests details to receive necessary MQTT connection information. Both the provider and the consumer establish their MQTT connections and data is exchanged via the MQTT protocol. It's important to note that an external MQTT broker is required for this to work properly. If MQTT is not suitable for some reason, other protocols could be used for data exchange as the data exchange here is separate from the discovery process So exchange protocols could be replaced to suit the specific use case. The dynamic connector is designed to be a specific tool with a defined scope. So what it does, it performs service discovery on the local network using Avahi MDNS. It handles data exchange via MQTT or possibly other protocols. and it provides an IC61499 interface, but it does not manage physical network connections, radio or wired medium access control. It does not do authentication, network connection management, or security. These functions must be handled separately. For example, in the hovering solutions use case, the network connection was managed. by the IceBlock controllers on the drone and ground units. And security should also be handled separately, for example, encrypting payload if it is necessary. This slide shows IEC 61499 interface used in the hovering solutions application. We have two key function blocks here. One is ground unit discoverable. It acts as a wrapper. for the service provider functionality on the ground unit with the sensor. And ground connector wraps the service consumer functionality for the drone, which downloads the data. In this specific use case, all data we need was stored in the ground unit data storage, and only unidirectional data flow was needed. from ground unit to the drone to upload the data. However, after the project ended, we developed an updated interface which allows bidirectional data flow. And here is a screenshot of the updated IEC 64899 interface. The blocks have been renamed for that, and the dynamic connector is is the service provider and the partner block is the service consumer. These new blocks enable bidirectional data exchange and a bit easier setup. They still use MQTT internally though protocols can be swapped if if it is needed for a specific use case. Hardware support. In theory, the system should work on any Linux based platform. However, it has specific requirements. It needs a Wahi daemon with its corresponding libraries and kernel modules. It needs an MQTT library and a special build of the ISE 64099 runtime from Universal Automation. That special build should include the service interface function blocks to communicate with a Wahi. and the necessary communication libraries, for example, for MQTT or other protocols, if you wish to use them. The system was tested on two specific hardware devices, the IceBlock from FlexBridge with developer-beta firmware, and the Schneider Electric Modicon, also with a special firmware build. When using different types of devices in the same system, it's crucial to ensure they have the same version of Avahi. to avoid service discovery issues if devices are of the same type and have the same for where the system generally works perfectly. So this is it for the presentation.

• Speaker #0

  Thank you Dimitri for driving us through this use case of how to discovery. Let's have a look if we have some questions or comments from the chat. So for those of you who are following us either on YouTube or on LinkedIn, don't hesitate to drop your comments and we can ask them to Dimitri. But let's start with one of my questions, Dimitri. In fact, what was the... the criteria to choose IEC 6439 as a foundation for this solution? Why this technology compared to other technologies which are on the market?

• Speaker #1

  I mean, in this use case, we kind of had a very simple system, but we wanted to maybe later explore possibilities to integrate it with some larger and more complex production systems. So maybe not just inspecting underground tunnels, but imagine a use case where similar kind of aerial inspection could be done over some production facilities. And then maybe it could be the drones or some other autonomous vehicles could request certain you operations in the manufacturing. And so using IEC 64899, we basically can integrate these autonomous systems with production lines and with factories if they run also IEC 64899. And basically we can have interconnections. For example, we have this drone with a small ice block flying on it, but on the ground there could be something else. Let's say Schneider PLC or PLC from some other vendor controlling some processes on the ground. And also with AC64099 and with this dynamic connector concept we can easily match them together and make them work together with very little effort.

• Speaker #0

  Okay, so here, if I kind of understood correctly what you said, this is like, okay, the first step to prepare for the future for kind of even broader use case, having other autonomous system, which can be drones or something else. uh linked to the industry or or whatever use case so it's kind of scalability and as well the possibility to have to be prepared for future evolutions on this on these use cases did I did I understand correctly yes yes exactly and um um so those those drones uh they are flying around uh in those tunnels with the the let's say the ice block on them but which um I assume you use a wireless technology to enable them to communicate. Which technology do you use for this wireless communication?

• Speaker #1

  Basically, in this use case, we used the Wi-Fi connection of the ice blocks. And I'm now trying to remember what exactly. I think for this use case we just used one ice blocks as a hotspot and then the other ice blocks would just automatically connect to it when it is in the range of connection. But also it's possible to build a Wi-Fi mesh, for example. But once again, the overall concept is not really dependent on any specific underlying networking protocol. So it could be used with different kinds of networks. Since we based the system on IceBlocks, we chose the network available on the IceBlocks. and basically what we have on the i's block is a Wi-Fi network, and on some later versions, also cellular network is possible with 5G, for example.

• Speaker #0

  5G, yeah, okay. Okay, makes sense. And talking about, let's say, the scalability of these, let's say, applications, what could be... So how scalable is the whole thing? So like, are there any limitations in terms of drones that you can fly together? Or how to make, how flexible and how scalable is this use case with the application that you have drafted?

• Speaker #1

  I mean, I cannot think of any, like... technical limit for that, but obviously hovering solutions didn't really need to send hundreds of the drones into the tunnels. But if we imagine such a use case, some really complicated infrastructure and sending many drones and maybe setting up a mesh network so they could relay the communications. between them. I would say quite a large system is possible if needed. But once again, of course, for this use case, it was just two drones because one drone carried some measurement equipment which is complex and more expensive and the second drone was sort of disposable so it could go before the main one and explore some dangerous places and kind of report back that it's safe to fly there. But yeah, this system is quite scalable and quite expandable if it is required.

• Speaker #0

  Makes sense. Makes sense. And we can even imagine that maybe the communication or the wireless network would be maybe the limit to this scalability. I don't think so.

• Speaker #1

  Probably, yeah.

• Speaker #0

  Yeah. I don't see any questions in the chat. So I think that your presentation was actually quite complete and did answer a lot of the questions. Do you have any words that you would like to share with our audience before we close this session?

• Speaker #1

  I didn't prepare any final words.

• Speaker #0

  About FlexBridge, if people want to reach out. like to fresh bridge to how how how could fresh which help them in their let's say development or applications in general i mean you you can check our website and of course email me with there was the email that is

• Speaker #1

  shared somewhere in this presentation but yeah basically we can support some interesting projects for highly decentralized systems where wireless communication is needed. And also we can help, for example, with advanced software architectures if you want to use AC64099 specifically, because this is kind of our area of expertise. So, yeah.

• Speaker #0

  Great, great. Thank you. Thank you so much, Dimitri, for sharing with us about FlexBridge, about this use case. on the auto discovery because it's really helping us it's a very innovative case and it's really helping us to to see how we could use the ic64099 in uh in uh in real real-life, let's say, industrial use cases. And thank you as well to all of you for joining us for this session of UAO Goes Live. I hope we will see you later in the next session. So today we have learned about how discovery can simplify integration, enable dynamic connectivity, and support advanced applications such as autonomous systems or autonomous inspection in challenging environments. That was a great example of how open automation and how IC619 can drive the future of industrial automation. So, Donny States, I'd like to thank you again, Dimitri, for making it. I'd like to thank our viewer for listening to us and for watching us and invite all of you to visit our website, universalautomation.org, if you want to see more resources to connect with the UAO community. We have shared already, and maybe we share again the details of Dimitri on the screen, so you can reach out to him directly if you need to have some contacts or to deep dive deeper on this use case. Don't miss out our next UL Go Live sessions. We will announce them shortly, most probably on LinkedIn. So you can get to know a bit more about what we are doing within the association, the use cases, the members. And let's thanks again. Let's keep pushing the boundary of open automation. And I wish you a very great day. See you. Bye bye.