EP4356581A1 - Procédé d'adaptation automatique de la configuration interne d'une interface de réseau externe, produit-programme informatique et dispositif - Google Patents

Procédé d'adaptation automatique de la configuration interne d'une interface de réseau externe, produit-programme informatique et dispositif

Info

Publication number
EP4356581A1
EP4356581A1 EP22734184.9A EP22734184A EP4356581A1 EP 4356581 A1 EP4356581 A1 EP 4356581A1 EP 22734184 A EP22734184 A EP 22734184A EP 4356581 A1 EP4356581 A1 EP 4356581A1
Authority
EP
European Patent Office
Prior art keywords
internal
hnifa
hnifb
network interface
lilac
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP22734184.9A
Other languages
German (de)
English (en)
Inventor
Harald Albrecht
Michael Dreher
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP4356581A1 publication Critical patent/EP4356581A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0806Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0876Aspects of the degree of configuration automation
    • H04L41/0886Fully automatic configuration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/085Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • H04L61/5014Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • the present invention relates to a method, a computer program product and a system... in an industrial automation system.
  • Industrial automation systems usually include a large number of automation devices that are networked with one another via an industrial communication network and are used in the context of manufacturing or process automation to control or regulate systems, machines or devices. Due to time-critical framework conditions in industrial automation systems, real-time communication protocols such as PROFINET, PROFIBUS, Real-Time Ethernet or Time-Sensitive Networking (TSN) and OPC UA are predominantly used for communication between automation devices. In particular, control services or applications can be automated and distributed to currently available servers or virtual machines of an industrial automation system depending on the workload.
  • TSN Time-Sensitive Networking
  • Interruptions in communication links between computing units in an industrial automation system or automation devices can lead to an unwanted or unnecessary repetition of a transmission of a service request.
  • messages that are not transmitted or not transmitted in full can, for example, prevent an industrial automation system from transitioning to or remaining in a safe operating state.
  • Problems can arise in Ethernet-based communication networks when network resources for the transmission of data streams or data frames with real-time requirements are used in competition for the transmission of data frames with large user data content without special quality of service requirements. Ultimately, this can lead to data streams or data frames with real-time requirements not being transmitted in accordance with a requested or required quality of service.
  • automation technology users can easily and modularly install, update and expand the functionalities they want for their automation in the form of so-called apps (applications).
  • apps applications
  • users benefit from the centralized and easily scalable management of many Industrial Edge devices, and on the other hand from the market, which also includes third-party providers for these apps.
  • Another important aspect is the desire of automation users to be able to easily install applications from different providers with as little additional integration effort as possible and to be able to put them into operation immediately.
  • OPC UA servers For example, encounter very different user-side configurations, which are taken into account by developers of control applications in automated configuration processes for the control applications. have to be taken.
  • the narrow range of IP addresses and TCP port numbers on the user side poses particular challenges when integrating control applications into an existing infrastructure Link network addressing information.
  • the (Industrial) Edge Management System is the central infrastructure used to manage all connected edge devices of any kind. Instead of having to apply software updates and bug fixes (e.g. security patches) to each edge device individually, everything is controlled centrally from one system that can be installed on-premises or in the cloud as required.
  • software updates and bug fixes e.g. security patches
  • the well-known software "Docker” can be used to create and manage so-called containers, which thanks to container virtualization has numerous advantages, such as low resource requirements, quick deployment and easy handling for the user
  • High-level languages are developed (not conclusively C/C++, Java, Python, Node.js, ...) and then virtualized as a so-called Docker image and then scalable and executable on all Edge devices.
  • a suitable runtime environment is required for this, which defines the available and specified requirements of the runtime system (runtime system) during the runtime of the computer programs. This is defined by the elementary components of the programming language, such as the behavior of language constructs, and other functions such as type checking, debugging, code generation and optimization.
  • the runtime environment includes other modules such as a runtime library, standard libraries, programming interfaces, runtime variables and hardware and software components via operating system functions.
  • containers provide an advantageous modularization of automation applications, including their uniform packaging, transport, installation and updating.
  • containers minimize the dependencies between applications, auxiliary libraries and the operating system, which are now difficult to manage, without the huge additional resource requirements of traditional virtual machines (VMs).
  • VMs virtual machines
  • Figure 1 illustrates such an example, with three Industrial Edge devices IE1, IE2, IE3, which are based on different hardware, with two of the devices IE1 and IE2 each having two interfaces with the (identical) identifiers XI, X2 for connection to a factory network, for example FN on the one hand, and a machine network MN on the other.
  • the identifiers of the respective interfaces XI and X2 are stored in the first Industrial Edge device IE1 with the addresses "ens30" and "ens31", in the second device IE2 with the addresses "ex8f5b" and "usb325".
  • the third device IE3 anyway has only one interface with the designation XI with the address "ep0s3".
  • Layer 2 access to the machine network, for example
  • PLAFINET Data Link Layer
  • Layer 2 / Layer 2 / Data Link Layer applications for example a directory application, the so-called "Inventory App” for automation devices.
  • Inventory information is made available for other systems and tools and the need for action to ensure device availability is determined.
  • the containers of such layer 2 applications can be suitably connected with the currently available virtual network elements of the operating systems within an industrial edge with the automation network or networks, with for example with the help of virtual bridges, virtual Ethernet cables and MACVLAN interfaces in Linux.
  • Configuration (2) is of particular interest for use in the Industrial Edge, but at the same time it should still be possible to offer the alternative configuration (1) if (customer) needs arise. However, if a customer does not use any Layer 2 applications, then none of the configurations should be activated in an Industrial Edge.
  • a bridge is a device that connects two Datalink/Layer 2 segments (e.g. Ethernet) together. Data packets, so-called frames, between the two segments are forwarded based on the layer 2 addresses (i.e. MAC addresses).
  • a bridge can be implemented either as a physical device or entirely in software.
  • Ethernet MAC addresses can be configured on a single physical interface, sub-interfaces (also referred to as slave devices) of a higher-level, physical Ethernet interface (also known as the master device), each with its own unique (randomly generated) MAC address and consequently its own IP address.
  • Applications, VMs, and containers can then bind to a specific sub-interface to directly to connect to the physical network using their own MAC and IP address.
  • the disadvantage of the constellation described above is that the internal network structure changes, particularly in the case of configuration (2) with a bridge, to the extent that the MN with the correct (IP) for integration into the external factory, FN and machine networks Change addresses, IPAdrl, IPAdr2 network interfaces to be configured. This is illustrated in FIG.
  • Two containers 160, 161, each with an associated IP stack, IPstu, and an application, cntr, are installed in the industrial edge device IE, 100.
  • the hardware interface here purple, 111b with the values IPAdr 1 "ens30" or “ens31"
  • the hardware interface here purple, 111b with the values IPAdr 1 "ens30" or “ens31”
  • the internal virtual bridge brm, 112 IP- technically has to be configured with the address IPAdr2.
  • the "multus" program https://github.com/intel/multus-cni, a so-called container network interface, CNI plugin for network configuration in container systems
  • the method according to the invention for automatically adapting the internal configuration of an external network interface on a device comprising an internal, device-related, first communication stack and service components, each of which is controlled by a sequence control system that can be loaded into a sequence control environment and executed there. component are encapsulated and have their own second communication stack, the first communication stack and the at least second communication stack being connected to the network interfaces (HNIF) via internal virtual networks, comprises the following steps:
  • topology information about internal virtual le networks (IVN) and the network interfaces (HNIF), where the topology information also contains information about the underlying network technology
  • HNIFa network interface
  • HINFb internal device-associated communication stack
  • HNIFa network interface
  • HIP internal device-associated communication stack
  • Process control components are, in particular, software containers that run isolated from other software containers or container groups within the flow control environment on a host operating system of a server facility.
  • alternative micro-virtualization concepts such as snaps can also be used for the flow control components.
  • the flow control environment may include, for example, a Docker Engine or a Snap Core running on a server facility.
  • the software containers each use a kernel of the host operating system of the server device together with other software containers running on the respective server device.
  • Storage images for the software container can be called up, for example, from a storage and provision system that can be read or written by a large number of users.
  • the implementation of the method according to the invention is proposed as a (logical) "intermediate layer" which converts the network parameters visible to the user from the user's point of view using the edge-internal virtual network topology to the respectively applicable concrete network interfaces.
  • FIG 3 shows an exemplary structure of a new Industrial Edge device IE, 100 comprising the claimed device, the so-called “Translator Manager” XAM, 131. It is assumed that this device can be designed as a so-called “virtual” device both in hardware and in software.
  • the industrial edge device IE, 100 has at least one, but typically multiple, physical network interfaces HNIFa, HNIFb, lila, 111b to the environment.
  • the physical network interfaces are connected to separate (automation) networks, such as the factory or machine networks AN 110a, 110b, via which other devices 121b connected to the machine network AN, for example for processing workpieces, can also be controlled.
  • the network interfaces HNIFa, HNIFb are connected via virtual internal networks IVNa, IVNb both to the communication IP stack, HIP, 140 of the Industrial Edge device itself and to the individual IP stacks CIP, 141 of the stored containers, CTR, which require direct Layer/Layer 2 access.
  • the user decides to what extent the layer/layer 2 containers are given access to which of the automation networks AN, 110a, 110b. This user choice decides whether and in what form the IVN 112a, 112b are specifically designed: the individual steps of the process are also shown in FIG. 4 as an example.
  • the respective network interface HNIFa, HNIFb is assigned directly to a host IP stack of the device, HIP, to optimize system performance and must be configured in terms of IP.
  • HIP host IP stack of the device
  • This possibility is not shown directly in FIG.
  • configuration (0) for further explanation.
  • Layer 2 access in the form of MACVLAN the configuration mentioned above (1), an additional MACVLAN interface must be set up for the host and configured in terms of IP due to technical constraints in the function of MACVLAN interfaces in Figure 4 the middle tree segment, 901.
  • a translator manager, XAM, 131 records the information relevant to it about the physical network interfaces HNIFa, HNIFb and the existing internal virtual networks IVNa, IVNb via a network topology detector, NTD, 130. This step is carried out for all 3 embodiments, 910
  • this can be, for example (but not exclusively) in the form of the Linux RTNETLINK API
  • the translator manager XAM, 131 determines whether a network interface HNIF(a, b) is connected directly to the host IP stack HIP; this corresponds to the configuration described above (0). In this case he notes that the network interface HNIF(a, b) must be configured directly in terms of IP technology, step 920. This corresponds to the already known method described in the introduction to the description.
  • the Translator Manager XAM searches for one (or possibly several) path(s) leading from the network interface HNIF(a, b) via virtual bridges or MACVLAN:
  • the Translator Manager XAM looks up in the topology information whether the network interface HNIF(a, b) has one or more MACVLANs associated (configuration (1)): if such a MACVLAN is connected to the host IP stack HIP, it will be in a database, 122, as IP-technically configured (i.e. IP address(es) and possibly IP routes and a DHCP client identification), and marked logically assigned to the network interface HNIF or the machine network AN, step 921 .
  • IP-technically configured i.e. IP address(es) and possibly IP routes and a DHCP client identification
  • the translator manager XAM looks up in the topology information whether the network interface HNIF(a, b) is associated with a bridge (configuration (2)): if so, the translator manager XAM checks whether the bridge is associated with the host IP Stack HIP is associated and then marks the bridge in a database, 122, as IP-technically to be configured and the network interface HNIF or the machine network AN logically assigned, step 922.
  • the Translator Manager XAM tracks the other bridges connected to the aforementioned bridge via Virtual Ethernet (VETH) (taking possible cycles into account) and repeats the check there to determine whether other bridges need to be configured in terms of IP and whether the network interface HNIF(a, b) or are logically associated with machine network AN, step 923.
  • the translator manager, XAM, 131 now controls the or the address auto-configurator, AAC, 150, in such a way that, depending on the system configuration, instead of a network interface HNIFa, HNIFb, they now have the logically assigned network interface, for example a bridge, IVNa, IP - configure technically, step 930.
  • a user 121, or the Industrial Edge Management System, IEMS, 666 enters a (static) IP configuration for the network interface HNIF (a, b), purple, 111b for the operation of the Industrial Edge device IE, 100 in the automation networks AN, 110a, 110b.
  • the Translator Manager, XAM accepts this information from the Network Address Configurator, NAC and now controls it instead of the Network Address Configurator, NAC according to the Address Auto-Configuration AAC.
  • the Translator Manager, XAM can also control the Network Address Configurator NAC and change its IP configuration in such a way that instead of the network interface HNIF, depending on the system configuration, the virtual bridges are configured with the desired static IP addresses or DHCP (the dynamic Host Configuration Protocol, RFC2131) is activated for these.
  • NAC Network Address Configurator
  • the method described above advantageously frees the industrial user from having to acquire deeper IT knowledge about the different names of network interfaces and the edge-internal virtual network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé, un produit-programme informatique ainsi qu'un système permettant l'adaptation automatique de la configuration interne d'une interface de réseau externe dans un système d'automatisation industrielle. Les utilisateurs d'appareils Industrial Edge veulent de plus en plus fréquemment utiliser également des applications correspondantes qui présentent un accès réseau de couche 2 direct. Cependant, dans la mesure où ces applications sont encapsulées dans ce que l'on appelle des « conteneurs », la configuration de ces interfaces exige des connaissances particulières qui vont au-delà des connaissances du domaine d'un homme du métier. Le procédé selon l'invention ainsi que le dispositif ont pour but d'apporter une solution au problème mentionné. Le procédé décrit dispense avantageusement l'utilisateur industriel de devoir acquérir des connaissances en TI plus approfondies sur les différents noms d'interfaces de réseau et le réseau virtuel interne de bordure (« Edge »). Il est proposé de mettre en oeuvre le procédé selon l'invention sous la forme d'une « couche intermédiaire » (logique) qui affecte les paramètres de réseau visibles pour l'utilisateur, du point de vue de celui-ci, aux interfaces de réseau concrètes respectivement applicables, sur la base de la topologie du réseau virtuel interne de bordure.
