Scheduling metadata for combinable real-time systems

Abstract

There is disclosed a method for integrating at least one combinable service into a system of combinable services, the method comprising: packaging scheduling metadata with at least one combinable service, where the scheduling metadata comprises scheduling-related constraints for each of the at least one combinable service; and integrating the at least one combinable service into a system of combinable services based on the scheduling metadata. A computer readable medium is disclosed, the computer readable medium comprising at least one combinable service, the at least one combinable service comprising packed scheduling metadata; wherein the scheduling metadata includes scheduling-related constraints for each of the at least one combinable service. A system for at least one combinable service is disclosed, the system including a processor configured to integrate the at least one combinable service received from a computer readable medium into the system for the at least one combinable service based on scheduling metadata.

Description

Technical Field

[0001] The present disclosure relates to a method for integrating at least one composable service into a system of composable services and a system for at least one composable service. Background Art

[0002] Real-time systems require careful adjustment of scheduling-related aspects such as thread priorities. This is done by hard-coding such information or by manual configuration by human experts. For systems consisting of multiple services, especially if these services are developed independently, the problem becomes complex.

[0003] Complex software systems (e.g., factory or substation automation systems) are typically designed to consist of multiple (preferably independent) services. This can be used by vendors to compose products with fixed functionality, or by end-users or integrators to configure and deploy systems with functionality that matches customer requirements.

[0004] Automation systems are typically implemented as embedded devices (e.g., protection relays or programmable logic controllers) with real-time software (i.e., software in which at least some services have deterministic execution times that meet specific constraints).

[0005] The correct operation of such systems requires adjustment of various scheduling-related aspects such as thread priorities, affinity, cache partitioning, etc. Today, such systems are either developed with hard-coded scheduling characteristics (as Figure 1 shown), or manually adjusted by human experts integrating the services into the system / product ( Figure 2 ).

[0006] Hard-coded scheduling or manual configuration of scheduling is particularly problematic when real-time systems consist of independently developed services that should be freely composable. In such cases, the hard-coded values may lead to scheduling conflicts. Similarly, through manual configuration, integration engineers may inadvertently select scheduling attributes that violate the implicit assumptions of the services. Summary of the Invention

[0007] The invention is defined by the independent claims. The dependent claims relate to preferred embodiments.

[0008] The present disclosure relates to a method for integrating at least one composable service into a system of composable services, the method comprising: packaging scheduling metadata with the at least one composable service, wherein the scheduling metadata includes scheduling-related constraints for each of the at least one composable service; and integrating the at least one composable service into the system of composable services based on the scheduling metadata.

[0009] Various embodiments may preferably implement the following features:

[0010] Preferably, integrating the at least one composable service into a system of composable services based on the scheduling metadata includes: performing static verification and / or automatic generation and / or dynamic verification using the scheduling metadata.

[0011] Preferably, packaging the scheduling metadata includes: including the scheduling metadata in the source file of each composable service among the at least one composable service, or attaching the scheduling metadata to a binary package distributed via a package distribution mechanism.

[0012] Preferably, the at least one composable service is an independently developed software component for implementation / integration into a system of composable services.

[0013] Preferably, the system of composable services runs under a general operating system, wherein at least one composable service executes as a process, a thread, or a container.

[0014] Preferably, the scheduling metadata includes one or more constraints related to one or more schedulable entities, such as relative thread priorities, scheduling policies, CPU affinity, or cache partitioning, etc.

[0015] Preferably, performing static verification using the scheduling metadata includes: preparing, preferably manually or by a human expert, a scheduling configuration of at least one composable service within the system of composable services; wherein the prepared scheduling configuration can be executed by the system of composable services.

[0016] In an embodiment, preparing a scheduling configuration of at least one composable service within the system of composable services may include a (semi)-automated method for the preparation. For example, the (semi)-automated method may be external automation, such as a script for configuration.

[0017] Preferably, further performing static verification using the scheduling metadata includes: verifying, via a verification tool, whether the prepared, preferably manually prepared or prepared by a human expert, scheduling configuration satisfies all scheduling-related constraints included in the scheduling metadata; and indicating the result of the verification.

