System and computer-implemented method for updating and / or updating at least one of a plurality of services

Abstract

The invention relates to a computer-implemented method for upgrading and / or updating at least one of a plurality of services executing on a computer-implemented system (T) in which the plurality of services implement a joint technology application, wherein the computer-implemented method is configured to: a. Deploy, on the system, at least one updated version (Vx) of at least one service that needs to be updated or upgraded while maintaining, on the system, a current version of the service wherein the updated version of the at least one service is prevented from controlling a particular portion of the federated technology application; b. Deploying and operating a monitoring module (A2K) for agreement of communications (IN) between a plurality of services and for analysing dependencies between applications of said plurality of services with respect to their runtime, said dependencies being derived from data generated by the agreement of communications and said dependencies being derived from data generated by the agreement of communications; wherein the agreement communication contains the time at which the service communicates with other components of the system, and wherein dependencies between all applications of the service result in a time-ordered sequence of service activities classified by agreement time, whereby the service activities are separated from each other by one or more inactivity sequences of all services; c. Determining a process state (PSt) of the service suitable for updating and / or upgrading each at least one service by following criteria inferred from the dependencies to identify a suitable time slot for updating and / or upgrading at least one service, where the suitable time slot means that all services are inactive at the same time; d. At a slot of the identified slots, disabling control (Ctr) of the current version of the service within the current technology application; and e. Enabling control (Ctr) of the deployed updated version of the service within the current technology application.

Description

Technical Field

[0001] The present invention relates to a system and a computer-implemented method for upgrading and / or updating at least one service of a plurality of services. Background Art

[0002] In software development, there is a trend towards updating and upgrading smaller parts of the system, which provides services more frequently in shorter cycles.

[0003] Multiple such services implement joint (technical) applications to run specific technical solutions.

[0004] For example, the joint application may be used to read data from one or more sensors and / or to control / manipulate one or more actuators in a technical system. The technical system may be a manufacturing / automation or energy system or other technical installation.

[0005] A single software application can be composed of many smaller services (so-called microservices) that are loosely coupled and independently deployable.

[0006] As a system consists of more and more components that can be updated / upgraded individually, the number of upgrades increases.

[0007] For every update / upgrade, it must be verified that it can be effectively used in the field (deployed for production). Here are the relevant questions:

[0008] It is difficult to determine whether a newly developed service version (update / upgrade) is good enough to be accepted or is better than the current service and should be used in place of the already implemented service. The problem is that laboratory testing may not be performed under conditions close enough to real-world operating conditions or last long enough to gain the required confidence.

[0009] From KOZIOLEK HEIKO et al.: "Dynamic Updates of Virtual PLCs Deployed asKubernetes Microservices", 26August 2021(2021-08-26),16TH EUROPEAN CONFERENCE-COMPUTER VISION-ECCV 2020,CORNELL UNIVERSITY LIBRARY,201OLINE LIBRARY CORNELLUNIVERSITY ITHACA,NY 14853,PAGE(S)3-19,XP047606262 Page 3-19, it is known that each service is stopped and migrated to the updated service instance along with its state.

[0010] It is unacceptable and very costly for critical systems to be out of service too frequently or for too long.

[0011] For systems that need to operate safely, any changes in the system need to be verified in the field to ensure safe operation in its intended environment.

[0012] After performing an upgrade / update, unforeseen problems may arise in the field and it may then be desirable to revert to the pre-upgrade state (rollback). However, in many cases this may not be possible in a quick and uncomplicated manner or may involve additional downtime of the system.

[0013] You can use a container orchestration framework like Kubernetes, which supports so-called "rolling updates" with the goal of zero service downtime.

[0014] For zero downtime updates of software in systems involving physical actuators, and combining this approach with a container orchestration framework, the method disclosed in EP3502875A1 for seamless and safe upgrades of SW-intensive systems during operation can be used.

[0015] These kinds of approaches work well in automation processes where the automation is implemented in a single "monolithic microservice". This means that if there is more than one microservice implementing a federated solution (such as in an automation environment), it depends on how the functionality (implemented in the microservice) is used. If the functionality is used in several independent, standalone processes (the ideal microservice architecture), each service can be updated, such as in one of the above approaches.

[0016] In case several microservices handle a joint process, it depends on the process implementation. Updating / upgrading a microservice should meet the following requirements:

[0017] Updates should be performed as quickly as possible.

[0018] It does not ensure that there are time slots where all involved microservices have the process state "idle" at the same time.

[0019] It should be ensured that each component is produced based on the previous / current or updated / new software version instead of a mix of previous and updated versions. There is no available knowledge about when and in which order microservices should be updated.

[0020] It doesn’t work like this: update every single microservice as soon as they are “idle”.

[0021] Figure 1 A constellation is shown as an example of where a software update might generate errors.