EP22734184.9A 2021-07-20 2022-05-31 Procédé d'adaptation automatique de la configuration interne d'une interface de réseau externe, produit-programme informatique et dispositif Withdrawn EP4356581A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP21186579.5A EP4123986A1 (fr) 2021-07-20 2021-07-20 Procédé d'ajustement automatique de la configuration interne d'une interface réseau externe, produit-programme informatique et dispositif
PCT/EP2022/064806 WO2023001437A1 (fr) 2021-07-20 2022-05-31 Procédé d'adaptation automatique de la configuration interne d'une interface de réseau externe, produit-programme informatique et dispositif

Publications (1)

Publication Number Publication Date
EP4356581A1 true EP4356581A1 (fr) 2024-04-24

Family

ID=76999662

Family Applications (2)

Application Number Title Priority Date Filing Date
EP21186579.5A Withdrawn EP4123986A1 (fr) 2021-07-20 2021-07-20 Procédé d'ajustement automatique de la configuration interne d'une interface réseau externe, produit-programme informatique et dispositif
EP22734184.9A Withdrawn EP4356581A1 (fr) 2021-07-20 2022-05-31 Procédé d'adaptation automatique de la configuration interne d'une interface de réseau externe, produit-programme informatique et dispositif

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP21186579.5A Withdrawn EP4123986A1 (fr) 2021-07-20 2021-07-20 Procédé d'ajustement automatique de la configuration interne d'une interface réseau externe, produit-programme informatique et dispositif