[0018] Preferably, performing automatic generation using the scheduling metadata includes: automatically combining the scheduling metadata of at least one composable service via an automated configuration tool to generate a global scheduling configuration that satisfies the scheduling-related constraints included in the scheduling metadata of at least one composable service.

[0019] Preferably, performing dynamic verification using the scheduling metadata includes: performing runtime verification of the scheduling metadata via an execution tool to detect whether there is a violation of any scheduling-related constraint included in the scheduling metadata of at least one composable service; and indicating the result of the verification.

[0020] The present disclosure also relates to a computer-readable medium that includes: at least one composable service, the at least one composable service including packaged scheduling metadata; wherein the scheduling metadata includes scheduling-related constraints for each composable service in the at least one composable service.

[0021] The present disclosure also relates to a system for at least one composable service, the system may include a processor configured to integrate at least one composable service received from a computer-readable medium (as described above) into the system for at least one composable service based on the scheduling metadata.

[0022] Various embodiments may preferably implement the following features:

[0023] Preferably, the system further includes an automated configuration tool configured to: receive the scheduling metadata packaged with each composable service in the at least one composable service; combine the scheduling metadata packaged with each composable service in the at least one composable service; and generate a scheduling configuration for at least one composable service within the system of composable services, wherein the scheduling configuration is executable by the system of composable services.

[0024] Preferably, the system further includes a static verification tool configured to: receive the scheduling configuration of the at least one composable service; receive the scheduling metadata packaged with each composable service in the at least one composable service; verify whether the scheduling configuration satisfies all scheduling-related constraints included in the scheduling metadata; and indicate the result of the verification.

[0025] Preferably, the system further includes a dynamic verification tool configured to: receive the scheduling metadata packaged with each composable service in the at least one composable service; receive an execution log file, wherein the execution log file includes scheduling-related information from the actual execution of the system configured with these services; and perform runtime verification of the scheduling metadata based on the scheduling metadata and the execution log file to detect any violation of any scheduling-related constraint included in the scheduling metadata of the at least one composable service.

[0026] According to an embodiment, a method for creating additional metadata for a distribution package accompanying a composable service is provided. This metadata describes the scheduling-related constraints to be satisfied in the final system. The metadata can be used for static or dynamic verification of the system, and / or for automated configuration.

[0027] According to an embodiment of the present disclosure, a system may include composable services packaged with metadata that describes constraints related to the scheduling of the composable services. The metadata may define at least one of the following: (i) relative thread priorities, (ii) scheduling policies, (iii) CPU affinity, and / or (iv) cache partitioning. The packaging mechanism may include: (i) being distributed as source code, and the metadata is included within the source files, (ii) being performed through a packaging distribution mechanism (e.g., .deb), and the metadata is installed with the files, and (iii) being performed through a container image, and the metadata is attached and distributed with the image.

[0028] According to another embodiment of the present disclosure, a system having the metadata as described above may be used to configure or verify the scheduling of services. For example, (a) the system may be used to statically verify a scheduling configuration prepared by a human expert, (b) the system may be used to automatically generate a scheduling configuration, (c) the system may be used to dynamically verify system behavior by monitoring system behavior at runtime (such as: (i) detecting incorrect implementations, and / or (ii) detecting cybersecurity violations (e.g., malicious threads)).

[0029] The present disclosure has been made in view of the above problems and provides a method and system for integrating at least one composable service based on metadata, particularly scheduling metadata for a composable real-time system.

[0030] The method in the present disclosure improves the quality of the system by ensuring that the system does not violate the requirements of each service used. Automated configuration can reduce costs and enable "plug-and-play" composability of services.

[0031] The exemplary embodiments disclosed herein are intended to provide features that will become readily apparent when considered in conjunction with the following description with reference to the accompanying drawings. Exemplary systems, methods, devices, and computer program products are disclosed herein in accordance with various embodiments. However, it should be understood that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art who read this disclosure that various modifications may be made to the disclosed embodiments while still within the scope of the present disclosure.

[0032] Accordingly, the present disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order and / or hierarchy of steps in the methods disclosed herein are merely exemplary methods. Based on design preferences, the specific order or hierarchy of steps of the disclosed method or process may be rearranged while still within the scope of the present disclosure. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in an exemplary order, and the present disclosure is not limited to the specific order or hierarchy presented unless otherwise expressly stated. Description of the Drawings