[0022] With reference numeral "1", an initial automation process is shown, in which robot RB1 as an actuator collects workpieces of green G, blue B and red R from basket IN and places them one by one on conveyor belt BT. Robot RB2 as an actuator picks up workpieces from the conveyor belt and sorts them into basket OUT containing blue workpieces and basket E containing red and green workpieces (as exceptions).

[0023] Marked with reference number "2", the automated process of updating is shown.

[0024] In the previous software version of the microservice, the microservice was configured to control robot RB2 which handles all kinds of workpieces. In the new / updated software version, robot RB1 separates only green workpieces. The separated workpieces are not forwarded to robot RB2.

[0025] According to the initial automation process, robot RB1 was running with the previous software version before its "update time slot". Therefore, it also puts the green workpiece on the conveyor. Robot RB2 is now in process state "idle" (nothing to do) and is also updated with the new software version.

[0026] The following error occurs:

[0027] The processing of the workpieces on the conveyor starts with the previous process and ends with the new / updated process (mixed process).

[0028] The updated software version of robot RB2 does not support any handling of the green workpiece (which is now handled by robot RB1). So the green workpiece still remains on the conveyor, because robot RB2 was not able to handle it before the update.

[0029] • No join slots available. The microservice for the conveyor belt BT can be updated earliest when the microservice is "idle" (eg, the conveyor belt is empty).

[0030] The order in which the different services are used is mostly opaque and not easy to work with, so often the entire system has to be shut down to perform any updates. Summary of the invention

[0031] Therefore, it is an object of the present invention to provide an improved system and / or an improved method for upgrading and / or updating at least one (micro)service of a plurality of services.

[0032] The above objects are achieved by a method and one or more devices and / or systems and / or arrangements according to the features of the independent claims.

[0033] Preferred embodiments of the invention are described in the dependent claims. Any combination of the features of the dependent claims is possible with each other and with the features of the independent claim.

[0034] The present invention claims a computer-implemented method for upgrading and / or updating at least one service of a plurality of services executing on a computer-implemented system, wherein the plurality of services implement a joint technology application in the system,

[0035] wherein the computer-implemented method is configured to:

[0036] a. deploying at least one updated version of at least one service that requires updating or upgrading on the system while maintaining a current version of the service on the system, wherein the updated version of the at least one service is prevented from controlling a specific portion of the joint technology application;

[0037] b. a deployment and operations monitoring module for protocolizing the communications between the plurality of services and for analyzing dependencies between the applications of the plurality of services with respect to their runtimes, wherein such dependencies are derived from data generated by the protocolized communications, wherein the protocolized communications contain the times at which the plurality of services communicate with other components of the system, and wherein the dependencies between all the applications of the plurality of services result in a time-ordered sequence of service activities categorized by the protocolized times, whereby the service activities are separated from each other by one or more inactivity sequences of all services;

[0038] c. determining a process state of said services suitable for updating and / or upgrading each at least one service by following criteria inferred from said dependencies to identify a suitable time slot for updating and / or upgrading said at least one service, wherein a suitable time slot means that all services are inactive at the same time;

[0039] d. disabling control of the current version of the service within the current technology application at a time slot in the identified time slot; and

[0040] e. Enable control of deployed updated versions of services within the current technology application.

[0041] Typical industrial plants are complex technical systems consisting of a wide variety of interconnected components, such as controllers, IO systems, industrial communication modules, energy distribution equipment, etc. Each component possesses various characteristics that are required to operate the respective system and achieve the required functionality.

[0042] Computer-implemented systems can be technical systems, or digital twins, or any combination of these.

[0043] For example, a joint technical application can read sensor data and / or control actuators in a technical process, for example to run a specific product and / or transport process.

[0044] Updating and / or upgrading at least one service is performed continuously, preferably at runtime (see below).

[0045] Within current technology applications, enabling control of deployed updated versions representing updated and / or upgraded versions of services typically results in modification of the joint application and / or implementation of another technology application (eg, modified / improved control of an actuator).

[0046] The protocolized communications may be recorded as time series data for all services over a predefined or predefined period of time.

[0047] Data regarding the communications may be captured from specific input and / or output services (preferably implemented as sidecars) that manage communications between the services implementing the federated technology application.

[0048] The criterion may be that the criterion is met if the first service activity of the plurality of services is started after a suitable time slot and / or the last service of the plurality of services is started before a suitable time slot in which the process states of all services are suitable for updating and / or upgrading.

[0049] The dependencies between all applications of a service may result in service activity sequences and service inactivity sequences, whereby each service activity sequence categorizes its service activities in chronological order. The sequences may be constructed by using recorded time series data. The resulting chronological order of service activities shall conform to the criteria. These sequences may be separated from each other by one or more inactivity sequences for all services.

[0050] Machine learning is used to determine the process state. When machine learning is applied in parallel with the application of the service, the training data for machine learning can be divided into (during the time period) a training data set to build a neural network model for machine learning, and a validation data set to validate the output data of the constructed neural network model.