Country Status (2)

Country Link
EP (2) EP4123986A1 (fr)
WO (1) WO2023001437A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3617880A1 (fr) * 2018-08-30 2020-03-04 Juniper Networks, Inc. Réseaux multiples pour éléments d'exécution virtuels

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10728145B2 (en) * 2018-08-30 2020-07-28 Juniper Networks, Inc. Multiple virtual network interface support for virtual execution elements
EP3637684A1 (fr) * 2018-10-12 2020-04-15 Siemens Aktiengesellschaft Procédé de configuration automatique d'un système, système, programme informatique et support lisible par ordinateur
EP3771148A1 (fr) * 2019-07-25 2021-01-27 Siemens Aktiengesellschaft Procédé de configuration automatique, noeud de travail de groupe, groupe, réseau, programme informatique et support lisible par ordinateur

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3617880A1 (fr) * 2018-08-30 2020-03-04 Juniper Networks, Inc. Réseaux multiples pour éléments d'exécution virtuels

Also Published As

Publication number Publication date
EP4123986A1 (fr) 2023-01-25
WO2023001437A1 (fr) 2023-01-26

Similar Documents

Publication Publication Date Title
DE102008019040B4 (de) Verfahren und Steuergerät zur Steuerung eines Automatisierungssystems
DE10029645B4 (de) Verfahren zur Adressierung von Netzwerkkomponenten
EP3538960B1 (fr) Commande de déroulement de modules de programme
EP4154139B1 (fr) Surveillance étendue de l'intégrité d'une image de récipient
DE112012004247T5 (de) Passives Überwachen virtueller Systeme unter Verwendung einer erweiterbaren Indexierung
EP4289123B1 (fr) Configuration d'application à médiation par un conteneur
EP4413429B1 (fr) Procédé et système de fourniture des applications de commande pour un système d'automatisation industrial
DE112010005509T5 (de) Robotersystemsteuerverfahren und eine Vorrichtung davon
EP2000908A1 (fr) Procédé de transmission de données entre des instances de système d'exploitation sur un serveur et des appareils périphériques dotés de capacités de connection à un réseau
EP2456124A1 (fr) Ingénierie d'interface de capteur
EP4356581A1 (fr) Procédé d'adaptation automatique de la configuration interne d'une interface de réseau externe, produit-programme informatique et dispositif
EP3977301A1 (fr) Serveur de durée d'exécution destiné à la mise en oeuvre simultanée de plusieurs systèmes de durée d'exécution d'une installation d'automatisation
EP3399375B1 (fr) Procédé de configuration d'appareils de commande
DE102019217047A1 (de) Verfahren und Vorrichtung zum Verwalten von Zugriffen mehrerer Softwarekomponenten auf Softwareschnittstellen
DE102004039633B4 (de) Verfahren und Vorrichtung zum Austauschen fahrzeugoriginärer Informationen
WO2022238482A1 (fr) Gestion de conteneurs de temps de transport pour un système d'automatisation industriel
DE19645861A1 (de) Plattformunabhängiges Kommunikations-Verfahren für heterogenes Netzwerk
DE69623084T2 (de) Verfahren zum Auffinden eines Druckers einer Druckerart in einem Netzwerk
EP2224301A1 (fr) Arrangement d'automatisation doté d'un composant d'automatisation industriel et procédé d'administration d'un composant d'automatisation industriel
EP3165975B1 (fr) Procede et agencement de telecommande d'appareils de terrain d'au moins une installation d'automatisation
EP1536328A2 (fr) Système de traitement de données avec la gestion automatisable et procédé pour la gestion automatisée d'un système de traitement de données
WO2021037378A1 (fr) Procédé de marquage automatique, noeud de travail de groupe, groupe, réseau, programme informatique et support lisible par ordinateur
EP2455831A1 (fr) Ingénierie d'une communication de données
WO2008052901A1 (fr) Procédé pour faire fonctionner un système informatique
WO2025103904A1 (fr) Procédé et appareil d'acquisition et de gestion d'informations concernant des artefacts de dispositif et/ou des artefacts logiciels disponibles dans un système industriel hétérogène, produit programme d'ordinateur et signal

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240116

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 41/0806 20220101ALI20250528BHEP

Ipc: H04L 41/0853 20220101ALI20250528BHEP

Ipc: H04L 41/08 20220101ALI20250528BHEP

Ipc: H04L 61/5014 20220101ALI20250528BHEP

Ipc: G06F 9/50 20060101ALI20250528BHEP

Ipc: G06F 9/455 20180101ALI20250528BHEP

Ipc: H04L 41/12 20220101AFI20250528BHEP

INTG Intention to grant announced

Effective date: 20250702

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20251104