[0033] The above and other aspects and their embodiments are described in more detail in the drawings, the specification, and the claims.

[0034] Figure 1 Shows a hard - coded configuration of a scheduling - related service manually adjusted by a human expert during development according to the prior art.

[0035] Figure 2 Shows a manual configuration of a job scheduling configuration prepared by a human expert during integration according to the prior art.

[0036] Figure 3 Shows an illustration of a static verification of a manually prepared scheduling configuration according to an embodiment of the present disclosure.

[0037] Figure 4 Shows an illustration of an automatic generation of a scheduling configuration based on metadata of all used services according to an embodiment of the present disclosure.

[0038] Figure 5 Shows an illustration of a dynamic verification that performs a runtime verification of scheduling metadata according to an embodiment of the present disclosure.

[0039] Figure 6 Shows a flowchart of a method for integrating at least one composable service into a system of composable services according to an embodiment of the present disclosure.

[0040] Figure 7 Shows a system for integrating at least one composable service into a system of composable services according to an embodiment of the present disclosure. Detailed Description

[0041] The present disclosure generally relates to composable real - time systems, i.e., systems composed of independently developed components (services). Nowadays, such systems are often implemented using a general - purpose operating system with real - time capabilities (e.g., PREEMPT - RT Linux). Each service can be a separate process, which may or may not be containerized. Such a service itself can create additional threads with various characteristics (e.g., having a specific priority, limited to a specific CPU, etc.). Then all such threads are executed using the global scheduler of the operating system (OS), which works according to scheduling policies, priorities, affinities, etc.

[0042] Figure 1 Shows a hard - coded configuration of a scheduling - related service manually adjusted by a human expert according to the prior art. In particular, Figure 1Shows system 200 and services A 300a and B 300b. Service A 300a includes tasks T1 and T2. Service B 300b includes tasks T1 and T2. Additionally, service A 300a includes features hard-coded into the implementation of service A 300a, namely, the priority of task T1 is 20, and the priority of task 2 is 30. Similarly, service B 300b includes features hard-coded into the implementation of service B 300b, namely, the priority of task T1 is 10, and the priority of task T2 is 10.

[0043] That is to say, if the final system 200 (i.e., the hardware (HW) setup and the set of services 300a and 300b to be run) is fixed and known at development time, then such features can be hard-coded into the implementation of each service. For example, service A 300a can be implemented to create a task with a priority of 20, and service B 300b can be implemented to create a task with a priority of 10, and when developers have "complete knowledge" about the target system 200, they know that system 200 will operate properly under these specific settings. Figure 1 This is illustrated in.

[0044] However, if the services are developed independently, the subset of services 300a and 300b to be used is unknown at development time (e.g., it is a configurable product), or system 200 can run on hardware with different capabilities (e.g., a faster CPU, a different number of cores, a different number of nodes in a distributed system 200), then the situation is more challenging. In such a case, completely fixed settings may not work properly or may operate in a sub-optimal manner.

[0045] Figure 2 Shows the manual configuration of a job scheduling configuration prepared by a human expert according to the prior art. In particular, Figure 2 Shows human expert 100, system 200, service A 300a, service B 300b, and job configuration file 400.

[0046] If there is a possibility to configure scheduling features externally (e.g., via some configuration files), then human expert 100 (system integration expert) can prepare job configuration file 400 based on his / her expertise and testing, and this job configuration file is then used to integrate services 300a and 300b into system 200. However, this relies on the expert's knowledge of services 300a and 300b from documentation or just experience.

[0047] There is a lack of a machine-readable way to formally express constraints on the thread scheduling for each individual service 300a and 300b. Then, such constraints can be combined to obtain global scheduling information for the entire system 200 in a fully automated manner or with the assistance of a human engineer 100.

[0048] The present disclosure introduces the concept of scheduling metadata that describes the scheduling constraints for each service. This metadata describes the schedulable entities (tasks, threads) present in the service and the limitations or preferences of these schedulable entities with respect to real-time execution. Examples of such information can be:

[0049] 1. "The priority of thread X must be 60",

[0050] 2. "Thread X must have a higher priority than thread Y",