[0051] If all variants of such a separated sequence during a predefinable time period are used as training data for machine learning, such training data can be labeled to separate them into a first data set representing process states of services suitable for updating and / or upgrading and a second data set representing process states of services not suitable for updating and / or upgrading. For example, time intervals (gaps) during which all services are inactive are suitable for updating / upgrading. When a service is inactive / has no activity, the process state of the service is "inactive" and / or "idle".

[0052] The present invention and its embodiments provide the following benefits:

[0053] • The present invention works in dynamic systems where dependencies between different services are changing and / or opaque.

[0054] • The present invention ensures automated software updates at runtime (zero downtime) as quickly as possible and at the right time and / or in the right sequence.

[0055] The present invention reduces the cost of system downtime.

[0056] The invention ensures that each individual "process run" is terminated based on the same "process implementation" from which it was started (no mixing between old and newer process behaviors) (e.g. Figure 1 ).

[0057] • Furthermore, the derived knowledge can be used to identify better service reductions (reducing their dependencies on each other). The present invention can be used as a tool for continuous improvement of the underlying software architecture and the implementation structure of microservices.

[0058] The present invention also claims a system for upgrading and / or updating at least one service of a plurality of services executed on a system, wherein the plurality of services implement a joint technology application and each service is configured to control a specific portion of the joint technology application,

[0059] The system is thereby coupled to and / or comprises one or more processors, the one or more processors being configured to:

[0060] a. deploying at least one updated version of at least one service that requires updating or upgrading on the system while maintaining a current version of the service on the system, wherein the updated version of the at least one service is prevented from controlling a specific portion of the joint technology application;

[0061] b. a deployment and operations monitoring module for protocolizing the communications between the plurality of services and for analyzing dependencies between the applications of the plurality of services with respect to their runtimes, wherein such dependencies are derived from data generated by the protocolized communications, wherein the protocolized communications contain the times at which the plurality of services communicate with other components of the system, and wherein the dependencies between all the applications of the plurality of services result in a time-ordered sequence of service activities categorized by the protocolized times, whereby the service activities are separated from each other by one or more inactivity sequences of all services;

[0062] c. determining a process state of said services suitable for updating and / or upgrading each at least one service by following criteria inferred from said dependencies to identify a suitable time slot for updating and / or upgrading said at least one service (at runtime), wherein a suitable time slot means that all services are inactive at the same time;

[0063] d. disabling control of the current version of the service within the current technology application at a time slot in the identified time slot; and

[0064] e. Enable control of deployed updated versions of services within the current technology application.

[0065] The version being updated can also be understood as an upgraded version.

[0066] One or more processors can be distributed across servers or in the cloud.

[0067] The above-described method embodiments may similarly be applied to systems, devices, computer programs (products), and computer-readable storage media.

[0068] The system and device may be implemented in hardware, firmware and / or software, or a combination thereof.

[0069] The computer-readable storage medium stores instructions executable by one or more processors of a computer, wherein execution of the instructions causes the computer system to perform the method.

[0070] The computer program (product) is executed by one or more processors of a computer and performs the method. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] The foregoing and other aspects of the present invention are best understood from the following detailed description when read in conjunction with the accompanying drawings. For the purpose of illustrating the invention, presently preferred embodiments are shown in the accompanying drawings, however, it should be understood that the invention is not limited to the specific means disclosed. The accompanying drawings include the following figures:

[0072] Figure 1 The state of the prior art described above is shown;

[0073] Figure 2 , 3 and 4: each diagram shows an example of the relationship between microservices in different process scenarios; and

[0074] Figure 5 Depicts the different components and / or modules that build the service architecture and their dependencies. DETAILED DESCRIPTION

[0075] In the context of the present invention, the following definitions are given:

[0076] renew:

[0077] Software updates represent new versions of software and are usually indicated by a change in the version number. They usually ensure that security holes and / or functional flaws in the program are closed / fixed.

[0078] upgrade:

[0079] A software upgrade can be better described as a new variant based on the original variant and includes technological innovations / improvements.

[0080] PLC:

[0081] Programmable logic controllers (PLCs) are industrial computer control systems that continuously monitor the state of input devices and make decisions based on custom programs to control the state of output devices.

[0082] OPC UA:

[0083] In industrial environments, there is a communication standard called OPC Unified Architecture (OPC UA). OPC UA is a cross-platform, open source IEC62541 standard for data exchange from sensors to cloud applications, developed by the OPC Foundation.

[0084] Runtime:

[0085] This concept is used to describe something that is being changed while the process affected by the change is ongoing. Switching computer parts or changing a software program at runtime means replacing / changing the computer / software part while the computer / software program is still running.

[0086] Process status:

[0087] In a multi-tasking computer (- implemented) system, a process may occupy multiple states. Typical process states are "active", "inactive / not active", "idle" or "waiting", etc.

[0088] Digital Twin:

[0089] A digital twin is a virtual representation that is a real-time digital counterpart of a physical object or process. Product drawings and engineering specifications have evolved from manual drafting to computer-aided design to model-based systems engineering. In a manufacturing environment, physical manufacturing objects are virtualized and represented as digital twins (avatars), seamlessly and tightly integrated in both physical and cyberspace. The physical object and the twin interact in a mutually beneficial way.

[0090] Microservices:

[0091] An approach in which a single application is composed of many smaller services that are loosely coupled and independently deployable.

[0092] Kubernetes:

[0093] An orchestration framework for container-based applications in computer clusters, responsible for the deployment, scaling, and management of applications.

[0094] container:

[0095] Containers are standardized software units that allow developers to isolate their applications from their environment. Containers run on a shared OS and encapsulate all resources, such as libraries, required by a specific application process. Processes running in a container can only access devices assigned to the container (such as a virtual machine).

[0096] Microservices Architecture:

[0097] An architectural design that uses containers to build distributed applications. They get their name because each function of the application operates as an independent service. Microservices architectures typically treat each function of an application as an independent service that can be changed, scaled, updated, or removed without affecting the rest of the application. Any business can benefit from the use of microservices architecture if their applications require frequent updates, experience dynamic business patterns, or require near real-time communication.

[0098] Kubernetes-Pod:

[0099] A Pod is the smallest deployable computing unit that can be created and managed in Kubernetes. A Pod is a group of one or more containers with shared storage and network resources and specifications for how to run the containers. The contents of a Pod are always co-located in a shared context and co-scheduled and run. A Pod simulates an application-specific "logical host": it contains one or more application containers that are relatively tightly coupled. In a non-cloud environment, applications executing on the same physical or virtual machine are similar to cloud applications executing on the same logical host.

[0100] Service Mesh:

[0101] A service mesh is an abstraction layer on top of a microservice application that provides the following capabilities:

[0102] Service-to-service communication (including service discovery and encryption)

[0103] Observability (monitoring and tracing)

[0104] Resilience (circuit breaking and retry)

[0105] Service management (routing, load balancing)

[0106] Security (authorization, encryption)

[0107] Service Mesh - Sidecar:

[0108] A service mesh addresses some of the challenges posed by distributed microservices by abstracting the necessary functionality—service discovery, connection encryption, error and failure handling, and latency detection and response—into separate entities called proxies.

[0109] A proxy (also called a sidecar) sits in front of each microservice and all inbound and outbound communications flow through it. The proxy provides the above functionality and metrics for observability purposes.

[0110] Service Mesh – Control Plane:

[0111] Service instances, sidecars, and their interactions make up what is known as the data plane in a service network. Another layer called the control plane manages tasks such as creating instances, monitoring, and implementing network management and security policies. The control plane can be connected to a CLI or GUI interface for application management.

[0112] In this example, the term "update" is used for both the terms "update" and / or "upgrade." In the automation process explained below, microservices are used for the above services.

[0113] refer to Figure 1 In the initial automation / production process 1, there is a one-to-one sequence of microservices, such as microservice MS1 for robot RB1, microservice MS2 for conveyor belt BT, and microservice MS3 for robot RB2. In a sequential production process - e.g. Figure 2 As shown - MS1 starts (robot RB 1 places a workpiece w on the conveyor belt BT), and after transferring workpiece w (MS2) to the direction of robot RB2 on the conveyor belt, microservice MS 3 starts (RB2 picks up workpiece w from the conveyor belt). In the parallel production process - as Figure 3 Shown - MS1 starts with "placing more than one workpiece on the conveyor". The workpieces are conveyed (MS2) to RB2. Robot RB2 picks up (MS3) all the workpieces on the conveyor.

[0114] The following knowledge can be derived:

[0115] Identified microservices: MS1 (robot RB1), MS2 (conveyor belt BT), MS3 (robot RB2)

[0116] ·Activity initiated by MS1

[0117] Sequential and / or parallel processes

[0118] Used in a “one-to-one” sequence: MS1–MS2–MS3

[0119] The maximum time delay between microservices (MS1 to MS2 and MS2 to MS3)

[0120] ·Minimum / maximum time required after process starts

[0121] Possibly the process was terminated by MS3.

[0122] Figure 4 A parallel production process is shown, which does not use a one-to-one sequence.

[0123] The following knowledge can be derived:

[0124] Identified microservices: MS1 (robot RB1), MS2 (conveyor belt BT), MS3 (robot RB2)

[0125] ·Activity initiated by MS1

[0126] Overlapping process

[0127] There is no “one-to-one” sequence: MS1–MS2–MS3

[0128] The maximum time delay between microservices (MS1 to MS2 and MS2 to MS3)

[0129] After MS1 is completed, the minimum / maximum time required for the process to complete

[0130] The process is terminated by MS3 or rarely by MS1

[0131] The same number of starts and stops within each MS2 and MS3.

[0132] Using the derived knowledge and the current “process state”, the present invention calculates the most appropriate “update order” and appropriate “update time slot” for each individual microservice.

