 Hello and welcome to our today's webinar. My name is Dirk Fischer and with me is Louis Chaucin, a colleague from our partner ST Microelectronics. We want to present and explain a solution to combine real-time Ethernet like Profinet or Ethernet IP with OPC way. Let me provide some organizational notes first. This session will be recorded. We have the possibility to forward it to colleagues or watch it again later. We also provide the slides of this presentation after the meeting. You will receive an email with the material. We prepared a short survey. We would like to answer you some questions about this webinar and the OPC way in general. It just takes one or two minutes and we really appreciate if you could provide some feedback. We would like to encourage you to ask questions. You have the possibility to enter questions in the Teams tool. We will reserve some time at the end to answer your questions. The webinar is split into four parts. First, we will talk about the motivation. Why do you need this solution? What are the benefits and use cases? The solution consists on hardware and software, and both aspects will be covered in this webinar. While the focus is more on the software side and the functionality within the software. The last section is about the configuration. How to model your device, how to create information models, and bring it into your device. Please let me introduce our company first before we start. Hilscher is a German company located close to Frankfurt. We have about 350 employees in our headquarters, a lot of development engineers. It's owner-driven, so Hans-Jürgen Hilscher founded this company in 1986. Just recently, he transferred the responsibility to his son, Sebastian. Our core competence is industrial automation. We offer a wide range of solutions for industrial communication. Standard products like PC cards or gateways, also SOC, so chips and modules for design in into your devices to integrate it, but also the software which is required for this. So a wide range of different protocol stacks. The traditional field buzzers, we started to develop these kind of protocols in the 1980s and 90s, and later we switched on to the real-time Ethernet based protocols. Now the next generation will be TSN and Gigabit-based solutions. We also provide custom development and also production. So we have our own production in Hattersheim, and we can do customized production as well. Eight subsidiaries are located in the most important regions in the world, in the US and in Asia, and we have, beside the headquarters, we have development sites in Bulgaria, big software development site, and also in Berlin, where we develop the SOCs. And a network of distributors all over the world, where you can purchase our standard products. The partnership with ST has a quite long history already. We have many successful common projects in the field outside. Many products are based on STM32 microcontroller plus NETIX, because both products fit perfectly together. We have development boards, evaluation boards developed together. There is STM32 cube expansion and software examples available. And we have joint exhibitions, so it's a quite good basement. I would like to hand over to Louis to explain a little bit about ST and its offering. Yes, thank you, Dirk. So first a few words about ST Microelectronics Company. So ST is one of the largest semiconductor companies with 11 manufacturing sites and 80 sales office all over the world. The four hand markets addressed by ST are automotive, industrial, personal electronics, and communication equipment, computers, peripherals. ST is delivering a wide range of products, including analog, power conversion, ICs, processors, ASICs, MEMS, and imaging sensors, discreet and power. ST is supporting evolution required by the industry 4.0, like better production efficiency, safer working environment, predictive maintenance, less waste and less energy used. So today we will focus more on our microcontrollers and microprocessor family. So this is STM32. So STM32 is our 32-bit general-purpose microcontroller and microprocessor family. It is well suited for industrial applications and it is used by many OEMs. Here are some few examples about the success of STM32 in the industrial market. So you can benefit from the 10-year longevity commitment. So this longevity commitment is renewed every year. Many devices are proposed with an extended temperature range up to 125 degrees. Functional safety is also one of focus. So you have features to support functional safety like flash and RAM error code corrections. Watchdog PWM protections. We provide safety manuals and self-test libraries certified by Tuva in London. All this is available free of charge and it will speed up your safety certification. So you can check STM32 functional safety web page for more information. A security framework has been defined also which is called STM32 trust to help you protect your assets and reach the security assurance level. You can check again the STM32 trust web page for more information. A consistent and comprehensive software solution is offered for STM32. So first you have the STM32 cube for all STM32 devices which is complemented by the open STLinux distribution to develop on STM32 MP1 microprocessor products. OK, thank you, Louis. Then let's start with the actual topic for today. And I would like to explain our motivation to offer this solution. I would like to start with a comparison. You see two pictures here, two boats, both of the same class of transport device, but with different properties. While the speedboat is fast, the cargo ship on the other hand is slow compared to this. So we have a clear advantage for the speedboat. It's also more quicker in reaction. You can turn the direction in a quicker way. The cargo ship has a bigger latency until it reacts. You need less resources to build a speedboat. You need a lot of metal and a lot of resources to build a cargo ship. Many advantages for the speedboat, but on the other hand, the cargo ship has a much bigger load capacity compared to the small boat. And it has a longer range. You can travel greater distances with a cargo ship. So both ships complement each other. If you have both in your fleet, you have more possibilities. You can cover more use cases. And this comparison can be transferred now to the protocols we are talking about today. Ethernet IP proofing net can be regarded as a speedboat while OPC way is a cargo ship. OPC way in this context means client server because in the solution we present today, we have implemented the OPC way server. OPC way might be extended by pub sub publisher subscriber mechanism. This is an extension to OPC way. Asia also covers this in the future. But for today for the solution we present here, it's a client server solution. So this is a rough comparison. Let's go a little bit more into the details. More on a technical base comparison on proofing net Ethernet IP with OPC way. I don't want to go through each of this rows here in this table, but want to highlight just two properties. First is the data structure or the data itself transported over these protocols. While the real time Ethernet protocols have quite limited amount of data and flat data structured, but not enriched with semantics or more structural elements. While on the other side, OPC way provides much more flexibility. We have an object oriented approach and semantics are included. It's much powerful, much more powerful compared to the simple data structure of the proofing net and Ethernet IP. So this is the biggest advantage of OPC way. If we compare the timing behavior, you see we have advantages on the other side. Yeah, we have a deterministic behavior on proofing net and Ethernet IP. We have guaranteed performance and short cycle times. While OPC way has a best effort strategy. You never know if data arrives in time. You don't know how long it might take to transfer the data. So it's not as reliable and much slower. Yeah, factor 100 approximately to transfer data and we have bigger jitter. So these are the two different properties, but they fit together. They complement each other. For that reason, the two protocols are used for different roles inside systems. And in the factory automation or in automation in general, you see this Pyramide, the classical automation Pyramide. The real time Ethernet is used in a horizontal communication on field level here, in the green colored levels to exchange data between devices, between the end nodes of your system and between PLC and end nodes. While OPC ways is used in a vertical manner to exchange information. So enriched information, but not in real time into the IT systems of the manufacturing execution system for controlling monitoring diagnostics. With a new solution, Hilscher offers now these borders disappear or at least they blur a little bit. So the IT and the OT world converge. It's possible now with this solution to transport information from the devices on the field level into the higher levels. Now, theoretically even up into the cloud, typically you have gateways in between for security reasons. But anyway, it's possible to access the nodes on field level by devices, HMI or mass systems directly down to the lowest level. And this enables new possibilities, new applications. This functionality is available through the same infrastructure. Now we use the same cables, same network to transfer both real time Ethernet and OPC way. Typically our hardware devices offer two ports as indicated here in this picture. So we can realize line topologies, daisy chaining and through this cables, you can transfer OPC way to an HMI to edge gateway, while proofing it is transported to the PLC on the same cable. How is this possible? These real time Ethernet protocols are based on standard TCP IP. They have additional mechanisms to guarantee the timing behavior to add real time capability. But beside this, there's always some bandwidth left for standard TCP IP and OPC way is based on standard TCP IP. So we can use the blue portion here of the bandwidth to transport OPC way data. RTE has higher priority. So the bandwidth for OPC way might be limited in order to guarantee the deterministic behavior of the RTE. Either cat might be a question here. What's about either cat because either cat is not standard TCP IP. There is vice versa. So either cat provides tunnel either net. It's called either either net over either cat. And there we have standard TCP IP inside either cat. And there it's also possible to transport OPC way. But today we don't offer such a solution. Technically, it's possible in the past. We did similar implementations already. But for today's solution, we don't offer it yet because the performance is limited because of this tunneling. You don't have a good performance. It's quite limited bandwidth for OPC way. There might be more services. Beside OPC way, you might want to use a web server and then you need additional bandwidth. And then it gets quite slow for either cat. So what are the user benefits? A device maker might ask you, why do I need it? I have my profile net or even at IP interface. That's OK. That's sufficient. But we think you have the chance to enhance your product, to add value and to differentiate your product with new features from the competition and also from PLC makers. Because now you have the possibility to provide data to the higher layers of a system by yourself, by your device. I have heard from many device makers, they have a lot of data inside their devices. But it's unused. They don't have possibilities to transport it to the outside world, except the data which is required for the control for the PLC. And now you have a channel to utilize this data. Just mine it. It's available anyway, already. And OPC way improves interoperability. You can talk with devices from other vendors from other makers because OPC way is a manufacturer independent standard. And by supporting such an interface, you can add new functionality like a set management, condition monitoring, diagnostics and maintenance. And even device configuration over OPC way is possible. So there are many new possibilities. Yeah, why OPC way for this purpose, for this additional channel besides the real time is in it. OPC way is platform and manufacturer independent. So it's well established already in the IT world. So there's a big amount of infrastructure or tools and everything available for OPC way. So it's quite easy to integrate this functionality into IT networks. In Europe, particularly in Germany, we have an initiative industry 4.0. And there was a reference architecture model specified within this industry 4.0 project. And OPC way is the only communication standard recommended in this reference architecture model. So it's really regarded as a very important and very meaningful for these applications. We have powerful information modeling capabilities and I will present the meaning of this later. What does it mean? Yeah, that's an important feature of OPC way. So VDMA is an important machine builder association in Europe with more than 3,000 members. And this organization just recently published a study about OPC way usage in machines. And 90% of the companies asked, did already or plan to implement OPC way interface into their machines and systems. About 500 companies were asked and this is really a big amount or a big number of companies regard OPC way as important. So that's about the motivation why it makes sense to implement OPC way. You need hardware to do this and Hilscher offers interfaces for that. So if you want to add this functionality to a sensor or to your drive to IO modules, you need an interface and we provide a different solutions for that purpose. PC cards, modules and even chips SOCs. So it's kind of scalable depending on your integration level. You can choose the right solution for your application. But the usage is always the same and it uses always the same software. So from programmer's perspective, it's the same solution. Just different hardware. You have different hardware interfaces. The PC card comes with a PCI express interface while the module and companionship features SPI interface to connect your host controller to it. And the chip even provides a parallel interface. So the system looks like this. We have the netics based hardware, the module, a PC card or the chip itself. This typically provides two ports and then you have the host interface to the host controller. So we have a clear separation between the communication part and the application part. The responsibility is also well defined and separated from each other. Yeah, if you look into the structure of the firmware running on the communication side, you see all parts are provided by Heelshow. The user don't have to deal with this functionality inside. You can regard it as a black box. Just the interface is important for you. The protocol stack is the most important part of this firmware. And then you have the interfaces to the application. So maybe it's more interesting for users, for you to look on the application side. So on any kind of STM32 microcontroller, you run your own user application, the blue-colored layer here. And Heelshow provides a driver for this purpose, so-called civics API, and the application use functions of the driver to communicate with the communication side. We will see some more specific examples later. What does it mean? This interface, how the set of functions look like. Operating system is not, it's optional. It's not mandatory. It's not really required. You don't need it. So even quite small microcontrollers are capable to communicate with the communication side and to use OPC way. You don't need much resources here on the host side. Even small microcontrollers do it. Not going into the details, just a few notes regarding the NETX chip itself and the most important functionality on this chip or module. Our important functionality is called XC. So this is a technology. It's a very flexible communication module. The XC modules, we have two of them on our chips to implement two channels. And they are flexible, reprogrammable by software. They can act as an EtherCAD interface as well as a Cercos, ProfiBus, ProfiNet, EtherNet, IP, whatever. And we have the files on chip. So many functions are already on chip. That this is also true for memory. So we have flash, which holds the firmware itself. And we have power supply and clock generation functions on chip. That means we have only a very small number of external components required for this solution. The protocol firmware is executed on an ARM Cortex-M4 CPU running at 100 MHz. And this block shows the host interface. This is a physical interface to the external microcontroller. And this can be a parallel interface called DPM or Serial Report Memory Interface, SPM. Optionally, there's also the possibility to use a second CPU on chip, another Cortex-M4, and a few peripherals which might be used for an application instead of an external controller. But there you are fixed with a set of functions and limited in resources. Development boards, if you want to start a development, you get different possibilities. ST offers fully integrated development board, the microcontroller and NETX90 on one chip. There's also motor control functionality on this board. So it's more related to motor control applications. And there are two variants with a serial interface and also parallel interface. A more generic approach is this. You use any kind of Nucleo or other development board for the microcontroller or even your own application, your own hardware, and connect this with an evolution board for NETX90. And Net Shield is another solution. So there's a small expansion board which can be connected directly to Nucleo. We have such module available already for older NETX derivatives. For NETX90, it is under development and will become available later this year. So you see in this picture, we have NETX90 connected to a microcontroller and that's a big advantage and provides big flexibility because you can scale this microcontroller. And I would like to hand over to Louis again because he can tell you about the portfolio of microcontrollers which can be used here as a host controller, depending on your requirements for the application. So Louis? Yeah, thank you, dear. So indeed, we propose a wide range of microcontrollers and microprocessors. Many devices with high performance, real-time capabilities, digital signal processing, low power operation, connectivity. So among the latest introduced STM32 series, okay, I can mention the STM32 H7 and STM32 MP1, if you are looking for performance. You have the, in the mainstream, you have the STM32 G4 for motor control or digital power, STM32 G0, which is a lower-cost microcontroller with Cortex-M0, STM32 U5 in the ultra-low power family. If you are looking for more security, for instance. And we have also wireless microcontrollers with STM32 WL and WB to implement Bluetooth, low-energy, ZigBee, Lora, or wireless MBUS. All this portfolio is complemented with a comprehensive ecosystem. So on the right side, you can see all the content with software and tools. Okay, if you are going to the STM32 web page, you will have all the links. And on the bottom side, you can see all the STM32 solutions like motor control or safety and artificial neural networks. So you can check all these solutions on the ST web page. So in terms of ecosystem, so the ecosystem is continuously growing. So it is based on STM32 Qube, which is a software solution for STM32, including software tools, as well as embedded software libraries. So the software tool can address the complete project development cycles, starting with a configuration with STM32 Qube MX, then you have STM32 Qube ID to compile and debug, and then you have a STM32 Qube programmer and Qube monitor. So in terms of embedded software, you have many software bricks available in this ecosystem, which is also complemented with some STM32 Qube expansion provided by ST or by some partners. So for instance, so we have seen that HR is providing a STM32 Qube expansion in order to connect the Netflix device to the STM32. You have also many hardware boards available like Nucleo or Discovery kits to allow a fast evaluation or prototyping also. And last but not least, you can rely also on many online resources and community with the trainings, massive open online courses, videos, and a network of partners to help you at any stage of your STM32 project, starting from evaluation, prototyping until the design and the production. So HR has enriched this ecosystem with a Nucleo expansion board as well as a STM32 Qube expansion to connect all these STM32 to the Netflix device to connect the STM32 application to a real-time industrial internet protocols and OPC UA. Okay, thank you very much, Louis. Now we can start with the software side of this solution. Before we go into the details, I want to introduce a term, an OPC UA-related term, information model. That's an important part of OPC UA because it represents typically a device. So you might have any kind of device connected to a network. And you want to provide data of this device to the outside world. And an information model gives you the opportunity to structure this data and to bring it into a relationship to each other. So an information model consists on nodes of nodes of different classes. So we have nodes of the class object, which is shown here as a box. And we have other nodes called variable nodes, showed here as a kind of bubble. And all these different nodes are interconnected. They have relationships. You see, we have sub nodes here of the sensor type. And these variable nodes, they actually contain the data. And in this case, and in this way, you can model your device and represent it to external clients. So in this context, we have seen this picture before, an HMI or configuration PC and diagnostic PC and edge gateway can access data of the device through this model. They just read and write variables shown here in these nodes. And it's even possible to provide the whole model to the client. So it's not necessary to load a kind of device description file into these clients to understand the structure. The server itself provided and the client can scan it and go through all the nodes and then check the content. So our task is now to implement such a model into the device, into your own device. This is a high level block diagram of a device. We have the separation. You remember the application side based on the microcontroller and the communication side based on the NETX chip. So we have two parts of the firmware. The yellow box represents the software, the firmware. And this model is somehow inside the software. So step by step, I want to go into more details of this implementation. So next level would be to check what's the interface between both firmware parts. We have the dual port memory in between. Now, physically we have the SPI or parallel interface and through this physical interface, you access memory, read and write memory from both sides to exchange data. Physically the dual port memory is located inside the NETX. So the no resources on the host controller are required for this purpose. So on the application side, we have two kinds of data. We have seen this before. We have distinguished the two colors, green for real-time data and blue for the slower, best efforts data, additional data, OPC way based. So, and we have this separation also in our application, even in the code, we can clearly separate these two parts. Real-time IO data, the process data image as a kind of image, flat in the memory. On the other hand, the OPC way data is structured in as objects. So we have a more abstract fuel. You can use C structures to hold abstract data objects. So these data objects not directly related to the information model yet. So this is a Hilscher specification, is these kind of abstract data objects. We will see how this maps to the information model later. But here the message is in your application, you just maintain data inside of these objects. Very simple. Now the functionality in our firmware, in our solution. In the middle, you see them three main important functional components, function blocks. We have a real-time Ethernet protocol stack here, Profinet or others, Ethernet IP. And on the other side, we have the OPC way server, the OPC way stack. There is an additional functionality, a web server in between. All these three functionalities are based on a common TCP IP stack, because all three components are based on TCP IP, except the real-time Ethernet part might bypass the TCP IP stack for some purposes and directly communicate with the underlying hardware abstraction in order to achieve the real-time behavior. So there are some functions not related to standard TCP IP. And then we need an interface towards the application. So we have a protocol interface. We have the so-called Ethernet interface, which provides sockets or raw Ethernet channel here. And we have the so-called net proxy. This is an interface component and abstraction layer between OPC way and the application. So these lines to upwards in the direction of the application go through the dual port memory. Yeah, so that's the communication path from the application part handling the object through the DPM to the net proxy. And yeah, I have a guess where is this information model handled and located inside this firmware? Yes, of course, very clear inside the OPC way stack. So this is a function, functional block handle the actual information model. The application does not deal directly with the information model because we have this abstraction layer in between. On the application side, it's much simpler. You just read and write your objects, data objects and the mapping from any kind of object to the actual variable nodes happens inside net proxy and the OPC way stack. So it's quite easy to implement these models and handle it from the application side. You don't have to deal with the details of such models. OPC way server in general cover a wide range of features. So these OPC servers have a lot of different functionalities and it's scalable because they are platform independent. They can run on small embedded devices like in our case, but also on big servers with much more CPU performance. Therefore the OPC way specification defines four different profiles shown here in the middle. The nano embedded server profile, micro embedded server profile, embedded and standard server profile. And with our solution, we cover the two lower profile variants, the nano and the micro embedded server profile. So these profiles define a set of functions provided by the solution. And in addition, they are so-called facets. These are optional additional features and function blocks. So we add some facets, optional facets in our solution, but we won't go into the details here at this point in the presentation. The server implementation is based on an open source project. So we use the open 624541. And this is an open source project published under the Mozilla license. We actively contribute to this project. We develop this stack and we provide our development back to the project and contribute it. Our solution passes the compliant test tool tests. This test tool is provided by the OPC way foundation. And we also participated in plug-fests. Just recently, there was a virtual one in some weeks ago where we test our solution together with other suppliers, with some other companies. Related to the software, one last slide about the interface towards the application. I mentioned this driver already. So for the host side, the microcontroller side, Hilscher provides a kind of driver, CITIX API. And on top of this driver, we provide an additional software layer, which is called host API. And this host API provides high-level functions to access the objects, as well as the cyclic IO data, the real-time data. So here you see some examples, read object element, write object element, or read input, write output for the cyclic process data. It's quite easy to use these functions to modify content of these objects. There are also indications and callbacks. You can register callbacks whenever a node insights information model is changed from outside. Let me go back here. If an external client write one of these variable nodes, for example, the mode, the OPC way and that proxy inform the application. So they send an indication towards the application and there a callback is called whenever such a node was modified outside. Yeah, this is to get a basic understanding how this API looks like. Now, the question, how can we define such a model? Yeah, we have assumed we have this model somehow inside the server, but this is flexible. It depends on the device. The user wants to modify it or want to create it and how can we do it? For this purpose, Hilscher provides a tool. It's communication studio and in the next slides I want to explain the configuration flow consists of some steps and just a simple overview of how to configure your own information models. In the first step, you have to think about it how to model your device on paper or in any form just to get an idea how you would like to structure your device. And then you can start the actual definition of the model inside the tool. There are three steps. The first step is not so important. We will not cover it here in this presentation. It's just basic configuration of the server. For example, which TCP-IP port is used for the OPC-A server and these kinds of stuff. It's not related to the model. And the second step is the most important one. Here you define this model shown in this picture. Typically, as a user, you don't define such a model from scratch. Typically, you use so-called companion specifications. So they can be regarded as a kind of template and for all kinds of different applications and device classes, these companion specifications are available now. So many user organizations define companion specs for their particular use case like scales, drives, send all kinds of different sensor types. There are particular companion specifications and you can import them. The companion specs are typically provided as an XML file and you can import this XML file into our tool and then use it as a starting point for your own model. In addition to the companion specs, there are some basic namespaces or you can regard this as a definition of types, standard types, which are built in already in our tool. You don't have to import. They are already there because they are very fundamental. And this is important, the DI device integration profile, which is a very generic device representation and you can add more information models on top of such a DI, typically. After you have modeled the device, so you have specified this information model, then you have to map it to NetProxy objects. So this is hillshare specific as a third step and then you can export the configuration and download it into your application. To get rough overview how this looks like, I will show two screenshots, one of this step and another one of this step. So this is a tool communication studio. On the left-hand side, you see the project explorer and the different steps of the configuration I've shown here. Second, number two is the most important one because information modeling is a fundamental of this. Here you can see the imported namespaces or the available namespaces, the basic ones, the UA and the DI namespace. And in this example, we imported a companion spec for scales. So we have this namespace for scales and you can use the type definitions here in your own model. And coming back to our simple example, this device with sensors and actuator, here you can see the sensor node. Here you can see the name, sensor name, it's of class object. And this object has subcomponents shown here, three subcomponents. One is called mode, state and the value. These subcomponents have different data types shown here. For example, the value node has a data type float. In this way, you create nodes and you reference them to each other. This is information building and then last step, map it to net proxy objects. Here we can create new objects. You are very flexible here. It's not necessary to directly reflect the information model object here. You can put all nodes of an information model into one net proxy object if you want or you can have completely different structures. But first you have to define it and then you have to link it or map it to the actual information model nodes. This is shown here in this column. We have three elements of this C structure of the net proxy object and we map each of this model, each of this element of the object to a particular node of the information model. And the last step is to export this configuration. You get a binary file which is imported into the flash of the netics device and the OPC way server will load this configuration and for the application on the microcontroller side you get a header file with a net proxy object definitions. Yeah, that's the way how you define information models and download it into the device. As a summary, this solution contain all parts required for the application. So you get hardware, communication hardware and you can choose between different levels of integration starting from chip level, module, even PC card can be used with the same software. Firmware is available and I will just show another slide after this one where it shows that this solution we've discussed here is just a part of our complete offering. So you have the possibility to scale down or up the set of functions in a firmware. And the tool of course is part of this solution to define your models and configure the OPC way stack. The big lineup or portfolio of microcontrollers STM32 provides much flexibility to choose the right one just fitting one for your application depending on your requirements. For motor control you need different controller than for simple sensors. This is for your reference, you will receive these slides and you can check the links where you can find more information. That's what I mentioned this firmware we've discussed here in this webinar is a high level of set of features. But you get also variants of firmware with less features. So the simplest one is basic field pass without OPC way without web server, it's just standard field pass. We have real-time Ethernet protocols firmware and with extended web server and now the biggest features that even with OPC way. Some of these features that's require more resources. So for the OPC way solution we need external memory while the simple firmware does not require additional memory we come the internal resources of netx90 are sufficient. Now, just know what you see we have many different protocols covered by the same hardware, one netx90 based hardware and you can operate all these different kinds of firmware and OPC way solution is just one of them. Yeah, that's from my side. We have some time left for questions and let's check if you have entered some questions already. Okay, there's one. What's your suggestion for adapting a proprietary JSON based API for OPC way could that app core in netx90 be used for that? No, I don't think so. So I think, so the API for on the communication side is fixed, maybe it's possible to add abstraction layer into your application. So your application may use your own proprietary JSON based API and you have to map this into net proxy objects. It could be done on the application side in the microcontroller, but on the communication firmware itself we don't have this kind of flexibility. Does the firmware of profanet and OPC way fits into the internal flash of netx90? Yes and no. Anyway, we need external memory. We need external SD RAM and external flash for the OPC way firmware. So the biggest portion of the firmware fits into the internal memory, but anyway, we need external memory for a file system and we store our configuration, the OPC way configuration in this external memory. So the internal memory is not sufficient for the solution. Okay, there's another question. Does Hilscher have a product that contains the netx and STM32 on one board? No, we don't have a standard product combining these two components as a product. You have seen the evaluation board or the development board is available where we have both components on one board, but this is not a standard product. I think it also doesn't really make sense because STM32 provides a big flexibility in host controllers and which one should we choose for such a solution. So I think this is necessary to develop your own custom hardware for this purpose. Another question. Does ARM-Kyle operating system have any support for this? No, there is no direct support or direct implementation of this Kyle OS. Of course, you can use ARM-Kyle OS on the application side and integrate our driver on top, but there is not a real direct integration. Next question. For the user application on the netx 90, how much resources memory is expected to be available for using OPC UA at the same time as another protocol like Profinet, especially when considering the large OPC web packet size? Can you also clarify the issues you may run into when running OPC UA and a web server at the same time? Thanks for the user application on the netx 90. You mean the integrated solution? I mean the protocol functionality, both Profinet as well as OPC UA, completely runs on the communication side. On the application side, there is no functionality directly related to OPC UA or Profinet. You just have to provide the data content. Therefore, there is not much resources required on the application side, no matter if it's the internal one or external controller. It depends a little bit on your information models, how large they might be, but beside this, there are not high requirements related to the resources on the application side. Another question, there are many software layers in netx 90 and host CPU. Each layer needs processing time. Do you have a performance measurement with SPI? Yes, I don't have a slide here, but of course, you have to consider the possible real-time, real-time, even at cycle times. And in our experience, the SPI interface was not really a bottleneck. So you can achieve one millisecond cycle time, which is the minimum for Profinet, RT anyway, or also even at IP one millisecond. And normal IO process data sizes like let's say 100 or 200 bytes is possible to achieve because the SPI frequency of netx 90 interface can be very high. So you can really have maximum SPI frequencies and yeah, this kind of combination, cycle time one millisecond and 200 byte IO data are possible beside a cyclic data. But if you have more requirements, so even shorter or sub millisecond cycle times then it is necessary to have a closer look and you might consider to use a parallel interface. If this is a critical question for you, we can also have a communication after this webinar you received our contact details. And anyway, if there are more questions afterwards, don't hesitate to contact us. We are ready to provide answers. So are there more questions? No, that seems not the case. Then I want to say thank you for your time for participating in this webinar. As we announced earlier, we will provide the slides in an email. And again, I would appreciate if you take one or two minutes to answer some questions about this webinar, provide feedback if it's necessary to improve. Thank you very much. Then we close this session. See you next time. And also thank you, Luik, for supporting this session here. You're welcome, thanks to you. Bye-bye. Bye.