[0051] 3. "Thread X must be the single highest priority thread in the system"

[0052] 4. "Thread X must run on the same CPU as thread Y",

[0053] 5. "Thread X must run on a different CPU from thread Y",

[0054] 6. "Thread X must have a CPU dedicated for its exclusive use",

[0055] 7. "Thread X must run on the same CPU as the interrupt from network card A",

[0056] 8. "Thread X must share the L2 / L3 cache with thread Y".

[0057] Such rules leave some degree of freedom for the actual settings. For example, rule #6 does not specify the exact CPU assigned to thread X.

[0058] This metadata is created by, for example, service developers. The exact syntax can be, for example, a DSL (Domain-Specific Language). However, the present disclosure is not limited to the exact syntax, and a person skilled in the art can use any suitable syntax.

[0059] When a new version of a service (in any form, e.g., as source code, a compiled binary, or a binary in a container image) is released, the metadata is bundled with the release and is available to a party performing the composition of the system 200. For example, for a containerized application, this metadata can be attached to the Docker image as custom labels.

[0060] Examples of the embodiments described in the present disclosure are in Figure 3 、 Figure 4 andFigure 5 is illustrated in Figure 3 is an illustration of static verification of a manually prepared scheduling configuration. Figure 4 is an illustration of the automatic generation of a scheduling configuration based on the metadata of all services used. Figure 5 is an illustration of dynamic verification that performs runtime verification of system behavior based on scheduling metadata.

[0061] More specifically, when the system is composed (e.g., by a system integration expert), the metadata can be utilized in different ways, some of which are illustrated in Figures 3 to 5 as follows:

[0062] Figure 3 illustrates the process of static verification according to an embodiment of the present disclosure. In particular, Figure 3 shows a human expert (system integration expert) 100, a system 200, a service A 300a, a service B 300b, a configuration file 400, and a verification tool 500.

[0063] The scheduling configuration is first manually prepared by the system integration expert 100 such that the verification tool 500 can then verify whether the manually prepared configuration satisfies all the constraints of the services 300a and 300b based on the metadata of all services 300a and 300b used.

[0064] The metadata is included in the corresponding services 300a and 300b. In particular, in Figure 3 service A 300a and service B 300b carry the following metadata respectively: priority (T1) < priority (T2), and priority (T1) = priority (T2). The metadata and the configuration file 400 prepared by the human expert 100 are received at the verification tool 500. The verification tool 500 then performs the corresponding verification by comparing the metadata with the manually prepared configuration file 400.

[0065] Thereafter, the verification tool 500 will indicate the result of the verification and accordingly notify the human expert 100 in case of any unsatisfied constraints and / or conflicts between the constraints. During static verification, the system 200 is not running (inactive).

[0066] The final configuration, i.e., once the verification tool 500 returns a positive verification to the human expert 100, the configuration is sent to the system 200, i.e., the system 200 is configured according to the configuration file 400.

[0067] Figure 4 illustrates the process of automatic generation of a scheduling configuration according to another embodiment of the present disclosure. In particular, Figure 4Shows system 200, service A 300a, service B 300b, configuration file 400, and automation configuration tool 600.

[0068] Automation configuration tool 600 receives the metadata carried by services 300a and 300b, automatically generates combinations in terms of scheduling that satisfy the constraints (metadata) of the required services 300a and 300b, and generates a scheduling configuration (configuration file 400) based on the metadata of all the used services 300a and 300b. Then, system 200 is automatically configured with services 300a and 300b based on configuration file 400.

[0069] Figure 5 Illustrates a dynamic verification process that performs runtime verification of scheduling metadata according to an embodiment of the present disclosure. In particular, Figure 5 Shows human expert (system integration expert) 100, system 200, service A 300a, service B 300b, configuration file 400, execution log 700, and monitoring tool 800 (also referred to as dynamic verification tool 800).

[0070] Services 300a and 300b are incorporated into system 200. For all scheduling-related information, the actual execution of system 200 configured with services 300a and 300b is observed. First, the observed information is captured in execution log file 700.