[0133] Figure 5 The different components and / or modules and their dependencies are shown.

[0134] The architecture of these components builds a service architecture. In particular, microservices are used. Microservices are encapsulated in containers CI / O, CA2K, CF1, ..., CFn, and these containers are embedded in Kubernetes Pods P IO, PA2K, Pod F1, ... PodF2, and can obtain information through the gateway G. The architecture also uses sidecars SC F1, SC F2, SC Fn and SC I / O based on the service mesh implementation. The sidecar is able to obtain, forward and manipulate outbound and / or inbound communications in IN. Information about the timing and dependencies of activities performed from different microservices leads to runtime updates / upgrades that allow microservice software.

[0135] The invention supports two different alternatives A1 and A2 for realizing an interface to a technical system T to be controlled. The technical system can include an automated process with a robot as an actuator, a conveyor belt and the above-mentioned workpieces.

[0136] Alternative A1:

[0137] Access to the actors and sensors of the technical system via I / O (I / O = process input and output) is implemented via a conventional programmable logic controller PLC (especially without the use of microservices) to control process-specific hardware, such as robots, conveyor belts.

[0138] Alternative A2:

[0139] Management of process images through microservices to control (see Figure 5 Ctr in)Process-specific hardware, such as robots, conveyors.

[0140] Typically, microservice architectures are designed so that different microservices can be updated and / or upgraded independently of each other. Figure 1 For example, each microservice can be updated and / or upgraded without any knowledge about the overall process dependencies.

[0141] In the following system implemented by microservices, for example, according to Figure 4 , knowledge about the joint technical application (e.g. controlling actuators in an automation process) is derived from each substitution of the I / O.

[0142] One of the main challenges facing automation systems is to achieve flexible and efficient production processes (e.g. batch sizes and zero downtime in production). This requires an automated approach to update and / or upgrade services in automation solutions at runtime.

[0143] In the architecture shown, there is a monitoring module A2K, called "Knowledge Activities". This module enables monitoring and analysis of the usage of available microservices / dependencies in the application. Depending on the above alternatives, there are different possibilities to capture the required data:

[0144] Alternative A1 is to interface the different functions F to the hardware via the mentioned PLC manipulation / control. In this case, the required data is derived from the microservices F1, ..., Fn of all the different functions via the associated sidecars (e.g. SC F1 shown and SC F2, ..., SC Fn hidden).

[0145] Alternative A2 is to interface I / O to hardware via “IO microservices”.

