EP4074011B1 - Plateforme de gestions de micro services concernant la gestion d'une batterie - Google Patents

Plateforme de gestions de micro services concernant la gestion d'une batterie Download PDF

Info

Publication number
EP4074011B1
EP4074011B1 EP20845188.0A EP20845188A EP4074011B1 EP 4074011 B1 EP4074011 B1 EP 4074011B1 EP 20845188 A EP20845188 A EP 20845188A EP 4074011 B1 EP4074011 B1 EP 4074011B1
Authority
EP
European Patent Office
Prior art keywords
service
micro
battery
function
services
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.)
Active
Application number
EP20845188.0A
Other languages
German (de)
English (en)
Other versions
EP4074011A1 (fr
Inventor
Stéphane ALAIMO
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.)
SAFT Societe des Accumulateurs Fixes et de Traction SA
Original Assignee
SAFT Societe des Accumulateurs Fixes et de Traction SA
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 SAFT Societe des Accumulateurs Fixes et de Traction SA filed Critical SAFT Societe des Accumulateurs Fixes et de Traction SA
Publication of EP4074011A1 publication Critical patent/EP4074011A1/fr
Application granted granted Critical
Publication of EP4074011B1 publication Critical patent/EP4074011B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Program-control systems
    • G05B19/02—Program-control systems electric
    • G05B19/18—Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of program data in numerical form
    • G05B19/4155—Numerical control [NC], i.e. automatically operating machines, in particular machine tools, e.g. in a manufacturing environment, so as to execute positioning, movement or co-ordinated operations by means of program data in numerical form characterised by program execution, i.e. part program or machine function execution, e.g. selection of a program
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/425—Structural combination with electronic components, e.g. electronic circuits integrated to the outside of the casing
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/48—Accumulators combined with arrangements for measuring, testing or indicating the condition of cells, e.g. the level or density of the electrolyte
    • H01M10/482—Accumulators combined with arrangements for measuring, testing or indicating the condition of cells, e.g. the level or density of the electrolyte for several batteries or cells simultaneously or sequentially
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/31—From computer integrated manufacturing till monitoring
    • G05B2219/31196—SOAP, describes available services and how to call them remotely
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/31—From computer integrated manufacturing till monitoring
    • G05B2219/31449—Monitor workflow, to optimize business, industrial processes
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/425—Structural combination with electronic components, e.g. electronic circuits integrated to the outside of the casing
    • H01M2010/4271—Battery management systems including electronic circuits, e.g. control of current or voltage to keep battery in healthy state, cell balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02E—REDUCTION OF GREENHOUSE GAS [GHG] EMISSIONS, RELATED TO ENERGY GENERATION, TRANSMISSION OR DISTRIBUTION
    • Y02E60/00—Enabling technologies; Technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02E60/10—Energy storage using batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them
    • Y04S40/18—Network protocols supporting networked applications, e.g. including control of end-device applications over a network