[0071] Then, monitoring tool 800 analyzes execution log file 700 to check for any violations of scheduling constraints. In particular, monitoring tool 800 receives services 300a and 300b, especially their metadata, and receives execution log file 700, and checks for possible violations of the scheduling constraints specified by the metadata. That is, execution tool 800 is used to perform runtime verification of scheduling metadata to detect any violations of any scheduling-related constraints included in the scheduling metadata of at least one of the required services 300a and 300b. Then, monitoring tool 800 will indicate the result of the verification and notify system expert 100 whether any violations of the constraint requirements are detected. During dynamic verification, system 200 runs to collect execution data (while active).

[0072] Once the global scheduling configuration is ready (whether manually or automatically), a mechanism (API) is provided that allows services to query the final characteristics of their threads at runtime so that the services can create and set these characteristics accordingly.

[0073] It should be understood that the present disclosure is not limited by the number of services described in the foregoing embodiments. Additionally, the present disclosure is not limited by the number of tasks that each service can provide. Although the number of tasks was described above as being equal between Service A and Service B, it is obvious that the number of tasks can also be different between Service A and Service B. The same applies to the number of characteristics (constraints) associated with each task, that is, the present disclosure covers any number of characteristics for tasks.

[0074] Each of the aforementioned verification tool 500, automation configuration tool 600, and monitoring tool 800 can be implemented using software and / or hardware components.

[0075] For example, each of the aforementioned verification tool 500, automation configuration tool 600, and monitoring tool 800 can be implemented by a processor configured to perform any of the above functions.

[0076] Figure 6 A flowchart of a method according to an embodiment of the present disclosure is shown. Figure 6 The method shown in can be used to integrate at least one composable service into a system of composable services and includes the following steps:

[0077] Step 601: Package scheduling metadata with at least one composable service, where the scheduling metadata includes scheduling-related constraints for each of the at least one composable service.

[0078] Step 602: Integrate at least one composable service into a system of composable services based on the scheduling metadata.

[0079] In an embodiment, integrating at least one composable service into a system of composable services based on the scheduling metadata includes: performing static verification and / or automatic generation and / or dynamic verification using the scheduling metadata.

[0080] In an embodiment, the packaging of the scheduling metadata includes including the scheduling metadata in the source file of each of the at least one composable service or attaching the scheduling metadata to a binary package distributed via a package distribution mechanism.

[0081] In an embodiment, the scheduling metadata includes one or more constraints related to one or more schedulable entities, such as relative thread priority, scheduling policy, CPU affinity, or cache partitioning, etc.

[0082] In an embodiment, performing static verification using the scheduling metadata includes: preparing a scheduling configuration for at least one composable service within a system of composable services; where the prepared scheduling configuration can be executed by the system of composable services.

[0083] In an embodiment, using scheduling metadata for static verification further includes: verifying, via a verification tool, whether a prepared scheduling configuration satisfies all scheduling-related constraints included in the scheduling metadata; and indicating the result of the verification.

[0084] In an embodiment, using scheduling metadata for automatic generation includes: automatically combining, via an automated configuration tool, the scheduling metadata of at least one combinable service to generate a global scheduling configuration that satisfies the scheduling-related constraints included in the scheduling metadata of the at least one combinable service.

[0085] In an embodiment, using scheduling metadata for dynamic verification includes: performing, via an execution tool, runtime verification of the scheduling metadata to detect whether there is a violation of any scheduling-related constraint included in the scheduling metadata of at least one combinable service; and indicating the result of the verification.

[0086] Figure 7 System 200 according to an embodiment of the present disclosure is shown. System 200 can be used to integrate at least one combinable service into a system of combinable services. System 200 includes a processor 201 configured to integrate at least one combinable service received from a computer-readable medium into a system for at least one combinable service based on scheduling metadata.

[0087] In an embodiment, the computer-readable medium includes at least one combinable service, and the at least one combinable service includes packaged scheduling metadata, where the scheduling metadata includes scheduling-related constraints for each combinable service in the at least one combinable service.

[0088] In an embodiment, system 200 includes an automated configuration tool configured to: receive the scheduling metadata packaged with each combinable service in the at least one combinable service; combine the scheduling metadata packaged with each combinable service in the at least one combinable service; and generate a scheduling configuration for at least one combinable service within the system of combinable services, where the scheduling configuration can be executed by the system of combinable services.