[0146] The required data can be derived via input and / or output communication occurring at the relevant sidecar SC I / O monitoring "IO microservice". (Exception: direct communication between microservices (without using "IO microservice")

[0147] Module A2K analysis:

[0148] When the process states (see reference symbol PSt) of the different microservices are active. This means when they are communicating with other components of the system.

[0149] How different activities and microservices relate to each other (which microservice initiates an activity for which microservice).

[0150] How to time it (how long different activities last: shortest, longest, average).

[0151] Based on the determined / calculated time slots suitable for updating / upgrading and the order of updating / upgrading, module A2K initiates an update (see reference numeral Up) for each involved microservice (initiates a switch between the current version Vx and the updated version). The update can be triggered by using the API (application programming interface) of a container orchestration framework (e.g. Kubernetes), but it can also be triggered by a service grid.

[0152] A2K components can be implemented in different ways:

[0153] i. As an algorithm that detects process states suitable for upgrading based on a fixed set of rules

[0154] ii. Use of Artificial Intelligence:

[0155] o Perform supervised learning using training data to distinguish between process states that are suitable for upgrading and those that are not suitable for upgrading

[0156] o Unsupervised learning for clustering: separate “active” (active) clusters from “idle” (inactive) clusters; trigger upgrades only during “idle” clusters.

[0157] Based on the calculated "update order" and "update time slot", "A2K" initiates updates for each involved microservice (controls switching between versions). Updates can be triggered by using the API of the container orchestration framework (such as Kubernetes), but can also be triggered through the service mesh.

[0158] The following suitable AI methods can be applied to the continuous update of microservices that work together in a priori unknown ways.

[0159] The following steps are described to provide analysis for points a, b, and c above.

[0160] 1. Identification of microservice collaboration patterns based on time series analysis.

[0161] 2. Identify gaps (time slots) during the full operation of the automation process so that updates to the microservices can be performed.

[0162] 3. Recommend updating microservices as soon as an update is requested and predict a range of suitable time slots for such updates.

[0163] The following method involving steps 1 and 2 above can be used for the aforementioned algorithm i as well as unsupervised and supervised machine learning ii.

[0164] Ad 1: Record tagged time series data of all microservices of the automation process. This recording can be done by the monitoring module mentioned above. For timestamps of all microservices, tags are active or inactive. A qualified time period TP for recording must be defined. The term "qualified" means that the recorded time period TP represents all collaboration patterns of microservices, which may also occur in future time periods of planned updates of microservices. The collaboration pattern including dependencies between microservices is defined by the microservice activity sequence S.

[0165] will generate statistics of the activities of all individual microservices MS_1, MS_2, MS_3, etc.

[0166] Time intervals of all activities: lengths of all identifiers A_1, A_2, ..., A_n, such as minimum and maximum lengths.

[0167] Also included are all identified time intervals / time slots without activity, meaning inactivity gaps I_1, I_2, ... I_n, such as minimum, maximum length, etc.

[0168] Based on this analysis, overall gaps are identified (which means: all microservices were inactive at the same time): all time periods of gaps G_1, G_2, ..., G_n, including maximum, median and minimum values, are identified and counted over the entire recording period.

[0169] The chronological order of microservices MS_1, MS_2, MS_3, etc. until MS_x is identified in the startup phase, and after a period of inactivity (gap) for all microservices: which microservice is started first, then which microservice is started second, then which microservice is started third, and so on.

[0170] The chronological order is also identified during the shutdown phase and before the entire period of inactivity (gap) backwards: which microservice was the last, second to last, and so on.

[0171] The sequence S (t_s(MS_1), t_e(MS_1), t_s(MS_2), t_e(MS_2), t_s(MS_3), t_e(MS_3) etc.) is the activity pattern of the orchestrated microservices to solve the joint technology application. For a given start time t_s and end time t_e of each microservice, the sequence categorizes the active microservices MS. It is defined as:

[0172] For all individual microservices, t_s <t_e;

[0173] t_s(MS_1)<=t_s(MS_2)<=t_s(MS_3), etc., and

[0174] t_e(MS_1)<=t_e(MS_2)<=t_e(MS_3), etc.

[0175] All activities of a microservice with a time period TP are divided into several sequences S. A sequence is initiated by an MS_1 activity. A sequence S may contain one or several activities of the following MS_2, MS_3, etc. between the start time t_s and the end time t_e of each microservice.

[0176] Once the sequence of microservices has been identified, for all sequences S, identify the time distances TD_12s=t_s(MS_2)-t_s(MS_1), TD_23s=t_s(MS_3)-t_s(MS_2), etc. between the start of the first microservice and the start of the second microservice, between the second and third microservices, etc. In the same way, identify the time distances between the end times: TD_12e=t_e(MS_2)-t_e(MS_1), TD_23e=t_e(MS_3)-t_e(MS_2), etc.

[0177] If the end time t_e of the last microservice of sequence S(i) is less than the start time of the next sequence S(i+1), there is an overlap between sequences S(i) and S(i+1).

[0178] A gap G consisting of simultaneous inactivity of all microservices serves as separation between sequences S. In case two sequences overlap, an inactivity gap I of each microservice serves as separation: an inactivity I of microservice MS_1 after t_e(MS_1) is followed by another inactivity I of MS_2 after t_e(MS_2), another inactivity I of MS_3 after t_e(MS_3), etc. This sequence of inactivity gaps SIG of all microservices serves as separation between collaborating (overlapping) sequences.

[0179] The identification or separation of sequences requires the description of many constraints and the use of iterative optimization methods.

[0180] The standard approach to solving is to apply a solver for constraint programming (CP) (https: / / en.wikipedia.org / wiki / Constraint_programming) and / or mixed-integer programming is an optimization method in which some or all variables are restricted to be integers. In many settings, the term refers to integer linear programming (ILP), where the objective function and the constraints (except for the integer constraints) are linear. If some decision variables are not discrete, the problem is called a mixed-integer programming problem (https: / / en.wikipedia.org / wiki / Integer_programming). For such optimization tasks, there are commercial (e.g. Gurobi, CPLEX), non-commercial (e.g. SCIP), and proprietary (e.g. Supreme and moaas) solvers. A problem statement in mathematical format is sufficient to start such a solver and obtain a sequence S followed by a sequence of inactive gaps SIG for a given time period TP listed.

[0181] Ad 2: For gap analysis, the update times UT_1, UT_2, UT_3, etc. for all microservices MS_1, MS_2, MS_3, etc. are given.

[0182] The simple case is: if the update times UT_1, UT_2, etc. are smaller than the gaps, G_j>max(UT1, UT2, UT3, etc.), then only the start of those gaps G_j must be identified for the update.

[0183] Gaps G_i that are too short for the overall update and gaps G_j that are long enough for the update are sorted, etc. Then only the start of the next gap must be taken from the future time series.

[0184] In case of an overlapping sequence S followed by an overlapping sequence of inactivity SIG: If the update times UT_1, UT_2, UT_3, etc. conform to all inactivity gaps I of the corresponding microservices of SIG (sequence of inactivity gaps), then the updates can proceed in the given sequence. Distinguish between SIG_j>((I(MS_1)>UT1) and (I(MS_2)>UT2)) and (I(MS_3)>UT3)) etc.) and SIG_i for which the gaps are too small.