Definitions

  • the present invention relates to the technical field of service platforms using micro-services for an industrial control system.
  • management functions of a complex industrial system generally relies on an IT infrastructure. These functions include operational monitoring, programming and remote diagnosis of machines and equipment, production monitoring and diagnosis, as well as man/machine interfaces allowing and facilitating interactions of human operators.
  • an industrial system may be a Battery Management System (BMS), which is an electronic control system that has multiple functions in an energy storage system based on one or batteries. These functions include, but are not limited to, monitoring the state of the battery (state of charge, state of health, temperature, electrical current passing through it, etc.), controlling the power connections of the battery with a charge, charge control, monitoring of the operational safety of the battery and functions ensuring its safety and security.
  • BMS Battery Management System
  • an IT infrastructure for managing an industrial system includes a management unit which executes the services and which is connected to one or more networks on which the machines and equipment of the system are also connected.
  • the machines and equipment transmit information about them to the management unit, and the computing unit executes business functions based on the information received, and sends commands to the machines and equipment.
  • FIG. 7 illustrates a [example of an industrial system in which equipment (A, B), sensors (1, 2, 3), a host system, a user are connected to an industrial process management body.
  • the latter receives, for example, data, measurements, configuration commands, configurations, and transmits, for example, commands, data, displays, etc.
  • the flows are centralized on the management body.
  • the service platform further includes a unified communications system for exchange of data and messages.
  • Such a platform improves the level of availability of a management platform, while offering a high level of availability without having to resort to 1 redundancy and high scalability. Further improvements, including preferred embodiments, which correspond to the dependent claims, will be discussed below.
  • the service platform can implement a management system for a battery and its auxiliary equipment; we are then talking about a service platform, implemented by one or more computers, for managing a battery and its auxiliary equipment.
  • the service platform according to the invention to implement a system for managing a battery and its auxiliary equipment, the battery being formed of one or more branches connected in parallel, each branch comprising one or several modules connected in series, each module comprising one or more electrochemical elements.
  • This use may further include at least one auxiliary equipment which is selected from a fire extinguishing system; an air conditioning system; a physical access monitoring system; an electrical power measurement system.
  • the present invention relates to a service platform implemented by one or more computers.
  • the service platform offers an IT infrastructure for managing an industrial system.
  • the service platform manages one or more services in the form of micro-services.
  • a platform service is in the form of a micro-service. If the platform manages several services, there can be as many micro-services as there are services.
  • Microservices can be run on one or more computers, i.e. a computing unit can run one or more microservices.
  • micro-service refers to a software architecture that structures an application as a set of services, each performing a simple unit function and loosely coupled together. Microservices should be as independent of each other as possible, and they should communicate independently with each other using programming language-independent APIs.
  • Each microservice has a standardized generic structure.
  • a standardized generic structure is described using a micro-service template.
  • the typical microservice model standardizes the construction and operation of the microservice. If the platform includes multiple microservices, each microservice will conform to the standardized generic structure.
  • the standardized generic structure which applies to each micro-service includes at least the following two sub-services.
  • the first subservice is a subservice implementing a business function.
  • the business function defines a specific role which will be performed by the micro-service as part of its use in the industrial system managed by the management platform.
  • the business function can also be called business functionality.
  • the business function or business functionality may include, for example, a business application, a business process, or even a business service.
  • the second sub-service is a messaging sub-service which allows the micro-service to communicate with an element external to itself, for example another micro-service.
  • the messaging sub-service defines an APl (acronym for Application Programming Interface) allowing the micro-service to access messaging common to the other micro-services and therefore to communicate with them.
  • the service platform includes a data and message exchange system which is a data and message transmission device shared between several components of the platform, for example the components are micro-services. This mechanism is subsequently called “unified communication system”.
  • FIG 1 illustrates an example of a platform according to the invention in which N+2 services are represented and communicate with each other via the unified communications system. All of the services represented on the figure 1 can be executed by a single computer or by several computers (and a maximum of N+2 computers).
  • the platform according to the invention allows industrial control which interfaces with diversified subsystems having varied interfaces (serial link, Ethernet, CAN, and with different protocols) and their business logic.
  • the service platform according to the invention provides high availability. Indeed, the proposed architecture makes it possible to achieve high levels of availability thanks to the great independence of the micro-services from each other which is notably ensured by the fact that each micro-service implements a simple business function and that it can communicate in a non-blocking manner with one or more other micro-services via the unified communications system. So when one of the micro-services no longer works, it does not take the entire platform with it, which continues to work.
  • the service platform according to the invention also provides high scalability and extensibility.
  • microservices can be on different host machines, load distribution is facilitated and can be reconfigured if necessary.
  • FIG. 3 illustrates the conceptual differences between a monolithic architecture used in known platforms for managing the services of an industrial system, and a platform based on micro-services according to the invention.
  • the independence of each micro-service for its execution improves the robustness of the platform in the event of failure of a micro-service, but also improves the deployment of the solution since each micro-service can be individually adapted to a new context, for example new, more recent equipment.
  • each microservice may include a user interface and/or a machine interface.
  • a user interface allows a user to interact with the microservice, for example to control it.
  • a machine interface allows a micro-service to communicate with equipment or a machine external to the platform.
  • service 2 and service N can exchange information and/or be controlled by equipment or a machine external to the platform) via a machine interface; we then speak of API.
  • the user interface and/or machine interface can be implemented as a separate subservice.
  • each microservice may include one or more microservice management functions.
  • a management function allows you to control the execution of the micro-service.
  • the management function(s) of the microservice may be a logging function.
  • Logging may relate to the system running the microservice and/or the microservice that includes the logging function, or another microservice. Logging refers to the sequential recording, in a file or database, of all events affecting the system running the micro-service and/or the micro-service that has the logging function and/or another micro-service. service. Logging can be timestamped.
  • the logging function may include a log centralization service for storing logging messages.
  • the log centralization service can be included in the logging function (i.e. internal to the logging function), or it can be independent of the logging function (i.e. external to the logging function). In the latter case, the log centralization service can be a micro-service of the services platform.
  • the log centralization service can be used by a logging function of a microservice and/or by several logging functions of several microservices.
  • the formatting of log messages performed by the logging function may include adding metadata to each log message. Metadata makes it possible to improve the processing of log data.
  • a TYPE metadata can be introduced into messages by the logging function.
  • This metadata is accompanied either by a SYSTEM value which indicates that the message is linked to the operation of the micro-service which issued it, or by an OPERATIONAL value indicating a message linked to and/or to the business functions of a micro -service, for example the one that sent the message.
  • AUDIT metadata can be introduced into messages by the logging function. This AUDIT metadata is accompanied by a TRUE value indicating that the message should be treated as security-related, or by a FALSE value indicating that the message should be treated as not security-related.
  • one of the management functions of the micro-service may be a management function of alarm(s) issued and/or received by the micro-service.
  • An alarm allows the micro-service to signal a level of criticality of an event which can be a present event (i.e. an event which is currently occurring, or even a past event (i.e. i.e. an event that has ended) or even a future event (i.e. an event that can occur, for example it is predicted).
  • a present event i.e. an event which is currently occurring, or even a past event (i.e. i.e. an event that has ended) or even a future event (i.e. an event that can occur, for example it is predicted).
  • a future event i.e. an event that can occur, for example it is predicted
  • one of the microservice management functions may be a microservice configuration management function.
  • the microservice configuration includes the set of defined parameters that determine how the microservice starts and/or is executed and/or is stopped.
  • one of the microservice management functions may be a function for saving and restoring a current state of the microservice.
  • the current state of the micro-service contains the data structures and their current values allowing the micro-service to restart with these initialization values rather than with default values (for example zero)
  • the service platform includes a unified communications system enabling the exchange of data and messages.
  • the unified communications system includes the use of sockets.
  • Sockets in a microservice can enable inter-microservice communication locally and inter-microservice communication over a TCP/IP network. It is understood that any network protocol allowing inter-micro-service communication can be used, and is not limited to TCP/IP. Sockets offer a model allowing inter-process communication (IPC, acronym for Inter Process Communication) to allow various processes to communicate both on the same machine and through a TCP/IP network.
  • IPC Inter Process Communication
  • the choice of local communication (for example when several micro-services are executed on the same computer) or via a TCP/IP network (for example when several micro-services are executed on several computers) is configured by the configuration management function of the microservice.
  • sockets for inter-micro-service communication use a stateless proxy which connects a micro-service publishing one or more messages concerning one or more messaging topics with one or more micro-services having subscribed to said one or more email subjects.
  • a stateless proxy is a proxy whose sole function is to transmit the messages it receives to the recipient(s) of the messages. The proxy does not store any information regarding the type of information and/or transaction it transmits and/or executes.
  • Such a proxy has the advantage of extreme simplicity in providing a multi-point to multi-point service, that is, a service in which several publishing micro-services can communicate with several micro-services that subscribe to publications, while limiting the number of sockets and therefore the consumption of computing resources and memory on the computer(s) that run the micro-services. In addition, it greatly facilitates the addition of new participants in the messaging system.
  • ZeroMQ ⁇ is used as the backbone for communications between microservices.
  • This API is middleware level (middleware in French) based on IPC (Inter Process Communication) sockets.
  • IPC Inter Process Communication
  • any other messaging API allowing micro-services to communicate can be used, preferably offering a subscription function to one or more messaging subjects, for example the nanomsg ⁇ messaging API.
  • ZeroMQ ⁇ is a high-performance asynchronous messaging library, intended for use in distributed or concurrent applications. The library's API is designed to resemble that of BSD sockets.
  • the version of ZeroMQ ⁇ used in this example is version 4.3.2 from July 8, 2019. It will be understood that implementations of version 4 or higher can be used.
  • the ZeroMQ ⁇ proxy is a stateless intermediary that connects (i.e. it connects) publishers micro-services with subscriber micro-services.
  • the ZeroMQ ⁇ proxy is not not a message agent (in English broker), that is to say it does not perform any conversion of messages.
  • the ZeroMQ ⁇ proxy is a stateless proxy, meaning it has no intelligence and does not perform any processing on messages; he is content to receive them and transmit them. It is understood that a stateless proxy can accept new micro-services easily, dynamically and without interruption of communications on the unified communications system.
  • the stateless proxy 40 receives on a first interface (denoted XSU8) all the micro-services 42 which publish, and on a second interface (denoted XPUB) all the micro-services (44) which are subscribed to the messages of one or more or all micro-services.
  • the stateless proxy 40 therefore forms the link between the publishers on one side and the subscribers on the other connected to the two interfaces.
  • the data sent by the microservices is serialized at the input (at the XSUB interface) and deserialized at the output (at the XPUB interface) using for example the Protobuff protocol (Protocol Buffer Format) which is a format binary exchange to serialize structured data.
  • Protobuff protocol Protocol Buffer Format
  • the unified communications system can be asynchronous, such as with ZeroMQ ⁇ .
  • the unified communications system can be non-blocking, that is, one message cannot prevent other messages from being transmitted. More generally, the non-blocking unified communications system allows the micro-service to carry out other tasks even if a sent message is pending, or an expected response to a message has not reached the micro-service.
  • the unified communications system can also be point-to-multipoint or multipoint-to-point; a micro-service can therefore send messages to several micro-services, and conversely several micro-services can send messages to a micro-service.
  • the messaging subservice may include one or more of the functions discussed in the examples that follow, and in one example it includes all of them.
  • the messaging sub-service may include a subscription function to one or more messaging topics.
  • a message subject can be determined by, but is not limited to, a subject identifier such as for example a measurement name coming from a micro-service interfaced with one or more external sensors such as 'Temperature' or 'Current'.
  • a subject identifier can also be a message category useful for the operation of the system itself, such as 'Alarm'.
  • the subscription function includes subscribing to one or more messaging subjects, formatting and writing the data contained in the messages associated with said one or more subscribed messaging subjects in a database adapted for storing time-stamped data.
  • the database can be a local database, that is, each microservice stores data on a database that is located on the computer running the microservice.
  • the database can be a remote database, for example located on a computer different from the one running the microservice.
  • the messaging subservice may include a posting function to a messaging topic. This publishing function allows the microservice to send messages for an email topic.
  • the messaging sub-service may include a function for sending a request via messaging.
  • a request is a message that awaits a response from one or more other microservices.
  • a query is a computer language used to access data, for example data from a database or other information systems.
  • the messaging subservice also includes a function for responding to a request received via messaging. This function therefore allows said micro-services to respond to the request issued by one of the micro-services.
  • all inter-service communications that is to say the sending of messages between the different sub-services of the platform's micro-services, go through the messaging sub-service.
  • an exception may concern the case where the service platform includes an interface allowing interaction with a user.
  • the interface is provided by a microservice that only uses local data for better performance, in particular to offer better responsiveness to the user.
  • a local web interface is provided to a user by a micro-service, and the web interface reads information from a local database of the computer which is running this micro-service, without going through the messaging system.
  • a microservice is a software element of the platform that includes a subservice implementing a business function and a messaging subservice.
  • the subservices implementing the business function perform the services of an industrial system
  • the messaging subservice offers the subservices implementing a business function means of communicating with each other, relying in particular on the communication system unified.
  • a service is a functionality or part of a functionality made available by a software component to perform a particular task.
  • one or more additional services may be provided by the operating system of one or more computers running one or more micro-services. In other words, additional services which are offered by the computers executing the micro-services can be exploited by the platform according to the invention.
  • the open source utility "monit” (version 5 or later), which falls into the category of daemons, can be in charge of monitoring the microservice and the computer running the microservice.
  • This utility can measure the computer resources (processor, memory, disks, network, etc.) used by the microservice, and be a watchdog that determines which processes are frozen.
  • the additional services may be selected from the following services. It is understood that these examples are not limiting and that any service that can be provided by an operating system can be an additional service.
  • an additional service may be an operating system initialization service which controls the execution of several programs at startup of the operating system.
  • the init program in UNIX/LINUX systems has a role as the main startup process which consists of controlling the execution of several programs.
  • An additional service can be a microservices startup service ; for example a service which sequences the startup of all micro-services according to a certain order, and which verifies their successful startup.
  • An additional service may be a service for storing and centrally managing log messages in a database.
  • daemon is a type of computer program, process, or set of processes that runs in the background rather than under the direct control of a user. Daemons are often started when the operating system loads, and are typically used to respond to network requests, hardware activity, or other programs by performing certain tasks.
  • a daemon can thus perform at least one of the following tasks, (i) The daemon determines whether one or more micro-services are working correctly, (ii) The daemon can restart a micro-service if it is not working correctly, (iii) ) The daemon can monitor the correct functioning of the operating system of the computer running the micro-service, (iv) The daemon can restart the operating system if it is not working correctly.
  • Microservices are programs run by a computer.
  • the term computer designates a programmable information processing system that operates by reading a set of instructions, organized into programs, which cause it to execute logical and arithmetic operations.
  • a computer comprises at least one calculation unit (for example a CPU) and a memory, in communication with the calculation unit, which stores the computer program.
  • the computer in the example includes a central processing unit (CPU) 1010 connected to an internal communication bus 1000, a random access memory (RAM) 1070 also connected to the bus.
  • the RAM is therefore in communication with the central processing unit.
  • the computer may have a graphics processing unit (GPU) 1110 which may be associated with a random access video memory 1100 connected to the bus.
  • Video RAM 1100 is also known in the art as a framebuffer.
  • the computer may include a mass storage device controller 1020; the controller manages access to a mass memory device, such as a hard disk 1030.
  • Mass memory devices are adapted to the concrete realization of computer program instructions and include all forms of non-volatile memory, including including by way of example semiconductor memory devices, such as EPROM, EEPROM and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and 1040 CD-ROM disks. All of the above can be supplemented or incorporated into specially designed ASICs (application specific integrated circuits).
  • the computer may include a network card 1050 that manages access to a network 1060.
  • the client computer may also include a haptic device 1090 such as a cursor controller, keyboard or the like.
  • the computer can store one or more computer programs on its RAM, or on mass memory.
  • the computer program may include instructions executable by the computer's calculation unit, the instructions comprising means for causing the computer above to implement all or part of the platform according to the invention.
  • the program may be recordable on any data storage medium, including system RAM and/or mass storage.
  • the program may, for example, be implemented in digital electronic circuits, or in computer hardware, firmware, software, or combinations thereof.
  • the program may be implemented as an apparatus, such as a product tangibly embedded in a machine-readable storage device for execution by a programmable processor.
  • the processor (the central processing unit) can thus be programmed and coupled to receive data and instructions from a data storage system, at least one input device and at least one output device.
  • the application program may be implemented in a procedural or object-oriented programming language. high level, or in assembly or machine language if necessary. In all cases, the language can be a compiled or interpreted language.
  • the program can be a full installer or an updater. The application of the program on the system in any case results in instructions for the implementation of the platform.
  • the platform can be distributed, that is, it is implemented (executed) by several computers, not just one.
  • the platform program can then be made up of several subprograms executed by several machines, thus forming the service platform according to the invention.
  • each computer runs at least one microservice.
  • FIG. 1 previously discussed illustrates an example of a platform that can be executed by multiple computers.
  • each microservice executed by a computer can be executed as a single process.
  • Each subservice of the microservice can be executed as a thread.
  • a thread (French term for "thread”, term and definition standardized by ISO/IEC 2382-7:2000) is similar to a process with the difference that a process has its own memory which it does not share with other processes while the threads of the same process share its memory.
  • the “multi-use of threads” of the subservices of a micro-service contributes to the performance of the micro-service because the threads are executed concurrently, in parallel.
  • FIG. 2 illustrates an example of a typical micro-service model according to the invention.
  • a model of a microservice is represented.
  • the model includes three groups of subservices.
  • a first group represents the main sub-services which are the main (i.e. expected) functionality of the micro-service.
  • a second group provides utility subservices for managing the microservice.
  • a third group represents the Communication sub-service to allow the micro-service to communicate with other micro-services, and therefore to be integrated into the platform.
  • micro-service also called micro-service template in English
  • the topmost group includes one or more sub-departments that represent the business function (business 1 and business 2 in the figure).
  • the middle group includes five microservice management functions.
  • the bottom group shows the functions that the messaging subservice includes.
  • the messaging sub-service includes a publication function in one or more messaging topics (named Publish-subscribe), a function for sending a request via messaging (named Request-Reply).
  • a subscription function to one or more messaging topics
  • a response function to a request received via messaging.
  • the implementation of the standardized generic structure can be carried out in an object-oriented programming language, for example in C++.
  • the business function can be implemented by a computer subroutine (named Main Program in the figure) which, when executed by the computer, performs the business function.
  • the five management functions of the microservice can be implemented by three computer routines.
  • the first subroutine (named Syslog clients API) implements the two logging functions “System logs” and “Operational logs”.
  • the second subroutine (named Alarm lib) implements the “Alarm Management” function.
  • a third subroutine (named “Protected directory in OS filesystem) can implement the “Config Handler” and “Context handler” functions.
  • the function of the third subroutine can be provided by the operating system of the computer running the microservice.
  • sub-services of a micro-service can be those offered by the operating system of the computer running the micro-service.
  • the operating system file system management service can store and manage in a database the alarm messages sent/received by the micro-service as well as the current state(s) of the micro-service.
  • the messaging subservice functions can be implemented using the ZeroMQ ⁇ API discussed in reference with the Figure 4 .
  • the typical micro-service model according to the invention therefore offers access to standardized messaging common to all the micro-services of the platform via a unified communication system which can use sockets for inter-process communication, either locally within the same operating system of a computer, either via a network and a network protocol (for example TCP/IP), or a combination of the two.
  • Common messaging can use an asynchronous “Publish-Subscribe” communication scheme.
  • Each microservice can emit data by publishing to the common messaging system, without needing to know whether the data will be consumed or not.
  • Each microservice can receive data by subscribing to data published by another microservice, without the publisher needing to be informed. Communication can therefore be asynchronous, non-blocking, point-to-multipoint and multipoint-to-point.
  • the service platform according to the invention is capable of managing services of an industrial system.
  • the latter implements a system for managing a battery and its auxiliary equipment.
  • a battery is a generic term designating a set of electrical accumulators, called elements, connected together so as to create an electrical generator of desired voltage, power and capacity.
  • a battery converts the electrical energy accumulated during the charging phase into chemical energy.
  • Chemical energy consists of electrochemically active compounds arranged in the element. The electrical energy is returned by conversion of chemical energy into electrical energy during the discharge phase.
  • the electrodes, arranged in a container are electrically connected to current output terminals which ensure electrical continuity between the electrodes and an electrical consumer with which the element is associated.
  • the battery is made up of one or more branches electrically connected in parallel. Each branch comprises one or more modules electrically connected in series, and each module comprising one or more electrochemical elements electrically connected in series or in parallel.
  • FIG. 6 is an example of a battery configuration in which N electrochemical elements (Cell1, Cell2,..., CelIN) are connected in series and arranged together in the same enclosure to form a first module (Module1). Similarly, N electrochemical elements are connected in series and arranged in an xth enclosure to form an xth module (Modulex).
  • the X modules are connected in series to form a battery (Bat).
  • the X modules constitute a branch of the circuit, called ESSU (English acronym for Energy Storage System Unit).
  • the elements are also not necessarily connected in series but can also be connected in parallel. It is also possible to connect certain elements together in parallel to obtain several associations of elements in parallel and then to connect these associations of elements in series.
  • the battery may comprise any number of modules, in a configuration not necessarily limited to a series connection.
  • the battery may comprise p parallel branches, each parallel branch comprising at least one module consisting of at least one element.
  • the auxiliary equipment of a battery is equipment contributing either to the safety, security, performance or operation of the battery.
  • at least one auxiliary equipment of the battery is selected from a fire detection and suppression system that prevents the spread of fire if one or more electrochemical modules catch fire, an air conditioning system to keep the battery in temperature conditions ensuring its optimal operation, a system for monitoring physical access to the battery (for example the room in which the battery is stored), or a system for measuring the electrical power delivered and/or received by the battery.
  • Each auxiliary equipment is managed by one or more micro-services of the platform responsible for performing a business function.
  • the micro-service that manages the fire extinguishing system may have the business function of measuring the temperature around the battery and sending alarms in the event of a fire to a micro-service providing an interface user allowing an operator to be informed of a battery problem.
  • the micro-service managing the air conditioning system may have the business function of checking that the air conditioning is working properly and sending alarms in the event of a failure.
  • the business function of the micro-service associated with the physical access monitoring system can be to send messages having a level of criticality depending on the people entering the room where the battery is stored.
  • the service platform according to the invention can be used to manage containers which are battery assemblies.
  • the platform can manage the different branches of the container's batteries as well as auxiliary equipment.
  • the platform makes it possible, for example, to send operating data to a logging micro-service.
  • the service platform according to the invention makes it possible to aggregate the data obtained on several devices by sending them to a data logging micro-service, or even to a data storage micro-service in a database.
  • the platform can manage several batteries, containers and offer an aggregated view of the parameters common to this equipment.
  • each battery in a container includes a micro-service for measuring the instantaneous electrical power delivered by the battery, all the batteries of one or more containers sending the data to a data aggregation micro-service allowing an operator to view the aggregated data, for example using a web service of this same micro- container data aggregation service.
  • a service platform makes it possible to facilitate the management of a battery and its auxiliary equipment.
  • battery management functionalities which are traditionally implemented in BMS (Battery Management System, bodies contributing to battery management), can be transferred outside the batteries in order to simplify their design and use.
  • SoC state of charge
  • SoH state of health
  • an assembly can be formed comprising one or more battery branches connected in parallel forming a battery, each branch of the battery comprising one or more modules connected in series, each module comprising one or more electrochemical elements.
  • the assembly also includes one or more computers, and a service platform according to the invention which is executed by the computers of the assembly.
  • the micro-services of the service platform implement business functions for managing the battery and its auxiliary equipment: for example for each management function of a battery and for each auxiliary equipment interface of the battery.
  • the assembly also includes one or more branch control units, which execute connection/disconnection orders and which provide measurements of the parameters of the branches, modules and electrochemical elements.
  • a control unit makes it possible to supervise the electrical state of a branch, for example to open or close the circuit of the branch.
  • At least one of the business functions may be selected from the following.
  • the first business function is to determine whether one or more branches of the battery are connected or disconnected to the electrical network, that is, to the battery output.
  • Another business function is to calculate current instructions applicable to charging and discharging drums.
  • a third business function is to calculate the state of charge (SoC) of the battery; the micro-service therefore implements at least one algorithm making it possible to measure or estimate the SoC.
  • SoC state of charge
  • a fourth function is to calculate the level of health (SoH, English acronym for State of Health) or level of life of the battery; the micro-service therefore implements at least one algorithm making it possible to measure or estimate the SoH of the battery.
  • a charge level (SoC) and a state of health (SoH) for a branch of the circuit (ESSU) are calculated by the BMS, and a charge level (SoC) and a state of health (SoH) by battery are calculated by the micro-services platform.
  • the assembly comprises two or more sets of battery branches mounted in parallel respectively forming two or more batteries.
  • This set with at least two batteries may include a micro-service implementing a business function for aggregating data from one or more of the other business functions previously mentioned.
  • the aggregation microservice aggregates data that pertains to each type of business function.
  • data aggregation can be carried out differently depending on the business function, and that there can be an aggregation micro-service per business function.
  • the assembly may include one or more microservices capable of sending data exchanged via the unified communications system to a remote storage system for storage.
  • the exchanged data can for example be selected using one or more of the metadata present in the messages carrying the exchanged data.
  • the storage system may be, but is not limited to, a database, a file system, one or more storage servers forming a cloud.
  • the remote storage system can be coupled with a machine learning system that can learn on the stored data. The data received are therefore observations making it possible to construct a model, for example a model of battery wear.
  • the service platform of the assembly further includes a micro-service for updating the other micro-services.
  • the update microservice can send requests to other microservices to find out their respective versions, and based on the responses to the requests, it can determine which microservices need to be updated.
  • the micro-services platform also includes a micro-service for updating the software of the branch control-command bodies. The decision to update or not a control unit can be made in the same way as for updating micro-services.

Landscapes

  • Engineering & Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Chemical & Material Sciences (AREA)
  • Chemical Kinetics & Catalysis (AREA)
  • Electrochemistry (AREA)
  • General Chemical & Material Sciences (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)

Description

    DOMAINE DE L'INVENTION
  • La présente invention concerne le domaine technique des plateformes de services utilisant des micro-services pour un système de contrôle-commande industriel.
    • ARRIERE-PLAN TECHNIQUE
  • L'exécution des fonctions de gestion d'un système industriel complexe repose généralement sur une infrastructure informatique. Ces fonctions comprennent notamment le suivi opérationnel, la programmation et le diagnostic à distance des machines et des équipements, le suivi et diagnostic de production, ainsi que des interfaces homme/machine permettant et facilitant les interactions des opérateurs humains.
  • Par exemple, un système industriel peut être un système de gestion de batterie (BMS, acronyme de l'anglais Battery Management System) qui est un système de contrôle électronique qui a de multiples fonctions dans un système de stockage d'énergie basé sur une ou des batteries. Ces fonctions comprennent, mais ne sont pas limitées à, la surveillance de l'état de la batterie (état de charge, état de santé, température, courant électrique la traversant, etc...), le contrôle des connections de puissance de la batterie avec une charge, le contrôle de la charge, la surveillance de la sûreté de fonctionnement de la batterie et des fonctions assurant sa sûreté et sa sécurité.
  • De façon générale, une infrastructure informatique de gestion d'un système industriel comprend une unité de gestion qui exécute les services et qui est connectée à un ou plusieurs réseaux sur lesquels les machines et équipements du système sont également connectés. Les machines et équipements transmettent à l'unité de gestion des informations les concernant, et l'unité de calcul exécute les fonctions métiers sur la base des informations reçues, et envoie des commandes aux machines et équipements. La figure 7 illustre un [exemple de système industriel dans lequel des équipements (A, B), des capteurs (1, 2, 3), un système hôte, un utilisateur sont reliés à un organe de gestion de processus industriel. Ce dernier reçoit par exemple des données, des mesures, des commandes de configuration, des configurations, et transmet par exemple des commandes, des données, des affichages... Les flux sont centralisés sur l'organe de gestion.
  • Or, le niveau de complexité des systèmes industriels supervisés peut atteindre un niveau tel qu'il devient difficile de garantir à la fois leur niveau de disponibilité et leur évolutivité (ajout d'un nouvel élément ou d'une fonction). En effet, : ils regroupent des sous-systèmes diversifiés, hétérogènes, ayant des interfaces variées (liaisons physiques de type série, Ethernet, CAN, sans-fils, et avec différents protocoles), différentes logiques métiers, des calculs algorithmiques et du stockage de données et sont traditionnellement implémentés de façon imbriquée dans une architecture monolithique. Toutes ces caractéristiques limitent leur évolutivité et leur niveau de disponibilité.
    • Le document « KaliGreen: A distributed Scheduler for Energy Saving », LVAREZ-VALERA HERNN H et al., PROCEDIA COMPUTER SCIENCE, ELSEVIER, AMSTERDAM, vol. 141, 5 novembre 2018 (2018-11-05), pages 223-230, décrit un ordonnanceur distribué pour l'économie d'énergie.
    • Le document US 2018/0295187 A1 décrit un procédé de surveillance de systèmes de stockage utilisant un dispositif de détection sans fil à faible puissance basé sur le WiFi.
  • Il n'existe donc pas actuellement de plateforme informatique de gestion offrant à la fois un haut niveau de disponibilité sans avoir recours à la redondance et une grande évolutivité.
    • RESUME DE L'INVENTION
  • La présente invention utilise une approche « service » faisant appel à une architecture de micro-services. Pour cela, l'invention propose une plateforme de services, telle que revendiquée dans la revendication 1, implementée par un ou plusieurs ordinateurs. La plateforme comprend un ou plusieurs micro-services. Chaque micro-service a une structure générique normalisée comprenant :
    • * un sous-service implémentant une fonction métier ;
    • * un sous-service de messagerie ;
  • La plateforme de service comprend en outre un système de communication unifié pour un échange de données et de messages.
  • Une telle plateforme améliore le niveau de disponibilité d'une plateforme de gestion, tout en offrant un haut niveau de disponibilité sans avoir recours à la 1 redondance et une grande évolutivité. D'autres améliorations, parmi lesquelles les modes de réalisation préférés, qui correspondent aux revendications dépendantes, seront discutées plus bas.
  • La plateforme de services peut implémenter un système de gestion d'une batterie et de ses équipements auxiliaires ; on parle alors d'une plateforme de services, implémentée par un ou plusieurs ordinateurs, de gestion d'une batterie et de ses équipements auxiliaires.
  • Selon différents modes de réalisation, toute combinaison d'au moins l'une des caractéristiques suivantes peut être implémentée :
    • chaque micro-service comprend en outre une interface utilisateur et/ou machine ;
    • chaque micro-service comprend en outre au moins une fonction de gestion du micro-service ;
    • ladite au moins une fonction de gestion est sélectionnée parmi une fonction de journalisation du système exécutant le micro-service et/ou du micro-service exécuté ; une fonction de gestion d'alarme(s) émise(s) et/ou reçue(s) par le micro-service ; une fonction de gestion de la configuration du micro-service ; une fonction de sauvegarde et de restauration d'un état courant du micro-service ;
    • un service de centralisation des journaux sur lequel sont stockés des messages de journalisation mis en forme et envoyés par la fonction de journalisation.
    • la fonction de journalisation ajoute une métadonnée à chaque message de journalisation mise en forme et envoyée par la fonction de journalisation, les métadonnées comprenant - une métadonnée PRIORITY, prenant une valeur sélectionnée parmi les valeurs suivantes : TRACE ; DEBUG ; INFO ; WARN ; ERROR ; CRITICAL ; - une métadonnée TYPE, prenant une valeur sélectionnée parmi les valeurs suivantes : une valeur SYSTEM indiquant un message lié au fonctionnement du micro-service en question ; une valeur OPERATIONNAL indiquant un message lié aux fonctions métier ; - une métadonnée AUDIT, prenant une valeur sélectionnée parmi les valeurs suivantes : une valeur VRAI indiquant que le message doit être traité comme ayant trait à la sécurité ; une valeur FAUX indiquant que le message doit être traité comme n'ayant pas trait à la sécurité ;
    • le système de communication unifié comprend l'utilisation, de sockets pour une communication inter-micro-service en local ou via un réseau TCP/IP, ce choix étant configuré par la fonction de gestion de la configuration du micro-service ;
    • les sockets pour la communication inter- micro-service utilisent un mandataire sans état qui met en relation un micro-service publiant un ou des messages concernant un ou plusieurs sujets de la messagerie avec un ou plusieurs micro-services ayant souscrit auxdits un ou plusieurs sujets de la messagerie ;
    • le sous-service de messagerie comprend :
      • * une fonction de souscription à un ou plusieurs sujets de la messagerie ;
      • * une fonction de publication dans un sujet de la messagerie ;
      • * une fonction d'envoi de requête via la messagerie ;
      • * une fonction de réponse à une requête reçue via la messagerie.
    • la fonction de souscription comprend souscrire à un ou plusieurs sujets du sous-service de messagerie, mettre en forme et écrire les données contenues dans les messages associés audit un ou plusieurs sujets souscrits dans une base de données locale adaptée pour le stockage de données horodatées ;
    • le système de communication unifié est asynchrone, non-bloquant, et point à multipoints ou multipoints à point ;
    • un ou plusieurs services supplémentaires sont fournis par le système d'exploitation d'un ou plusieurs ordinateurs exécutant un ou plusieurs micro-services ;
    • le un ou plusieurs services supplémentaires sont sélectionnés parmi un service d'initialisation du système d'exploitation ; un service de démarrage des micro-services ; un service central de stockage et de gestion des messages de journalisation dans une base de données ;
    • un daemon (un « démon » en français) exécuté par un ordinateur, le daemon réalisant au moins une des tâches suivantes : déterminer si le un ou plusieurs micro-services fonctionne correctement, et le redémarre le cas échéant ; surveiller le bon fonctionnement du système d'exploitation de l'ordinateur exécutant le micro-service et le redémarrer le cas échéant ;
    • chaque micro-service est exécuté comme un unique processus et chaque sous-service du micro-service est exécuté comme un thread ; un thread (terme anglais pour fil d'exécution, terme et définition normalisés par ISO/CEI 2382-7:2000) est similaire à un processus à la différence qu'un processus possède sa propre mémoire qu'il ne partage pas avec les autres processus tandis que les threads d'un même processus se partagent sa mémoire.
  • Il est également proposé une utilisation de la plateforme de services selon l'invention pour implémenter un système de gestion d'une batterie et de ses équipements auxiliaires, la batterie étant formée d'une ou plusieurs branches montées en parallèle, chaque branche comprenant un ou plusieurs modules montés en série, chaque module comprenant un ou plusieurs éléments électrochimiques.
  • Cette utilisation peut en outre comprendre au moins un équipement auxiliaire qui est sélectionné parmi un système d'extinction d'incendie ; un système de climatisation ; un système de surveillance des accès physiques ; un système de mesure de la puissance électrique.
  • Il est également proposé un ensemble comprenant :
    • une ou plusieurs branches de batterie montées en parallèle formant une batterie, chaque branche de la batterie comprenant un ou plusieurs modules montés en série, chaque module comprenant un ou plusieurs éléments électrochimiques ;
    • un ou plusieurs ordinateurs ;
    • une plateforme de services selon l'invention implémentée par lesdits un ou plusieurs ordinateurs, dans laquelle les micro-services implémentent des fonctions métiers de gestion de la batterie et de ses équipements auxiliaires ; et
    • un ou plusieurs organes de contrôle-commande des branches, qui exécutent les ordres de connexion/déconnexion et qui fournissent des mesures des paramètres des branches, des modules et des éléments électrochimiques.
  • Il est également proposé un ensemble comprenant :
    • une ou plusieurs branches de batterie montées en parallèle formant une batterie, chaque branche de la batterie comprenant un ou plusieurs modules montés en série, chaque module comprenant un ou plusieurs éléments électrochimiques ;
    • au moins un équipement auxiliaire de la batterie;
    • un ou plusieurs ordinateurs ;
    • une plateforme de services selon l'invention implémentée par lesdits un ou plusieurs ordinateurs ; et
    • un ou plusieurs organes de contrôle-commande des branches, qui exécutent les ordres de connexion/déconnexion et qui fournissent des mesures des paramètres des branches, des modules et des éléments électrochimiques.
  • Selon différents modes de réalisation, toute combinaison d'au moins l'une des caractéristiques suivantes peut être implémentée pour l'ensemble :
    • une ou plusieurs des fonctions métier sont sélectionnées parmi la détermination de la connexion / déconnexion au réseau électrique d'au moins une branche de la batterie ; le calcul des consignes de courant applicables à la charge et à la décharge de la batterie ; le calcul du niveau de charge de la batterie ; le calcul du niveau de vie de la batterie ;
    • deux ou plus ensembles de branches de batterie montées en parallèle formant respectivement deux ou plus batteries et dans lequel la plateforme de service comprend en outre un micro-service implémentant une fonction métier d'agrégation des données d'une ou plusieurs des autres fonctions métier.
    • la plateforme de service comprend en outre un ou plusieurs micro-services pouvant envoyer des données échangées sur le système de communication unifié en direction d'un système de stockage distant pour y être stockées, le système de stockage distant étant en outre couplé avec un système d'apprentissage automatique pouvant effectuer son apprentissage sur les données stockées ;
    • la plateforme de service comprend en outre un micro-service de mise à jour des autres micro-services ;
    • la plateforme de service comprend en outre un micro-service de mise à jour des logiciels des organes de contrôle-commande des branches ;
    • au moins un équipement auxiliaire est sélectionné parmi :
      • un système d'extinction d'incendie ;
      • un système de climatisation ;
      • un système de surveillance des accès physiques ;
      • un système de mesure de la puissance électrique.
    BREVE DESCRIPTION DES FIGURES
  • Des modes de réalisation de l'invention vont être maintenant décrits au moyen d'exemples non-limitatifs de l'invention, et en référence aux figures, où :
    • [Fig. 1] est un exemple d'architecture de communication entre les micro-services ;
    • [Fig. 2] est un exemple de modèle type de micro-service ;
    • [Fig. 3] illustre une comparaison entre une gestion monolithique des services et une gestion via micro-services ;
    • [Fig. 4] est un exemple de messagerie comprenant des publieurs et des souscripteurs abonnés à des sujets de la messagerie
    • [Fig. 5] est un exemple d'ordinateur pouvant exécuter un micro-service ;
    • [Fig. 6] est un exemple de configuration d'une batterie pouvant être gérée en utilisant la plateforme de services ; et
    • [Fig. 7] illustre la diversité des équipements et des services proposés par une plateforme de service.
    DESCRIPTION DE MODES DE REALISATION DE L'INVENTION
  • La présente invention concerne une plateforme de services implémentée par un ou plusieurs ordinateurs. La plateforme de services propose une infrastructure informatique de gestion d'un système industriel. La plateforme de service gère un ou plus services sous la forme de micro-services. Un service de la plateforme est sous la forme d'un micro-service. Si la plateforme gère plusieurs services, il peut y avoir autant de micro-services qu'il y a de services. Les micro-services peuvent être exécutés sur un ou plusieurs ordinateurs, c'est-à-dire qu'une unité de calcul peut exécuter un ou plusieurs micro-services.
  • Le terme micro-service fait référence à une architecture logicielle qui structure une application comme un ensemble de services réalisant chacun une fonction unitaire simple et faiblement couplés entre eux. Les micro-services doivent être aussi indépendants que possible les uns des autres, et ils doivent communiquer entre eux indépendamment les uns avec les autres en utilisant des API indépendantes du langage de programmation.
  • Chaque micro-service possède une structure générique normalisée. Une structure générique normalisée est décrite grâce à un modèle type (appelé en anglais "template") de micro-service. Le modèle type de micro-service normalise la construction et le fonctionnement du micro-service. Si la plateforme comprend plusieurs micro-services, chaque micro-service sera conforme à la structure générique normalisée.
  • La structure générique normalisée qui s'applique à chaque micro-service comprend a minima les deux sous-services suivants. Le premier sous-service est un sous-service implémentant une fonction métier. La fonction métier définit un rôle spécifique qui va être rendu par le micro-service dans le cadre de son utilisation dans le système industriel géré par la plateforme de gestion. La fonction métier peut être également nommée fonctionnalité métier. La fonction métier ou fonctionnalité métier peut comprendre par exemple une application métier, un processus métier, ou encore un service métier.
  • Le deuxième sous-service est un sous-service de messagerie qui permet au micro-service de communiquer avec un élément externe à lui-même, par exemple un autre micro-service. Le sous-service de messagerie définit une APl (acronyme de l'anglais Application Programming Interface) permettant au micro-service d'accéder à une messagerie commune aux autres micro-services et donc de communiquer avec eux.
  • La plateforme de service comprend un système d'échange de données et de messages qui est un dispositif de transmission de données et de messages partagé entre plusieurs composants de la plateforme, par exemple les composants sont des micro-services. Ce mécanisme est appelé par la suite « système de communication unifié ».
  • La figure 1 illustre un exemple de plateforme selon l'invention dans laquelle N+2 services sont représentés et communiquent entre eux via le système de communication unifié. L'ensemble des services représentés sur la figure 1 peuvent être exécutés par un seul ordinateur ou encore par plusieurs ordinateurs (et au maximum N+2 ordinateurs).
  • La plateforme selon l'invention permet un contrôle industriel qui s'interface avec des sous-systèmes diversifiés ayant des interfaces variées (liaison série, Ethernet, CAN, et avec différents protocoles) et leur logique métier. La plateforme de service selon l'invention fournit une haute disponibilité. En effet, l'architecture proposée permet d'atteindre de hauts niveaux de disponibilité grâce à la grande indépendance des micro-services entre eux qui est notamment assurée par le fait que chaque micro-service implémente une fonction métier simple et qu'il peut communiquer de manière non-bloquante avec un ou plusieurs autres micro-services via le système de communication unifié. Ainsi lorsqu'un des micro-services ne fonctionne plus, il n'entraine pas la totalité de la plateforme avec lui qui continue à fonctionner. La plateforme de service selon l'invention fournit également une grande évolutivité et extensibilité. En effet, l'ajout d'un nouveau micro-service est possible sans modification et sans impact sur les micro-services déjà existants ; la seule condition est que les ressources matérielles permettant son exécution soient disponibles. De plus, les micro-services pouvant être sur des machines hôtes différentes, la répartition de la charge est facilitée et peut être reconfigurée si besoin est.
  • La figure 3 illustre les différences conceptuelles entre une architecture monolithique utilisée dans des plateformes connues de gestion des services d'un système industriel, et une plateforme basée sur des micro-services selon l'invention. Notamment, l'indépendance de chaque micro-service pour son exécution améliore la robustesse de la plateforme en cas de défaillance d'un micro-service, mais améliore également le déploiement de la solution puisque chaque micro-service peut être individuellement adapté à un nouveau contexte, par exemple un nouvel équipement plus récent.
  • Dans des exemples, chaque micro-service peut comprendre une interface utilisateur et/ou une interface machine. Une interface utilisateur permet à un utilisateur d'interagir avec le micro-service, par exemple pour le contrôler. Une interface machine permet à un micro-service de dialoguer avec un équipement ou une machine extérieure à la plateforme. Sur la figure 1, le service 2 et le service N peuvent échanger des informations et/ou être contrôlés par un équipement ou une machine extérieure à la plateforme) via une interface machine ; on parle alors d'API. L'interface utilisateur et/ou l'interface machine peuvent être implémentées comme un sous-service à part.
  • Dans des exemples, chaque micro-service peut comprendre une ou plusieurs fonctions de gestion du micro-service. Une fonction de gestion permet de contrôler l'exécution du micro-service.
  • Dans des exemples, la ou les fonctions de gestion du micro-service peuvent être une fonction de journalisation. La journalisation peut concerner le système exécutant le micro-service et/ou le micro-service qui comporte la fonction de journalisation, ou encore un autre micro-service. La journalisation désigne l'enregistrement séquentiel, dans un fichier ou une base de données de tous les événements affectant le système exécutant le micro-service et/ou le micro-service qui compte la fonction de journalisation et/ou d'un autre micro-service. La journalisation peut être horodatée.
  • Dans des exemples, la fonction de journalisation peut comprendre un service de centralisation des journaux pour stocker les messages de journalisation. Le service de centralisation des journaux peut être compris dans la fonction de journalisation (c'est-à-dire interne à la fonction de journalisation), ou bien il peut être autonome à la fonction de journalisation (c'est-à-dire externe à la fonction de journalisation). Dans ce dernier cas, le service de centralisation des journaux peut être un micro-service de la plateforme de services. Le service de centralisation des journaux peut être utilisé par une fonction de journalisation d'un micro-service et/ou par plusieurs fonctions de journalisations de plusieurs micro-services.
  • Dans des exemples, la mise en forme des messages de journalisation réalisée par la fonction de journalisation peut comprendre l'ajout d'une métadonnée à chaque message de journalisation. Les métadonnées permettent d'améliorer les traitements des données de journalisations.
  • Dans des exemples, une métadonnée PRIORITY peut être introduite dans les messages par la fonction de journalisation. Cette métadonnée informe du niveau de criticité du message selon la valeur associée à la métadonnée PRIORITY. Dans un ordre croissant de criticité, la valeur associée peut être sélectionnée parmi les valeurs suivantes :
    • TRACE : le contenu du message ne comprend pas d'événement courant particulier ;
    • DEBUG : le contenu du message peut comprendre des informations pertinentes pour un futur événement courant ;
    • INFO : le contenu du message comprend des informations pertinentes pour un évènement courant ;
    • WARN : le contenu du message comprend des informations pertinentes pour un événement courant problématique ;
    • ERROR : le contenu du message comprend des informations pour un évènement courant grave ;
    • CRITICAL : le contenu du message comprend des informations pour un événement courant critique.
  • Dans des exemples, une métadonnée TYPE peut être introduite dans les messages par la fonction de journalisation. Cette métadonnée est accompagnée soit d'une valeur SYSTEM qui indique que le message est lié au fonctionnement du micro-service qui l'a émis, soit d'une valeur OPERATIONNAL indiquant un message lié à et/ou aux fonctions métier d'un micro-service, par exemple celui qui a émis le message.
  • Dans des exemples, une métadonnée AUDIT peut être introduite dans les messages par la fonction de journalisation. Cette métadonnée AUDIT est accompagnée d'une valeur VRAI indiquant que le message doit être traité comme ayant trait à la sécurité, ou bien d'une valeur FAUX indiquant que le message doit être traité comme n'ayant pas trait à la sécurité.
  • Les précédents exemples de métadonnées introduites dans les messages par la fonction de journalisation peuvent être combinés entre eux.
  • Dans des exemples, l'une des fonctions de gestion du micro-service peut être une fonction de gestion d'alarme(s) émise(s) et/ou reçue(s) par le micro-service. Une alarme permet au micro-service de signaler un niveau de criticité d'un événement qui peut être un événement présent (c'est à dire un événement qui est en train de se produire, ou bien encore un événement passé (c'est-à-dire un événement qui s'est terminé) ou bien encore un événement futur (c'est-à-dire un événement qui peut se produire, par exemple il est prédit). De manière générale, on utilise le terme événement courant pour désigner ces différents types d'évènement.
  • Dans des exemples, l'une des fonctions de gestion du micro-service peut être une fonction de gestion de la configuration du micro-service. La configuration du micro-service comprend l'ensemble des paramètres définis qui déterminent la façon dont le micro-service démarre et/ou est exécuté et/ou est stoppé.
  • Dans des exemples, l'une des fonctions de gestion du micro-service peut être une fonction de sauvegarde et de restauration d'un état courant du micro-service. L'état courant du micro-service contient les structures de données et leur valeurs courantes permettant au micro-service de redémarrer avec ces valeurs d'initialisation plutôt qu'avec des valeurs par défaut (par exemple zéro)
  • La plateforme de services comprend un système de communication unifié permettant l'échange de données et de messages.
  • Dans des exemples, le système de communication unifié comprend l'utilisation de sockets. Les sockets d'un micro-service peuvent permettre une communication inter-micro-service en local et une communication inter-micro-service via un réseau TCP/IP. On comprend que tout protocole réseau permettant une communication inter-micro-service peut être utilisé, et n'est pas limité à TCP/IP. Les sockets offrent un modèle permettant la communication inter processus (IPC, acronyme de l'anglais Inter Process Communication) afin de permettre à divers processus de communiquer aussi bien sur une même machine qu'à travers un réseau TCP/IP.
  • Le choix d'une communication en local (par exemple lorsque plusieurs micro-services sont exécutés sur un même ordinateur) ou via un réseau TCP/IP (par exemple lorsque plusieurs micro-services sont exécutés sur plusieurs ordinateurs) est configuré par la fonction de gestion de la configuration du micro-service.
  • Dans un exemple, les sockets pour la communication inter-micro-service utilisent un mandataire sans état qui met en relation un micro-service publiant un ou des messages concernant un ou plusieurs sujets de la messagerie avec un ou plusieurs micro-services ayant souscrit auxdits un ou plusieurs sujets de la messagerie. Un mandataire sans état (en anglais stateless proxy) est un mandataire qui a pour unique fonction de transmettre les messages qu'il reçoit au(x) destinataire(s) des messages. Le mandataire ne stocke aucune information concernant le type d'information et/ou de transaction qu'il transmet et/ou exécute. Un tel mandataire présente l'avantage d'une extrême simplicité dans la fourniture d'un service multi-points à multi-points, c'est-à-dire d'un service dans lequel plusieurs micro-services qui publient peuvent communiquer avec plusieurs micro-services qui souscrivent aux publications, tout en limitant le nombre de sockets et donc la consommation de ressources de calcul et de mémoire sur le ou les ordinateur(s) qui exécutent les micro-services. De plus il facilite grandement l'ajout de nouveaux intervenants dans le système de messagerie.
  • La figure 4 est un exemple d'implémentation d'une communication inter-micro-service. Dans cet exemple, une API de messagerie ZeroMQ© est utilisée comme épine dorsale pour les communications entre les micro-services. Cette API est de niveau middleware (intergiciel en français) basée sur des sockets IPC (Inter Process Communication). On comprend que toute autre API de messagerie permettant de mettre en communication des micro-services peut être utilisée, offrant de préférence une fonction de souscription à un ou plusieurs sujets de la messagerie, par exemple l'API de messagerie nanomsg©. ZeroMQ© est une bibliothèque de messagerie asynchrone haute performance, destinée à être utilisée dans des applications distribuées ou concurrentes. L'API de la bibliothèque est conçue pour ressembler à celle des sockets BSD. La version de ZeroMQ© utilisée dans cet exemple est la version 4.3.2 du le 8 juillet 2019. On comprendra que les implémentations de la version 4 ou supérieure peuvent être utilisées. Le proxy ZeroMQ© est un intermédiaire sans état qui met en relation (c'est-à-dire qu'il relie) des micro-services publieurs (en anglais publishers) avec des micro-services abonnés (en anglais subscribers). Le proxy ZeroMQ© n'est pas un agent de message (en anglais broker), c'est-à-dire qu'il n'effectue aucune conversion des messages. Le proxy ZeroMQ© est un mandataire sans état, c'est-à-dire qu'il n'a aucune intelligence et qu'il n'effectue aucun traitement sur les messages ; il se contente de les recevoir et de les transmettre. On comprend qu'un mandataire sans état peut accepter de nouveaux micro-services facilement, dynamiquement et sans interruption des communications sur le système de communication unifié.
  • Toujours en référence à la figure 4, le mandataire sans état 40 reçoit sur une première interface (notée XSU8) l'ensemble des micro-services 42 qui publient, et sur une deuxième interface (notée XPUB) l'ensemble des micro-services (44) qui sont abonnés aux messages d'un ou plusieurs ou de tous les micro-services. Le mandataire sans état 40 fait donc le lien entre les publieurs d'un côté et les abonnés de l'autre connectés aux deux interfaces. Les données envoyées par les micro-services sont sérialisées en entrée (au niveau de l'interface XSUB) et désérialisées en sortie (au niveau de l'interface XPUB) en utilisant par exemple le protocole Protobuff (Protocol Buffer Format) qui est un format d'échange binaire pour sérialiser des données structurées.
  • Dans des exemples, le système de communication unifié peut être asynchrone, comme par exemple avec ZeroMQ©. Le système de communication unifié peut être non-bloquant, c'est-à-dire qu'un message ne peut pas empêcher d'autres messages d'être transmis. Plus généralement, le système de communication unifié non-bloquant permet au micro-service de réaliser d'autres tâches même si un message envoyé est en attente, ou encore une réponse attendue à un message n'est pas parvenue au micro-service. Le système de communication unifié peut être également point à multipoint ou bien multipoint à point ; un micro-service peut donc envoyer des messages à plusieurs micro-services, et inversement plusieurs micro-services peuvent envoyer des messages à un micro-service.
  • Le sous-service de messagerie est maintenant discuté. Dans des exemples, le sous-service de messagerie peut comprendre une ou plusieurs des fonctions discutées dans les exemples qui suivent, et dans un exemple il les comprend toutes. Le sous-service de messagerie peut comprendre une fonction de souscription à un ou plusieurs sujets de la messagerie. Un sujet de messagerie peut être déterminé par, mais n'est pas limité à, un identifiant de sujet comme par exemple un nom de mesure venant d'un micro-service interfacé avec un ou des capteurs externes comme par exemple 'Température' ou 'Courant'. Un identifiant de sujet peut également être une catégorie de message utile au fonctionnement du système lui-même comme par exemple 'Alarme'.
  • Dans un exemple, la fonction de souscription comprend la souscription à un ou plusieurs sujets de la messagerie, la mise en forme et l'écriture des données contenues dans les messages associés audit un ou plusieurs sujets de messagerie souscrits dans une base de données adaptée pour le stockage de données horodatées. La base de données peut être une base de données locale, c'est-à-dire que chaque micro-service stocke les données sur une base de données qui est localisée sur l'ordinateur qui exécute le micro-service. La base de données peut être une base de données distante, par exemple localisée sur un ordinateur différent de celui qui exécute le micro-service.
  • Le sous-service de messagerie peut comprendre une fonction de publication dans un sujet de la messagerie. Cette fonction de publication permet au micro-service d'envoyer des messages pour un sujet de messagerie.
  • Le sous-service de messagerie peut comprendre une fonction d'envoi de requête via la messagerie. Une requête est un message qui attend une réponse d'un ou plusieurs autres micro-services. De façon générale, une requête est un langage informatique utilisé pour accéder à des données, par exemple des données d'une base de données ou d'autres systèmes d'information. Dans un exemple, le sous-service de messagerie comprend également une fonction de réponse à une requête reçue via la messagerie. Cette fonction permet donc auxdits micro-services de répondre à la requête émise par l'un des micro-services.
  • Dans des exemples, l'ensemble des communications interservices, c'est-à-dire l'envoi de messages entre les différents sous-services des micro-services de la plateforme, passent par le sous-service de messagerie. Dans un exemple, une exception peut concerner le cas où la plateforme de services comprend une interface permettant d'interagir avec un utilisateur. L'interface est fournie par un micro-service qui utilise uniquement des données locales pour de meilleures performances, notamment pour offrir une meilleure réactivité à l'utilisateur. Dans un autre exemple, une interface web locale est fournie à un utilisateur par un micro-service, et l'interface web vient lire les informations dans une base de données locale de l'ordinateur qui exécute ce micro-service, sans passer par le système de messagerie.
  • Un micro-service est un élément logiciel de la plateforme qui comprend un sous-service implémentant une fonction métier et un sous-service de messagerie. Les sous-services implémentant la fonction métier réalisent les services d'un système industriel, et le sous-service de messagerie offre aux sous-services implémentant une fonction métier des moyens de communiquer entre eux, en s'appuyant notamment sur le système de communication unifié. On rappelle qu'un service est une fonctionnalité ou une partie de fonctionnalité mise à disposition par un composant logiciel pour assurer une tâche particulière. Afin de limiter le nombre de micro-services gérés par la plateforme, et dans des exemples, un ou plusieurs services supplémentaires peuvent être fournis par le système d'exploitation d'un ou plusieurs ordinateurs exécutant un ou plusieurs micro-services. En d'autres termes, des services supplémentaires qui sont offerts par les ordinateurs exécutant les micro-services peuvent être exploités par la plateforme selon l'invention. Par exemple, l'utilitaire open source "monit" (version 5 ou ultérieure), qui rentre dans la catégorie des daemons, peut être en charge de surveiller le micro-service et l'ordinateur qui exécute le micro-service. Cet utilitaire peut mesurer les ressources de l'ordinateur (processeur, mémoire, disques, réseau...) utilisées par le micro-service, être un chien de garde (watchdog en anglais) qui détermine les processus qui sont gelés.
  • Dans des exemples, les services supplémentaires peuvent être sélectionnés parmi les services suivants. On comprend que ces exemples ne sont pas limitatifs et que tout service pouvant être fourni par un système d'exploitation peut être un service supplémentaire. Ainsi, un service supplémentaire peut être un service d'initialisation du système d'exploitation qui commande l'exécution de plusieurs programmes au démarrage du système d'exploitation. Par exemple, le programme init dans les systèmes UNIX/LINUX a un rôle de processus principal du démarrage qui consiste à commander l'exécution de plusieurs programmes. Un service supplémentaire peut être un service de démarrage des micro-services ; par exemple un service qui séquence le démarrage de tous les micro-services selon un certain ordre, et qui vérifie leur bon démarrage. Un service supplémentaire peut être un service de stockage et de gestion centrale des messages de journalisation dans une base de données.
  • Également dans le but de limiter le nombre de micro-service gérés par la plateforme, et dans des exemples, un ou plusieurs daemons exécutés par un ordinateur peuvent être utilisés. Un daemon est un type de programme informatique, un processus ou un ensemble de processus qui s'exécute en arrière-plan plutôt que sous le contrôle direct d'un utilisateur. Les daemons sont souvent démarrés lors du chargement du système d'exploitation, et servent en général à répondre à des requêtes du réseau, à l'activité du matériel ou à d'autres programmes en exécutant certaines tâches. Un daemon peut ainsi réaliser au moins une des tâches suivantes, (i) Le daemon détermine si un ou plusieurs micro-services fonctionnent correctement, (ii) Le daemon peut redémarrer un micro-service si celui-ci ne fonctionne pas correctement, (iii) Le daemon peut surveiller le bon fonctionnement du système d'exploitation de l'ordinateur exécutant le micro-service, (iv) Le daemon peut redémarrer le système d'exploitation si celui-ci ne fonctionne pas correctement.
  • Les micro-services sont des programmes exécutés par un ordinateur. Le terme ordinateur désigne un système de traitement de l'information programmable qui fonctionne par la lecture d'un ensemble d'instructions, organisées en programmes, qui lui font exécuter des opérations logiques et arithmétiques. Un ordinateur comprend au moins une unité de calcul (par exemple une CPU) et une mémoire, en communication avec l'unité de calcul, qui stocke le programme d'ordinateur.
  • La figure 5 montre un exemple d'un ordinateur permettant d'exécuter un micro-service selon l'invention, et pouvant être compris dans une plateforme selon l'invention. L'ordinateur de l'exemple comprend une unité de traitement centrale (CPU) 1010 connectée à un bus de communication interne 1000, une mémoire vive (RAM) 1070 également connectée au bus. La mémoire vive est donc en communication avec l'unité de traitement centrale. L'ordinateur peut être doté d'une unité de traitement graphique (GPU) 1110 qui peut être associée à une mémoire vidéo à accès sélectif 1100 connectée au bus. La RAM vidéo 1100 est également connue dans la technique sous le nom de mémoire tampon d'images (framebuffer en anglais). L'ordinateur peut comprendre un contrôleur de dispositif de mémoire de masse 1020 ; le contrôleur gère les accès à un dispositif de mémoire de masse, tel qu'un disque dur 1030. Les dispositifs de mémoire de masse sont adaptés à la réalisation concrète d'instructions de programmes informatiques et incluent toutes les formes de mémoire non volatile, y compris à titre d'exemple des dispositifs de mémoire à semi-conducteurs, tels que EPROM, EEPROM et dispositifs de mémoire flash ; des disques magnétiques tels que des disques durs internes et des disques amovibles ; disques magnéto-optiques ; et disques CD-ROM 1040. Tout ce qui précède peut-être complété ou incorporé dans des ASIC spécialement conçus (circuits intégrés spécifiques à une application). L'ordinateur peut comprendre une carte réseau 1050 qui gère les accès à un réseau 1060. L'ordinateur client peut également inclure un dispositif haptique 1090 tel qu'un dispositif de commande de curseur, un clavier ou similaire.
  • L'ordinateur peut stocker sur sa mémoire vive, ou bien sur une mémoire de masse un ou plusieurs programmes d'ordinateur. Le programme d'ordinateur peut comprendre des instructions exécutables par l'unité de calcul de l'ordinateur, les instructions comprenant des moyens pour amener l'ordinateur ci-dessus à implémenter tout ou partie de la plateforme selon l'invention. Le programme peut être enregistrable sur n'importe quel support de stockage de données, y compris la mémoire vive et/ou la mémoire de masse du système. Le programme peut par exemple être mis en œuvre dans des circuits électroniques numériques, ou dans du matériel informatique, des micrologiciels, des logiciels ou des combinaisons de ceux-ci. Le programme peut être mis en œuvre sous la forme d'un appareil, par exemple un produit incorporé de manière tangible dans un dispositif de stockage lisible par machine pour une exécution par un processeur programmable. Le processeur (l'unité de traitement centrale) peut ainsi être programmé et couplé pour recevoir des données et des instructions provenant d'un système de stockage de données, d'au moins un dispositif d'entrée et d'au moins un dispositif de sortie et pour transmettre des données et des instructions à un tel système. Le programme d'application peut être implémenté dans un langage de programmation procédural ou orienté objet de haut niveau, ou en langage assembleur ou machine si nécessaire. Dans tous les cas, le langage peut être un langage compilé ou interprété. Le programme peut être un programme d'installation complet ou un programme de mise à jour. L'application du programme sur le système entraîne dans tous les cas des instructions pour l'implémentation de la plateforme.
  • La plateforme peut être distribuée, c'est-à-dire qu'elle est implémentée (exécutée) par plusieurs ordinateurs, et non par un seul. On comprend alors que le programme de la plateforme peut alors être constitué de plusieurs sous-programmes exécutés par plusieurs machines, formant ainsi la plateforme de services selon l'invention. Lorsque la plateforme est implémentée sur plusieurs ordinateurs, chaque ordinateur exécute au moins un micro-service. La figure 1 précédemment discutée illustre un exemple de plateforme pouvant être exécutée par plusieurs ordinateurs.
  • Dans des exemples, chaque micro-service exécuté par un ordinateur peut l'être comme un unique processus. Chaque sous-service du micro-service peut être exécuté comme un fil d'exécution. Un fil d'exécution (terme français pour « thread », terme et définition normalisés par ISO/CEI 2382-7:2000) est similaire à un processus à la différence qu'un processus possède sa propre mémoire qu'il ne partage pas avec les autres processus tandis que les fils d'exécution d'un même processus se partagent sa mémoire. Le « multi-usage de fils d'exécution » des sous-services d'un micro-service participe à la performance du micro-service car les fils d'exécution sont exécutés de manière concurrente, en parallèle.
  • La figure 2 illustre un exemple de modèle type de micro-service selon l'invention. Sur la partie gauche de la figure 2, un modèle d'un micro-service est représenté. Le modèle comprend trois groupes de sous-services. Un premier groupe représente les sous-services principaux qui sont la fonctionnalité principale (c'est-à-dire attendue) du micro-service. Un deuxième groupe fournit des sous-services utilitaires pour la gestion du micro-service. Enfin, un troisième groupe représente le sous-service de Communication pour permettre au micro-service de communiquer avec d'autres micro-services, et donc d'être intégré à la plateforme.
  • Toujours en référence à la figure 2, et maintenant sur la partie de droite de la figure, un exemple de structure générique normalisée est représenté. La structure normalisée du micro-service (aussi appelée micro-service template en anglais) est définie par le modèle. Tous les micro-services sont basés sur cette structure normalisée. Le groupe le plus haut comprend un ou plusieurs sous-services qui représentent la fonction métier (métier 1 et métier 2 sur la figure). Le groupe du milieu comprend cinq fonctions de gestion du micro-service. Parmi ces fonctions, il y a une fonction de journalisation des événements liés au fonctionnement du micro-service (nommée System logs), une fonction de journalisation des événements concernant la fonction métier (nommée Operational logs ou Op log), une fonction de gestion des alarmes émises et reçues par le micro-service (nommée Alarmes), une fonction de gestion de configuration du micro-service (nommée Config), et une fonction de sauvegarde et de restauration de l'état courant du micro-service (nommée Context). Le groupe du bas montre les fonctions que comprend le sous-service de messagerie. Le sous-service de messagerie comprend une fonction de publication dans un ou plusieurs sujets de la messagerie (nommée Publish-subscribe), une fonction d'envoi de requête via la messagerie (nommée Request-Reply). Il peut comprendre de plus (non représenté sur la figure 2) une fonction de souscription à un ou plusieurs sujets de la messagerie, une fonction de réponse à une requête reçue via la messagerie. On comprend que les messages envoyés/reçus comprenant une métadonnée TYPE ou encore AUDIT seront notamment traités par les fonctions de journalisation.
  • Un exemple d'implémentation du micro-service est discuté. L'implémentation de la structure générique normalisée peut être réalisée en langage de programmation orientée objet, par exemple en C++. La fonction métier peut être implémentée par un sous-programme d'ordinateur (nommé Main Program sur la figure) qui, lorsqu'il est exécuté par l'ordinateur, réalise la fonction métier. Les cinq fonctions de gestion du micro-service peuvent être implémentées par trois sous-programmes d'ordinateur. Le premier sous-programme (nommé Syslog clients API) implémente les deux fonctions de journalisation « System logs » et « Operational logs ». Le deuxième sous-programme (nommé Alarm lib) implémente la fonction « Alarm Management ». Un troisième sous-programme (nommé « Protected directory in OS filesystem) peut implémenter les fonctions « Config Handler » et « Context handler ». La fonction du troisième sous-programme peut être fournie par le système d'exploitation de l'ordinateur exécutant le micro-service. On comprend donc que des sous-services d'un micro-service peuvent être ceux proposés par le système d'exploitation de l'ordinateur exécutant le micro-service. Le service de gestion de système de fichiers du système d'exploitation peut stocker et gérer dans une base de données les messages d'alarmes envoyés/reçus par le micro-service ainsi que le/les états courants du micro-service. Enfin, les fonctions du sous-service de messagerie peuvent être implémentées à l'aide de l'API ZeroMQ© discutées en référence avec la figure 4.
  • Le modèle type de micro-service selon l'invention offre donc un accès à une messagerie normalisée commune à tous les micro-services de la plateforme via un système de communication unifié qui peut utiliser des sockets pour la communication inter-processus, soit en local au sein du même système d'exploitation d'un ordinateur, soit via un réseau et un protocole réseau (par exemple TCP/IP), ou encore une combinaison des deux. La messagerie commune peut utiliser un schéma de communication asynchrone « Publication-Abonnement ». Chaque micro-service peut émettre des données en publiant dans la messagerie commune, sans avoir besoin de savoir si la donnée sera consommée ou pas. Chaque micro-service peut recevoir des données en s'abonnant à une donnée publiée par un autre micro-service, sans que le publieur n'ait besoin d'être informé. La communication peut donc être asynchrone, non-bloquante, point-à-multipoint et multipoint-à-point.
  • La plateforme de services selon l'invention est apte à gérer des services d'un système industriel, Parmi des exemples d'utilisation de la plateforme, cette dernière implémente un système de gestion d'une batterie et de ses équipements auxiliaires. Une batterie est un terme générique désignant un ensemble d'accumulateurs électriques, appelés éléments, reliés entre eux de façon à créer un générateur électrique de tension, de puissance et de capacité désirée. Une batterie convertit l'énergie électrique accumulée pendant la phase de charge en énergie chimique. L'énergie chimique est constituée par des composés électro-chimiquement actifs disposés dans l'élément. L'énergie électrique est restituée par conversion de l'énergie chimique en énergie électrique pendant la phase de décharge. Les électrodes, disposées dans un contenant, sont connectées électriquement à des bornes de sortie de courant qui assurent une continuité électrique entre les électrodes et un consommateur électrique auquel l'élément est associé. La batterie est formée d'une ou plusieurs branches montées électriquement en parallèle. Chaque branche comprend un ou plusieurs modules montés électriquement en série, et chaque module comprenant un ou plusieurs éléments électrochimiques montés électriquement en série ou en parallèle.
  • La figure 6 est un exemple de configuration d'une batterie dans laquelle N éléments électrochimiques (Cell1, Cell2,..., CelIN) sont connectés en série et disposés ensemble dans une même enceinte pour former un premier module (Module1). De manière similaire, N éléments électrochimiques sont connectés en série et disposés dans une xième enceinte pour former un xième module (Modulex). Les X modules sont connectés en série pour former une batterie (Bat). Les X modules constituent une branche du circuit, appelé ESSU (acronyme anglais de Energy Storage System Unit). Les éléments ne sont pas non plus nécessairement connectés en série mais peuvent aussi être connectés en parallèle. Il est également envisageable de connecter certains éléments entre eux en parallèle pour obtenir plusieurs associations d'éléments en parallèle puis de connecter ces associations d'éléments en série. De même, la batterie peut comprendre un nombre quelconque de modules, dans une configuration non nécessairement limitée à une connexion en série. Par exemple, la batterie peut comprendre p branches parallèles, chaque branche parallèle comprenant au moins un module constitué d'au moins un élément.
  • Les équipements auxiliaires d'une batterie sont des équipements participant soit à la sûreté, soit à la sécurité, soit aux performances, soit au fonctionnement de la batterie. Dans des exemples, au moins un équipement auxiliaire de la batterie est sélectionné parmi un système de détection et d'extinction d'incendie qui prévient la propagation du feu si un ou plusieurs modules électrochimiques prennent feu, un système de climatisation pour maintenir la batterie dans des conditions de température assurant son fonctionnement optimal, un système de surveillance des accès physiques à la batterie (par exemple le local dans lequel la batterie est entreposée), ou encore un système de mesure de la puissance électrique délivrée et/ou reçue par la batterie.
  • Chaque équipement auxiliaire est géré par un ou plusieurs micro-services de la plateforme en charge d'effectuer une fonction métier. Par exemple, le micro-service qui gère le système d'extinction d'incendie peut notamment avoir pour fonction métier de mesurer la température autour de la batterie et d'envoyer des alarmes en cas d'incendie à un micro-service offrant une interface utilisateur permettant de tenir informé un opérateur d'un problème sur la batterie. Par exemple, le micro-service gérant le système de climatisation peut avoir pour fonction métier de vérifier le bon fonctionnement de la climatisation et d'envoyer des alarmes en cas de défaillance. La fonction métier du micro-service associé au système de surveillance des accès physiques peut être d'envoyer des messages ayant un niveau de criticité dépendant des personnes pénétrant dans le local où est entreposée la batterie. Le système de mesure de la puissance électrique peut être géré par un micro-service dont la fonction métier est de restituer à l'opérateur la consommation de la puissance électrique aux bornes de la batterie : par exemple le micro-service fournit un service web ainsi que calculer l'énergie accumulée par la batterie. On comprendra que plusieurs équipements auxiliaires peuvent être gérés par un ou plusieurs mêmes micro-services ; dit autrement, la gestion de plusieurs équipements auxiliaires peut être regroupée dans un ou plusieurs mêmes micro-services.
  • On comprend que la plateforme de service selon l'invention peut être utilisée pour gérer des containers qui sont des assemblages de batterie. La plateforme peut gérer les différentes branches des batteries du container ainsi que les équipements auxiliaires. La plateforme permet par exemple d'envoyer des données de fonctionnement vers un micro-service de journalisation. Notamment, la plateforme de services selon l'invention permet d'agréger les données obtenues sur plusieurs équipements en les envoyant sur un micro-service de journalisation des données, ou encore sur un micro-service de stockage des données dans une base de données. Ainsi, la plateforme peut gérer plusieurs batteries, containers et offrir une vue agrégée des paramètres communs à ces équipements. Dans un exemple, chaque batterie d'un container comprend un micro-service de mesure de la puissance électrique instantanée délivrée par la batterie, l'ensemble des batteries d'un ou plusieurs containers envoyant les données vers un micro-service d'agrégation des données permettant à un opérateur de visualiser les données agrégées, par exemple à l'aide un service web de ce même micro-service d'agrégation des données des containers.
  • On comprend qu'une plateforme de service selon l'invention permet de faciliter la gestion d'une batterie et de ses équipements auxiliaires. Ainsi des fonctionnalités de gestion des batteries qui sont traditionnellement implémentées dans les BMS (Battery Management System, organes contribuant à la gestion des batteries), peuvent être déportées à l'extérieur des batteries afin d'en simplifier la conception et l'utilisation. Notamment, des calculs d'état de charge (SoC) et d'état de santé (SoH) peuvent être faits avec une plus grande précision grâce à la puissance de calcul beaucoup plus élevée de la plateforme de service par rapport aux BMS traditionnels.
  • Dans des exemples, on peut former un ensemble comprenant une ou plusieurs branches de batterie montées en parallèle formant une batterie, chaque branche de la batterie comprenant un ou plusieurs modules montés en série, chaque module comprenant un ou plusieurs éléments électrochimiques. L'ensemble comprend également un ou plusieurs ordinateurs, et une plateforme de service selon l'invention qui est exécutée par les ordinateurs de l'ensemble. Les micro-services de la plateforme de service implémentent des fonctions métiers de gestion de la batterie et de ses équipements auxiliaires : par exemple pour chaque fonction de gestion d'une batterie et pour chaque interface d'équipement auxiliaire de la batterie. L'ensemble comprend également un ou plusieurs organes de contrôle-commande des branches, qui exécutent des ordres de connexion/déconnexion et qui fournissent des mesures des paramètres des branches, des modules et des éléments électrochimiques. Un organe de contrôle-commande permet de superviser l'état électrique d'une branche, par exemple d'ouvrir ou de fermer le circuit de la branche.
  • Dans des exemples, au moins une des fonctions métier peut être sélectionnée parmi les suivantes. La première fonction métier est de déterminer si une ou plusieurs branches de la batterie sont connectées ou déconnectées au réseau électrique, c'est-à-dire à la sortie de la batterie. Une autre fonction métier est de calculer des consignes de courant applicables à la charge et à la décharge de la batterie. Une troisième fonction métier est de calculer le niveau de charge (SoC, acronyme anglais de State of Charge) de la batterie ; le micro-service implémente donc au moins un algorithme permettant de mesurer ou bien d'estimer le SoC. Une quatrième fonction est de calculer le niveau de santé (SoH, acronyme anglais de State of Health) ou niveau de vie de la batterie ; le micro-service implémente donc au moins un algorithme permettant de mesurer ou bien d'estimer le SoH de la batterie.
  • Dans un exemple, un niveau de charge (SoC) et un état de santé (SoH) pour une branche du circuit (ESSU) sont calculés par le BMS, et un niveau de charge (SoC) et un état de santé (SoH) par batterie sont calculés par la plateforme de micro-services.
  • Dans des exemples, l'ensemble comprend deux ou plus ensembles de branches de batteries montées en parallèle formant respectivement deux ou plus batteries. Cet ensemble avec au moins deux batteries peut comprendre un micro-service implémentant une fonction métier d'agrégation des données d'une ou plusieurs des autres fonctions métier précédemment citées. En d'autres termes, le micro-service d'agrégation agrège les données qui concernent chaque type de fonction métier. On comprend que l'agrégation des données peut être réalisée différemment selon la fonction métier, et qu'il peut y avoir un micro-service d'agrégation par fonction métier.
  • Dans des exemples, l'ensemble peut comprendre un ou plusieurs micro-services pouvant envoyer des données échangées via le système de communication unifié en direction d'un système de stockage distant pour y être stockées. Les données échangées peuvent par exemple être sélectionnées à l'aide d'une ou plusieurs des métadonnées présentes dans les messages transportant les données échangées. Le système de stockage peut être, mais n'est pas limité à, une base de données, un système de fichiers, un ou plusieurs serveurs de stockage formant un cloud. Le système de stockage distant peut être couplé avec un système d'apprentissage automatique pouvant effectuer son apprentissage sur les données stockées. Les données reçues sont donc autant d'observations permettant de construire un modèle, par exemple un modèle de l'usure de la batterie.
  • Dans des exemples, la plateforme de service de l'ensemble comprend en outre un micro-service de mise à jour des autres micro-services. Dans un exemple, le micro-service de mise à jour peut envoyer des requêtes aux autres micro-services afin de connaître leurs versions respectives, et en fonction des réponses aux requêtes, il peut déterminer quels micro-services doivent être mis à jour. Dans un exemple, la plateforme de micro-services comprend en outre un micro-service de mise à jour des logiciels des organes de contrôle-commande des branches. La décision de mettre à jour ou pas un organe de contrôle-commande peut être réalisée de la même façon que pour la mise à jour des micro-services.

Claims (15)

  1. Plateforme de services, implémentée par un ou plusieurs ordinateurs, de gestion d'une batterie et de ses équipements auxiliaires, comprenant :
    • un ou plusieurs micro-services (42, 44), chaque micro-service ayant une structure générique normalisée comprenant :
    ∘ un sous-service implémentant une fonction métier, chaque fonction métier définissant un rôle spécifique rendu par le micro-service dans la gestion de la batterie et de ses équipements auxiliaires ;
    ∘ un sous-service de messagerie ;
    • un système de communication unifié pour un échange de données et de messages,
    dans laquelle chaque micro-service comprend en outre au moins une fonction de gestion du micro-service, l'une des au moins une fonction de gestion du micro-service étant une fonction de gestion de la configuration du micro-service,
    dans laquelle le système de communication unifié comprend :
    • l'utilisation, de sockets pour une communication inter-micro-service en local ou via un réseau TCP/IP, ce choix étant configuré par la fonction de gestion de la configuration du micro-service.
  2. Plateforme de services selon la revendication 1, dans laquelle chaque micro-service comprend en outre :
    ∘ une interface utilisateur et/ou machine.
  3. Plateforme de services selon l'une quelconque des revendications précédentes, dans laquelle ladite au moins une fonction de gestion est sélectionnée parmi :
    • une fonction de journalisation du système exécutant le micro-service et/ou du micro-service exécuté ;
    • une fonction de gestion d'alarme(s) émise(s) et/ou reçue(s) par le micro-service ;
    • une fonction de sauvegarde et de restauration d'un état courant du micro-service.
  4. Plateforme de services selon la revendication 3, comprenant en outre un service de centralisation des journaux sur lequel sont stockés des messages de journalisation mis en forme et envoyés par la fonction de journalisation.
  5. Plateforme de services selon l'une quelconque des revendications précédentes, dans laquelle les sockets pour la communication inter- micro-service utilisent un mandataire sans état qui met en relation un micro-service publiant un ou des messages concernant un ou plusieurs sujets de la messagerie avec un ou plusieurs micro-services ayant souscrit auxdits un ou plusieurs sujets de la messagerie.
  6. Plateforme de services selon l'une quelconque des revendications précédentes, dans laquelle le sous-service de messagerie comprend :
    • une fonction de souscription à un ou plusieurs sujets de la messagerie ;
    • une fonction de publication dans un sujet de la messagerie ;
    • une fonction d'envoi de requête via la messagerie ;
    • une fonction de réponse à une requête reçue via la messagerie.
  7. Plateforme de services selon la revendication 6, dans laquelle la fonction de souscription comprend souscrire à un ou plusieurs sujets du sous-service de messagerie, mettre en forme et écrire les données contenues dans les messages associés audit un ou plusieurs sujets souscrits dans une base de données locale adaptée pour le stockage de données horodatées.
  8. Plateforme selon l'une quelconque des revendications précédentes, dans laquelle le système de communication unifié est asynchrone, non-bloquant, et point à multipoints ou multipoints à point.
  9. Plateforme de services selon l'une quelconque des revendications précédentes, dans laquelle un ou plusieurs services supplémentaires sont fournis par le système d'exploitation d'un ou plusieurs ordinateurs exécutant un ou plusieurs micro-services.
  10. Plateforme de services selon l'une quelconque des revendications précédentes, dans laquelle chaque micro-service est exécuté comme un unique processus et chaque sous-service du micro-service est exécuté comme un thread.
  11. Ensemble comprenant :
    • une ou plusieurs branches de batterie montées en parallèle formant une batterie, chaque branche de la batterie comprenant un ou plusieurs modules montés en série, chaque module comprenant un ou plusieurs éléments électrochimiques ;
    • au moins un équipement auxiliaire de la batterie;
    • un ou plusieurs ordinateurs ;
    • une plateforme de services selon l'une quelconque des revendications 1 à 10 implémentée par lesdits un ou plusieurs ordinateurs ; et
    • un ou plusieurs organes de contrôle-commande des branches, qui exécutent les ordres de connexion/déconnexion et qui fournissent des mesures des paramètres des branches, des modules et des éléments électrochimiques.
  12. Ensemble selon la revendication 11, dans lequel une ou plusieurs des fonctions métier sont sélectionnées parmi :
    • la détermination de la connexion / déconnexion au réseau électrique d'au moins une branche de la batterie ;
    • le calcul des consignes de courant applicables à la charge et à la décharge de la batterie ;
    • le calcul du niveau de charge de la batterie ;
    • le calcul du niveau de vie de la batterie.
  13. Ensemble selon l'une des revendications 11 ou 12, comprenant en outre :
    • deux ou plus ensembles de branches de batterie montées en parallèle formant respectivement deux ou plus batteries ;
    • et dans lequel la plateforme de service comprend en outre un micro-service implémentant une fonction métier d'agrégation des données d'une ou plusieurs des autres fonctions métier.
  14. Ensemble selon l'une quelconque des revendications 11-13, dans lequel la plateforme de service comprend en outre un ou plusieurs micro-services pouvant envoyer des données échangées sur le système de communication unifié en direction d'un système de stockage distant pour y être stockées, le système de stockage distant étant en outre couplé avec un système d'apprentissage automatique pouvant effectuer son apprentissage sur les données stockées.
  15. Ensemble selon l'une des revendications 11-14, dans lequel la plateforme de service comprend en outre un micro-service de mise à jour des autres micro-services.
EP20845188.0A 2019-12-13 2020-12-11 Plateforme de gestions de micro services concernant la gestion d'une batterie Active EP4074011B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1914436A FR3104866B1 (fr) 2019-12-13 2019-12-13 Plateforme de services pour les systèmes de contrôle-commande industriels et son procédé d’utilisation.
PCT/FR2020/052404 WO2021116633A1 (fr) 2019-12-13 2020-12-11 Plateforme de gestions de micro services concernant la gestion d'une batterie

Publications (2)

Publication Number Publication Date
EP4074011A1 EP4074011A1 (fr) 2022-10-19
EP4074011B1 true EP4074011B1 (fr) 2024-08-07

Family

ID=72266328

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20845188.0A Active EP4074011B1 (fr) 2019-12-13 2020-12-11 Plateforme de gestions de micro services concernant la gestion d'une batterie

Country Status (4)

Country Link
US (1) US12443165B2 (fr)
EP (1) EP4074011B1 (fr)
FR (1) FR3104866B1 (fr)
WO (1) WO2021116633A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220222129A1 (en) * 2021-01-12 2022-07-14 GM Global Technology Operations LLC System for parallel processing middleware node application algorithms using threads
CN113704755B (zh) * 2021-07-13 2024-06-28 奇安信科技集团股份有限公司 一种文件检测方法、装置、电子设备、程序及存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG11201802860SA (en) * 2016-01-11 2018-07-30 Equinix Inc Architecture for data center infrastructure monitoring
GB2565656B (en) 2016-02-25 2020-04-15 Intel Corp Platform for computing at the mobile edge
FR3057378B1 (fr) * 2016-10-07 2022-03-18 Worldline Systeme de detection de fraude dans un flux de donnees
DE102016124348A1 (de) * 2016-12-14 2018-06-14 Codewrights Gmbh System und Mikroservice zum Überwachen einer Anlage der Prozessautomatisierung
US20180295187A1 (en) * 2017-04-11 2018-10-11 Ashok Ashok Sabata IoT Solution to Monitor Controlled Environments
CN107612959A (zh) 2017-07-21 2018-01-19 哈尔滨工程大学 一种基于云微服务自管理的云服务平台
US12224603B2 (en) * 2020-06-02 2025-02-11 Inventus Power, Inc. Mode-based disabling of communication bus of a battery management system
CA3238747A1 (fr) * 2021-11-23 2023-06-01 Charles Howard CELLA Plateformes de transaction dotees de systemes comprenant des ensembles d'autres systemes
US11444338B1 (en) * 2021-11-30 2022-09-13 Knoetik Solutions, Inc. Smart battery system

Also Published As

Publication number Publication date
FR3104866B1 (fr) 2023-11-24
US20230011254A1 (en) 2023-01-12
WO2021116633A1 (fr) 2021-06-17
EP4074011A1 (fr) 2022-10-19
FR3104866A1 (fr) 2021-06-18
US12443165B2 (en) 2025-10-14

Similar Documents

Publication Publication Date Title
US9208215B2 (en) User classification based on data gathered from a computing device
EP4074011B1 (fr) Plateforme de gestions de micro services concernant la gestion d'une batterie
US11449120B2 (en) Centralized power management of wireless devices
Diaconescu et al. Automatic performance management in component based software systems
CN113971098A (zh) 一种RabbitMQ消费管理方法及系统
Nzanzu et al. Fedargos-v1: A monitoring architecture for federated cloud computing infrastructures
WO2024263452A1 (fr) Exploitation d'états de santé d'instances de dépendance pour analyser une cause profonde d'interruption
CN115619170A (zh) 电量负荷调整方法、装置、设备、计算机介质和程序产品
US10659326B2 (en) Cloud computing network inspection techniques
US11748138B2 (en) Systems and methods for computing a success probability of a session launch using stochastic automata
Matić et al. Health monitoring and auto-scaling RabbitMQ queues within the smart home system
US20240193327A1 (en) Digital twinning data simulator
CN115865881A (zh) 一种基于mqtt的消息交互方法、系统、设备及介质
Daradkeh et al. Real time metering of cloud resource reading accurate data source using optimal message serialization and format
CN115695453A (zh) 一种提高镜像仓库稳定性的方法、装置、设备及介质
Surianarayanan et al. Cloud Monitoring and Observability
EP2961032B1 (fr) Procédé et dispositif pour gérer le partage de ressources entre équipements producteur et/ou consommateur
US12450386B2 (en) Intelligent feature control
EP3900386A1 (fr) Procédé de gestion d'un dispositif de communication de données et dispositif pour la mise en oeuvre du procédé
Koh-Dzul et al. Improving ESB Capabilities through Diagnosis Based on Bayesian Networks and Machine Learning.
Hadian Power Estimation Framework to Ensure the Reliability of Edge Devices in Internet-of-Things Applications
Nashaat et al. Dynamic machine learning approach for workload prediction in cloud environments
Sidhanta et al. Managing a cloud for multi-agent systems on ad-hoc networks
FR2984054A1 (fr) Procede et programme d'ordinateur de gestion externalisee et centralisee de pannes dans un cluster comprenant des equipements a haute disponibilite
CN118138431A (zh) 一种电力系统传感器适配方法、装置、设备及存储介质

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: 20220713

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)
P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230524

REG Reference to a national code

Ref country code: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ref country code: DE

Ref legal event code: R079

Ref document number: 602020035506

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: H04L0067125000

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 67/025 20220101ALN20240220BHEP

Ipc: H01M 10/48 20060101ALI20240220BHEP

Ipc: H01M 10/42 20060101ALI20240220BHEP

Ipc: H04L 67/125 20220101AFI20240220BHEP

INTG Intention to grant announced

Effective date: 20240318

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

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

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602020035506

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: FRENCH

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241107

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1712150

Country of ref document: AT

Kind code of ref document: T

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241209

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241108

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241207

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241107

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241107

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241209

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241107

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241207

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20241108

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602020035506

Country of ref document: DE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

26N No opposition filed

Effective date: 20250508

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20241231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241211

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20240807

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20251211

Year of fee payment: 6

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20251219

Year of fee payment: 6

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241211

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20251229

Year of fee payment: 6

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20241211

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20251223

Year of fee payment: 6

PGRI Patent reinstated in contracting state [announced from national office to epo]

Ref country code: IT

Effective date: 20250430