[0089] In an embodiment, system 200 further includes: a static verification tool configured to: receive a scheduling configuration of at least one combinable service; receive the scheduling metadata packaged with each combinable service in the at least one combinable service; verify whether the scheduling configuration satisfies all scheduling-related constraints included in the scheduling metadata; and indicate the result of the verification.

[0090] In an embodiment, system 200 further includes: a dynamic verification tool configured to: receive scheduling metadata packaged with each of at least one composable service; receive an execution log file, wherein the execution log file includes scheduling-related information of the actual execution from a system configured with the service; and perform runtime verification of the scheduling metadata based on the scheduling metadata and the execution log file to detect any violation of any scheduling-related constraint included in the scheduling metadata of the at least one composable service.

[0091] The dynamic verification tool and / or the static verification tool and / or the automated configuration tool may be provided as components separate from system 200. Each of the dynamic verification tool and / or the static verification tool and / or the automated configuration tool may include a processor configured to perform the above functions.

[0092] Although various embodiments of the present disclosure have been described above, it should be understood that these embodiments are presented by way of example and not by way of limitation. Similarly, the various figures may depict example architectures or configurations provided to enable those of ordinary skill in the art to understand the exemplary features and functions of the present disclosure. However, those of ordinary skill in the art should understand that the present disclosure is not limited to the illustrated example architectures or configurations, but may be implemented using various alternative architectures and configurations. Additionally, as those of ordinary skill in the art will understand, one or more features of one embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of the present disclosure should not be limited by any of the above exemplary embodiments.

[0093] It should also be understood that any reference in this document to elements by names such as "first", "second", etc. generally does not limit the number or order of those elements. Rather, these names may be used herein as a convenient way to distinguish between two or more elements or instances of elements. Thus, the reference to a first and a second element does not mean that only two elements may be employed, or that the first element must precede the second element in some manner.

[0094] Additionally, those of ordinary skill in the art will understand that any of a variety of different techniques and methods may be used to represent information and signals. For example, data, instructions, commands, information, signals, bits, and symbols (e.g., as may be mentioned in the above description) may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0095] Those skilled in the art will further appreciate that any of the various illustrative logical blocks, units, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., digital implementations, analog implementations, or combinations thereof), firmware, various forms of programs or design code containing instructions (which may be referred to herein for convenience as "software" or "software units"), or any combination of these technologies.

[0096] To clearly illustrate this interchangeability of hardware, firmware, and software, the various illustrative components, blocks, units, circuits, and steps have been described generally above in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these technologies, depends on the particular application and design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in various ways for each particular application, but such implementation decisions do not result in a departure from the scope of the present disclosure. In accordance with various embodiments, a processor, device, component, circuit, structure, machine, unit, etc. can be configured to perform one or more of the functions described herein. The terms "configured to" or "configured for" as used herein with respect to a specified operation or function refer to a processor, device, component, circuit, structure, machine, unit, etc. that is physically constructed, programmed, and / or arranged to perform the specified operation or function.

[0097] In addition, those skilled in the art will understand that the various illustrative logical blocks, units, devices, components, and circuits described herein can be implemented within or performed by an integrated circuit (IC) that may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, or any combination thereof. The logical blocks, units, and circuits can further include antennas and / or transceivers to communicate with various components within a network or within a device. The general-purpose processor can be a microprocessor, but in an alternative, the processor can be any conventional processor, controller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration to perform the functions described herein. If implemented in software, these functions can be stored as one or more instructions or code on a computer-readable medium. Accordingly, the steps of the methods or algorithms disclosed herein can be implemented as software stored on a computer-readable medium.

[0098] In this document, the term "unit" as used herein refers to software, firmware, hardware, and any combination of these components for performing the relevant functions described herein. Additionally, for discussion purposes, the various units are described as discrete units; however, it will be apparent to those of ordinary skill in the art that two or more units may be combined to form a single unit that performs the relevant functions in accordance with embodiments of the present disclosure.