[0185] Ad3: Choose a forecasting approach to derive criteria for future microservice updates from update opportunities identified in the past.

[0186] Guiding question: Is the time period TP long enough to represent all variants of the sequence S followed by a sequence of inactive gaps (SIG)? Case-based reasoning (CBR) analysis or clustering (similarity analysis based on clustering methods such as K-MEANS, DBSCAN, etc.) is performed. CBR is the process of solving new problems based on previous solutions to similar problems (https: / / en.Wikipedia.org / wiki / Case-based_reasoning).

[0187] If the sequence S following SIG appears more than once, and the number of variants is much smaller than the total number of sequences, there are some repetitive patterns that can be used for prediction.

[0188] Next guiding question: What is the necessary time range for starting the update? Because sequences S_j and SIG_j may overlap in some way, it may be too late to initiate the update after sequence S_j, but SIG_j has already started before S_j has finished. Some pattern in the time series must be identified that always occurs before SIG_j.

[0189] Before SIG_j (a sequence of inactivity gaps with sufficient update gaps) occurs, a neural network for time series prediction is applied to identify patterns in the time series. Applicable architectures for such neural networks are deep learning frameworks such as Tensorflow for feed-forward networks (see https: / / en.wikipedia.org / wiki / TensorFlow) or recurrent neural networks such as those implemented in SENN (see https: / / www.wit press.com / Secure / elibrary / papers / data00 / data00054fu.pdf).

[0190] Training of the neural network: The pattern of SIG_j is considered as the target information yt. The other patterns are the input patterns x of the neural network. The goal is to minimize the difference between the target information yt and the model output y. The weights of the neural network are optimized in such a way that the objective function approaches zero. The typical training method is to divide the data of the time period TP into a training set and a verification set. The neural network model is built on the basis of the training data. Then it is applied to the verification of the verification data.

[0191] Application of Neural Networks in Automating Process Microservice Updates:

[0192] The neural network defined by the network architecture and weights is applied in parallel to the operation of the microservices of the automated process. It acquires the current time series data in real time. The model calculates the near-term output y with a timestamp (t_current+x) in real time. The future timestamp determines the predicted time range of the process state suitable for the updated microservice. If the output y provides a value indicating SIG_j in the near future, the computer-implemented system or the person responsible for the update that can use the API of the container orchestration framework knows that the update of the microservice can be implemented within the time slot.

[0193] Finally, control over the current version of the microservice within the current automation process is disabled during that time slot, and control over the deployed updated version of the microservice is enabled.

[0194] The invention has been described in detail with reference to embodiments and examples of the invention. Variations and modifications are possible. Instead of the above-described production process, one or more processes may be similarly applied to an AGV (Automated Guided Vehicle), where one vehicle transports a workpiece from one place to another, where the workpiece is processed in different process stages.

[0195] It is also conceivable that the present invention is similarly used in the context of energy systems like microgrids, where energy load balancing needs to be controlled by manipulating energy suppliers and energy consumers at the right time.

[0196] The system may be (computer) implemented to perform the method steps of the present invention.

[0197] The system can be integrated into a (computer) cloud. It includes one or more processors and can be coupled to data, wherein the processor is configured to perform the method steps.

[0198] The method may be performed by at least one processor such as a microcontroller or microprocessor, an application specific integrated circuit (ASIC), any kind of computer including a mobile computing device such as a tablet, smartphone or laptop, or one or more servers in a control room or in the cloud.

[0199] For example, a processor of a system and / or computer, a controller or an integrated circuit and / or another processor may be configured to implement the actions described herein.

[0200] The above method can be implemented by a computer program (product), which includes one or more computer-readable storage media, on which instructions that can be executed by one or more processors of a computing system and / or computing engine are stored. The execution of the instructions causes the computing system to perform operations corresponding to the actions of the above method.

[0201] Instructions for implementing the processes or methods described herein may be provided on a non-transitory computer-readable storage medium or memory, such as a cache, buffer, RAM, flash memory, removable media, hard drive, or other computer-readable storage medium. The processor executes or implements instructions to train and / or apply a trained model for a control system. Computer-readable storage media include various types of volatile and non-volatile storage media. The functions, actions, or tasks shown in the figures or described herein may be performed in response to one or more sets of instructions stored in or on a computer-readable storage medium. Functions, actions, or tasks may be independent of a particular type of instruction set, storage medium, processor, or processing strategy, and may be performed individually or in combination by software, hardware, integrated circuits, firmware, microcode, etc. Similarly, processing strategies may include multi-processing, multi-tasking, parallel processing, etc.

[0202] Additionally or alternatively, the control device may receive other computer-readable control signals in order to initiate the described manipulation / control process via its processor.

[0203] The present invention has been described in detail with reference to the embodiments and examples of the present invention. However, within the spirit and scope of the present invention covered by the claims, changes and modifications may be made. The phrase "at least one of A, B and C" as an alternative expression may specify that one or more of A, B and C may be used.