[0099] Furthermore, a memory or other storage device and communication components may be employed in embodiments of the present disclosure. It should be recognized that, for clarity, the embodiments of the present disclosure have been described above with reference to different functional units and processors. However, it is apparent that any suitable functional distribution between different functional units, processing logic elements, or domains may be used without departing from the present disclosure. For example, functions illustrated as being performed by separate processing logic elements or controllers may be performed by the same processing logic element or controller. Thus, the reference to a particular functional unit is only a reference to a suitable device for providing the described function, and does not denote a strict logical or physical structure or organization.

[0100] Various modifications to the described embodiments of the present disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Therefore, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed in the appended claims.

Claims

1. A method for integrating at least one composable service (300a, 300b) into a system (200) of composable services, the method comprising: Packaging (601) scheduling metadata with at least one composable service (300a, 300b), wherein the scheduling metadata includes scheduling-related constraints for each of the at least one composable service (300a, 300b); and Integrating (602) the at least one composable service (300a, 300b) into the system (200) of composable services based on the scheduling metadata; wherein integrating (602) the at least one composable service into the system (200) of composable services based on the scheduling metadata includes at least one of the following operations: (i) Performing static verification using the scheduling metadata, the operation including: Preparing a scheduling configuration for the at least one composable service (300a, 300b) within the system (200) of composable services; wherein the prepared scheduling configuration is executable by the system (200) of composable services, (ii) Performing automatic generation using the scheduling metadata, the operation including: Automatically combining the scheduling metadata of the at least one composable service (300a, 300b) via an automated configuration tool (600) to generate a global scheduling configuration that satisfies the scheduling-related constraints included in the scheduling metadata of the at least one composable service, or (iii) Performing dynamic verification using the scheduling metadata, the operation including: Performing runtime verification of the scheduling metadata via an execution tool (800) to detect whether there is a violation of any scheduling-related constraints included in the scheduling metadata of the at least one composable service (300a, 300b); and Indicating the result of the verification.

2. The method according to claim 1, wherein, The packaging (601) of the scheduling metadata includes: Including the scheduling metadata in the source file of each of the at least one composable service (300a, 300b), or Attaching the scheduling metadata to a binary package distributed via a package distribution mechanism.

3. The method according to claim 1 or 2, Among them, The scheduling metadata includes one or more constraints related to one or more schedulable entities, such as relative thread priority, scheduling policy, CPU affinity, or cache partitioning, etc.

4. The method according to any one of claims 1 to 3, wherein, Performing static verification using the scheduling metadata further includes: Verifying via a verification tool (500) whether the prepared scheduling configuration satisfies all scheduling-related constraints included in the scheduling metadata; and Indicating the result of the verification.

5. A system (200) for at least one composable service, the system (200) comprising: A processor (201), the processor being configured to integrate at least one composable service (300a, 300b) received from a computer-readable medium into the system (200) for at least one composable service based on the scheduling metadata; wherein the computer-readable medium includes: At least one composable service (300a, 300b), said at least one composable service including packaged scheduling metadata; wherein the scheduling metadata includes scheduling-related constraints for each composable service in the at least one composable service (300a, 300b); wherein the system (200) further includes at least one of the following: (i) An automated configuration tool (600), the automated configuration tool being configured to: Receive the scheduling metadata packaged with each composable service in the at least one composable service (300a, 300b); Combine the scheduling metadata packaged with each composable service in the at least one composable service (300a, 300b); and Generate a scheduling configuration for the at least one composable service (300a, 300b) within the system (200) of the composable service, wherein the scheduling configuration is executable by the system (200) of the composable service; (ii) A static verification tool (500), the static verification tool being configured to: Receive the scheduling configuration of the at least one composable service (300a, 300b); Receive the scheduling metadata packaged with each composable service in the at least one composable service (300a, 300b); Verify whether the scheduling configuration satisfies all scheduling-related constraints included in the scheduling metadata, and Indicate the result of the verification; or (iii) A dynamic verification tool (800), the dynamic verification tool being configured to: Receive the scheduling metadata packaged with each composable service in the at least one composable service (300a, 300b); Receive an execution log file (700), wherein the execution log file (700) includes scheduling-related information of the actual execution from the system (200) configured with the service (300a, 300b); Perform runtime verification of the scheduling metadata based on the scheduling metadata and the execution log file (700) to detect any violation of any scheduling-related constraint included in the scheduling metadata of the at least one composable service, and Indicate the result of the verification.

Images