[0204] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the exemplary embodiments of the present invention.As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0205] It should be understood that the elements and features recited in the appended claims may be combined in different ways to produce new claims that also fall within the scope of the invention. Therefore, although the dependent claims attached below are only dependent on a single independent or dependent claim, it should be understood that these dependent claims may be alternatively dependent on any previous or subsequent claims, whether independent or dependent, in an alternative form, and such new combinations should be understood to form part of this specification.

[0206] No element recited in a claim is intended to be a means-plus-function element unless the element is explicitly recited using the phrase "means for" or, in the case of a method claim, the phrase "operation of" or "step of."

[0207] Although the present invention has been described above with reference to various embodiments, it should be understood that many changes and modifications may be made to the described embodiments. Therefore, the foregoing description is intended to be considered illustrative rather than restrictive, and it should be understood that all equivalents and / or combinations of the embodiments are intended to be included in this description.

Claims

1. A computer-implemented method for upgrading and / or updating at least one service of a plurality of services executed on a computer-implemented system (T), wherein the plurality of services implement a joint technical application in the system, wherein the computer-implemented method is configured to: a. deploying at least one updated version (Vx) of at least one service that requires updating or upgrading on the system while maintaining a current version of the service on the system, wherein the updated version of the at least one service is prevented from controlling a specific portion of the joint technology application; b. a deployment and operations monitoring module (A2K) for protocolizing the communication (IN) between the plurality of services and for analyzing dependencies between the applications of the plurality of services with respect to their runtimes, wherein such dependencies are derived from data generated by the protocolized communications, wherein the protocolized communications contain the times at which the plurality of services communicate with other components of the system, and wherein the dependencies between all the applications of the plurality of services result in a time-ordered sequence of service activities classified by the protocolized times, whereby the service activities are separated from each other by one or more inactivity sequences of all services; c. determining a process state (PSt) of said services suitable for updating and / or upgrading each at least one service by following criteria inferred from said dependencies to identify a suitable time slot for updating and / or upgrading said at least one service, wherein a suitable time slot means that all services are inactive at the same time; d. disabling control (Ctr) of the current version of the service within the current technology application at the time slot in the identified time slot; and e. Enable control of deployed updated versions of services within the current technology application (Ctr).

2. The method according to the preceding claim, wherein the protocolized communications are recorded as time series data for all services during a predefinable time period.

3. A method according to any of the preceding claims, wherein the data about the communication is captured from a specific input and / or output service (SCI / O), which manages the communication between the multiple services that implement the joint technical application.

4. A method according to any of the preceding claims, wherein the criterion is met if the first service activity of the multiple services is started after a suitable time slot and / or the last service of the multiple services is started before a suitable time slot, in which the process status of all services is suitable for updating and / or upgrading.

5. The method according to any of the preceding claims, wherein machine learning is used to determine the process state.

6. The method according to the preceding claim, wherein when machine learning and application of the service are applied in parallel, the training data is divided into a training data set and a verification data set, wherein the training data set is used to construct a neural network model of the machine learning, and the verification data set is used to verify the output data of the constructed neural network model.

7. A method according to the preceding claim, wherein all variants of such a separated sequence during said predefinable time period are used as training data for said machine learning, whereby said training data are labeled so as to separate them into a first data set representing process states of services suitable for updating and / or upgrading and a second data set representing process states of services not suitable for updating and / or upgrading.

8. A system for upgrading and / or updating at least one service of a plurality of services executed on a system (T), wherein the plurality of services implement a joint technology application and each service is configured to control a specific portion of the joint technology application, The system is thereby coupled to and / or comprises one or more processors, the one or more processors being configured to: a. deploying at least one updated version (Vx) of at least one service that requires updating or upgrading on the system while maintaining a current version of the service on the system, wherein the updated version of the at least one service is prevented from controlling a specific portion of the joint technology application; b. a deployment and operations monitoring module (A2K) for protocolizing the communication (IN) between the plurality of services and for analyzing dependencies between the applications of the plurality of services with respect to their runtimes, wherein such dependencies are derived from data generated by the protocolized communications, wherein the protocolized communications contain the times at which the plurality of services communicate with other components of the system, and wherein the dependencies between all the applications of the plurality of services result in a time-ordered sequence of service activities classified by the protocolized times, whereby the service activities are separated from each other by one or more inactivity sequences of all services; c. determining a process state (PSt) of said services suitable for updating and / or upgrading each at least one service by following criteria inferred from said dependencies to identify a suitable time slot for updating and / or upgrading said at least one service, wherein a suitable time slot means that all services are inactive at the same time; d. disabling control (Ctr) of the current version of the service within the current technology application at the time slot in the identified time slot; and e. Enable control of deployed updated versions of services within the current technology application (Ctr).

9. A computer program product to be executed by a computer or one or more processors of a system according to the preceding claim, so as to perform the method according to any of the preceding method claims.

Images