Creation device and creation method

Abstract

A software carbon emission requirement satisfaction plan creation device 10 inputs a carbon intensity utilization specification constraint including a place where software can be executed, creates a deployment schedule including a software execution place for each time period, on the basis of carbon intensity information indicating carbon intensity for each place and each time period, and the place where the software can be executed, calculates carbon emissions on the basis of the power consumption and the carbon intensity when the software is executed according to the deployment schedule, and outputs the software execution place for each time period created according to the deployment schedule when the carbon emissions satisfy a carbon emission requirement.

Description

Generation Apparatus and Generation Method

[0001] The present disclosure relates to a generation apparatus and a generation method.

[0002] Emissions of greenhouse gases including carbon dioxide are recognized as a cause of climate change, and there is a need to reduce such emissions. As ICT technology continues to spread and expand, carbon emissions in the ICT field have also increased. The main source of carbon emissions in the ICT field is power consumption by data centers, and technologies for improving power efficiency have been developed, and power efficiency has been improved through the introduction of such technologies.

[0003] To further reduce carbon emissions derived from power consumption in data centers, utilization of renewable energy is being promoted. Carbon intensity, which means the amount of carbon emissions per unit of power consumption, varies depending on power generation methods, and its value fluctuates depending on time and region. For example, thermal power generation using fossil fuels has high carbon intensity, while solar power generation has low carbon intensity; however, the amount of power generated by solar power generation depends on sunlight, so it fluctuates over time even at the same location. Carbon emissions derived from power consumption are calculated as the product of power consumption and carbon intensity. Therefore, by selecting a time period with low carbon intensity to perform processing, or selecting a location with low carbon intensity to perform processing, carbon emissions can be reduced even when the amount of power consumption required for processing is the same.

[0004] Focusing on fluctuations in carbon intensity depending on time and region, the techniques of Non-Patent Document 1 and Non-Patent Document 2 have been proposed as techniques for reducing carbon emissions when executing software processing.

[0005] Non-Patent Document 1 discloses a technique related to reducing carbon emissions in batch processing. When a completion time is required as a requirement for batch processing, carbon emissions can be reduced by temporarily suspending processing within a range that still satisfies the requirement during time periods when carbon intensity is high. However, since carbon intensity fluctuates gradually over a long period of time, the effect is limited if processing is simply suspended according to carbon intensity. Non-Patent Document 1 proposes a technique for reducing carbon emissions by increasing the allocation amount of computing resources during time periods with low carbon intensity to perform more processing.

[0006] Non-patent document 2 concerns a technology for reducing carbon emissions from serverless applications. A serverless application is an application that starts up and processes data when called from an external source, then waits for a certain period of time for the next call, and terminates if no call occurs during that time. Non-patent document 2 proposes a technology to reduce carbon emissions by considering not only the power consumption during the execution of the serverless application, but also the carbon emissions from the manufacturing and transportation of servers, and by selecting the serverless application's waiting time and the server used for execution according to its carbon intensity.

[0007] Walid A. Hanafy, Qianlin Liang, Noman Bashir, David Irwin, and Prashant Shenoy, "CarbonScaler: Leveraging Cloud Workload Elasticity for Optimizing Carbon-Efficiency," Proc. ACM Meas. Anal. Comput. Syst., December 2023, Vol. 7, No. 3, Article 57Yankai Jiang, Rohan Basu Roy, Baolin Li, and Devesh Tiwari, "EcoLife: Carbon-Aware Serverless Function Scheduling for Sustainable Computing," In Proceedings of the International Conference for High Performance Computing, Networking, Storage, and Analysis (SC '24), IEEE Press, 2024, Article 12, 1-15.

[0008] Conventional technologies all aim to reduce carbon emissions under given conditions such as processing time, waiting time, time constraints until processing is complete, startup frequency, and server selection requirements. These conditions vary depending on the software, and some cannot be changed after application development. In the pursuit of a decarbonized society, if we assume that the carbon emissions of software itself will be defined as a non-functional requirement of the software, then it will be necessary to identify the conditions that the software must satisfy in order to meet the defined carbon emission requirements before development. However, conventional technologies cannot derive these conditions in this backward-working manner.

[0009] This disclosure is made in view of the above and aims to obtain software execution patterns that meet carbon emission requirements.

[0010] A creation device in one aspect of the present disclosure is a creation device for creating software execution patterns that satisfy carbon emission requirements, which inputs constraints including locations where the software can be executed, creates a deployment schedule including software execution locations for each time period based on carbon intensity information indicating carbon intensity for each location and time period and the locations where the software can be executed, calculates carbon emissions based on the power consumption and carbon intensity when the software is executed according to the deployment schedule, and outputs the software execution locations for each time period created according to the deployment schedule if the carbon emissions satisfy the carbon emission requirements.

[0011] According to this disclosure, it is possible to obtain software execution patterns that meet carbon emission requirements.

[0012] Figure 1 shows an example of the configuration of the software carbon emission requirement fulfillment proposal generation device. Figure 2 is a flowchart showing an example of the processing flow of the carbon intensity utilization specification creation unit. Figure 3 is a flowchart showing an example of the processing flow of the deployment plan creation unit. Figure 4 is a flowchart showing an example of the processing plan creation unit. Figure 5 is a flowchart showing an example of the processing flow for creating an online processing type processing plan. Figure 6 is a flowchart showing an example of the processing flow for creating a batch processing type processing plan. Figure 7 is a flowchart showing an example of the processing flow of the result output unit. Figure 8 shows an example of the hardware configuration of the software carbon emission requirement fulfillment proposal generation device.

[0013] [Device Configuration] Referring to Figure 1, an example of the configuration of the software carbon emission requirement fulfillment proposal creation device 10 will be described. The software carbon emission requirement fulfillment proposal creation device 10 comprises a carbon intensity utilization specification creation unit 11, a deployment plan creation unit 12, a processing plan creation unit 13, and a result output unit 14.

[0014] The carbon intensity utilization specification draft creation unit 11 takes the carbon intensity utilization specification constraints related to the software under development as input and creates a carbon intensity utilization specification draft that satisfies the constraints and best utilizes carbon intensity fluctuations. Carbon intensity utilization specification constraints are constraint conditions that must be satisfied with respect to the specifications of the software under development that relate to the utilization of carbon intensity fluctuations. For example, carbon intensity utilization specification constraints include whether or not the deployment location (also called the execution location) can be changed while the software is running, whether or not processing can be interrupted while the software is running, and a list of locations where the software can be deployed.

[0015] An example of the data structure for the carbon strength utilization specification constraints and the proposed carbon strength utilization specification is shown below. Note that the notation of the data structure follows the conventional notation for sets. That is, R (double-lined R) is a real number, N (double-lined N) is a natural number, B (double-lined B) is a set of truth values, A×B is the Cartesian product of A and B, A|B is the direct union of A and B, 2 A represents the power set of A.

[0016]

[0017] The carbon strength utilization specification constraints are either online processing or batch processing. The difference between online and batch processing is whether or not processing can be interrupted. In online processing applications, which perform short processing for each request and respond immediately, the concept of processing interruption does not exist.

[0018] Online processing specifications describe the specifications for applications that wait for processing requests and perform immediate processing in response to those requests. Online processing specifications consist of whether the deployment location can be changed and a list of possible deployment locations.

[0019] Batch processing specifications describe the requirements for applications that take a long time to complete in a single execution, such as routine processing of large amounts of data. Batch processing specifications consist of whether processing can be interrupted, whether the deployment location can be changed, and a list of possible deployment locations.

[0020] The "Deployment Location Changeability" parameter is a truth value that indicates whether software, once deployed and executed at a designated location, can be redeployed to a different location. In other words, it indicates whether the deployment location can be changed while the software is running.

[0021] The "Cancel Processing" status is a truth value that indicates whether or not it is possible to temporarily suspend the software's execution and then resume it later.

[0022] The deployment location ID is an identifier that identifies the geographical location of the server running the software, and can be in any format, such as an integer or a string.

[0023] The proposed carbon intensity utilization specification is one of the specifications for the software under development that relates to the utilization of carbon intensity fluctuations. The proposed carbon intensity utilization specification sets values ​​for specifications that were not input externally as carbon intensity utilization specification constraints, and therefore has the same structure as the carbon intensity utilization specification constraints.

[0024] The deployment plan creation unit 12 takes the carbon intensity utilization specification proposal and carbon intensity information as input and creates a deployment plan proposal that determines the deployment location of the application for each time period from the deployable locations indicated in the carbon intensity utilization specification proposal. In particular, for applications whose deployment location can be changed during execution, the deployment plan creation unit 12 creates a deployment plan proposal that deploys the application to the location with the lowest carbon intensity for each time period.

[0025] An example of the data structure for carbon intensity information is shown below. The carbon intensity information is input from an external source. The data input from the external source may be stored in the device's storage means.

[0026]

[0027] Carbon intensity information is a data structure that represents the carbon intensity for each deployment location at different times of the day. The carbon intensity values ​​for each time period are obtained by methods such as calculating the average over a certain period from past performance data. The carbon intensity values ​​do not necessarily have to be statistically processed from actual data; they may be obtained using any means, such as simulations based on some model.

[0028] The time zones are periods obtained by dividing the day into equal parts using any natural number, and each is represented by assigning a natural number as an identifier. Since the carbon intensity used to calculate carbon emissions is not obtained as an exact value in fine time units such as seconds or minutes, but is generally published as a value in units of several tens of minutes to one hour, this embodiment uses a structure that represents that the carbon intensity fluctuates for each time zone divided into fixed time intervals.

[0029] An example of the data structure for the proposed deployment plan is shown below.

[0030]

[0031] The deployment plan is a data structure that represents the deployment schedule of applications for each time period. The deployment schedule may also include carbon intensity information for each time period.

[0032] The processing plan creation unit 13 takes the proposed carbon intensity utilization specifications, deployment plan, power consumption model, and processing volume information as input and creates a processing plan regarding deployment locations and processing volumes for each time period from the perspective of reducing carbon emissions. The processing plan creation unit 13 also outputs the carbon emissions in the said processing plan. Carbon emissions are calculated as the product of carbon intensity and power consumption, and since power consumption increases according to the processing volume, the processing plan creation unit 13 should create a processing plan that processes more during times when carbon intensity is low.

[0033] An example of the data structure for a power consumption model is shown below.

[0034]

[0035] The power consumption model is represented as a function that takes throughput as input and power consumption as output. Throughput is a real number representing the amount of processing per unit time. The power consumption model in this embodiment is a simplified model as an example, and a more complex model may be used.

[0036] An example of the data structure for processing volume information is shown below.

[0037]

[0038] Processing volume information represents information about the amount of processing that the software is required to do while it is running.

[0039] Online processing volume information is represented as a function that takes a time period as input and outputs the processing volume. In online processing applications, processing requests are required to be processed immediately, so the processing volume depends on the amount of processing requests which fluctuates from time to time.

[0040] Batch processing volume information is represented by a pair of the total amount of processing to be executed and the start and end times for which that processing can be performed. Batch processing applications often require processing to be completed within a specified time range, and the start and end times represent this time range. To represent the case where neither the start nor end time is specified, the value ε can be set.

[0041] An example of the data structure of a processing plan is shown below.

[0042]

[0043] The processing plan indicates throughput (which may also be processing volume) for each time slot and each location, and is configured as a set of real numbers representing a time slot, a placement location ID, and throughput.

[0044] The result output unit 14 receives, as inputs, a carbon intensity utilization specification draft, a processing plan draft, the carbon emission amount of said processing plan draft, and carbon emission amount requirements, selects a processing plan draft that satisfies the carbon emission amount requirements, and generates a carbon emission amount requirement satisfaction draft.

[0045] An example of the data structure of carbon emission amount requirements is shown below.

[0046]

[0047] The carbon emission amount requirement is a real number representing the allowable amount of carbon emission per day for software. The carbon emission amount requirement is not limited to the above, and may be a requirement in another format such as the maximum value of carbon emission per unit time.

[0048] An example of the data structure of a carbon emission amount requirement satisfaction draft is shown below.

[0049]

[0050] The carbon emission amount requirement satisfaction draft is a set of a carbon intensity utilization specification draft and a processing plan draft that satisfy the carbon emission amount requirements. To represent the case where the carbon emission amount requirements cannot be satisfied due to constraints of various inputs, ε can be set as the value.

[0051] [Processing of Each Unit of the Apparatus] With reference to the flowchart of FIG. 2, an example of processing performed by the carbon intensity utilization specification draft generation unit 11 will be described.

[0052] In step S11, the carbon intensity utilization specification draft generation unit 11 inputs the carbon intensity utilization specification constraints for the application to be processed, duplicates the carbon intensity utilization specification constraints, and uses one of the duplicates as the carbon intensity utilization specification draft.

[0053] In step S12, the carbon strength utilization specification creation unit 11 refers to the carbon strength utilization specification constraints and determines whether the application to be processed is an online processing type or a batch processing type.

[0054] If the application is batch processing type, in step S13, the carbon strength utilization specification creation unit 11 sets whether processing can be interrupted. Specifically, if a value has already been set for whether processing of the carbon strength utilization specification can be interrupted, the carbon strength utilization specification creation unit 11 maintains that value, and if no value has been set, it sets it to "True" to indicate that processing can be interrupted.

[0055] In step S13, the carbon strength utilization specification creation unit 11 sets whether the deployment location can be changed. Specifically, if a value has already been set for whether the deployment location of the carbon strength utilization specification can be changed, the carbon strength utilization specification creation unit 11 maintains that value, and if no value has been set, it sets it to "True" to indicate that the deployment location can be changed.

[0056] Next, referring to the flowchart in Figure 3, an example of the processing by the deployment plan creation unit 12 will be explained.

[0057] In step S21, the deployment plan creation unit 12 inputs the carbon strength utilization specification draft and carbon strength information. The carbon strength utilization specification draft is input from the carbon strength utilization specification creation unit 11, and the carbon strength information is input from an external source.

[0058] In step S22, the deployment plan creation unit 12 extracts carbon intensity information for each deployment location from the carbon intensity information for each deployment location, for which the deployment location ID is included in the list of deployable locations included in the carbon intensity utilization specification proposal.

[0059] In step S23, the deployment plan creation unit 12 refers to the carbon strength utilization specification proposal and determines whether or not the deployment location can be changed.

[0060] If the deployment location can be changed, in step S24, the deployment plan creation unit 12 searches for the deployment location with the minimum carbon intensity for each time period from the list of carbon intensity information extracted in step S22 and creates a deployment schedule. If the deployment location can be changed, the best deployment schedule with the minimum carbon intensity for each time period is obtained.

[0061] If the deployment location cannot be changed, in step S25, the deployment plan creation unit 12 creates a deployment schedule corresponding to each of the carbon intensity information entries extracted in step S22. If the deployment location cannot be changed, multiple deployment schedules for locations where the application can be deployed are obtained.

[0062] The deployment plan creation unit 12 lists the deployment schedules created in step S24 or step S25 and outputs a deployment plan.

[0063] Next, referring to the flowchart in Figure 4, an example of the processing plan creation unit 13 will be explained.

[0064] In step S31, the processing plan creation unit 13 receives input for the carbon strength utilization specification, deployment plan, power consumption model, and processing volume information. The carbon strength utilization specification is input from the carbon strength utilization specification creation unit 11, and the deployment plan is input from the deployment plan creation unit 12. The power consumption model and processing volume information are input from an external source.

[0065] In step S32, the processing plan creation unit 13 refers to the carbon strength utilization specification proposal and determines whether the application to be processed is an online processing type or a batch processing type.

[0066] In the case of online processing, in step S33, the processing plan creation unit 13 creates an online processing plan.

[0067] In the case of batch processing, in step S34, the processing plan creation unit 13 creates a batch processing type processing plan.

[0068] Details on creating draft processing plans for each processing type will be described later.

[0069] In step S35, the processing plan creation unit 13 outputs the processing plan and carbon emissions. The processing plan creation unit 13 also determines carbon emissions when creating the processing plan.

[0070] Referring to the flowchart in Figure 5, an example of the process for creating an online processing plan will be explained. In creating an online processing plan, for each deployment schedule of the deployment plan, carbon emissions are calculated from the carbon intensity per time period and the processing volume per time period included in the processing volume information, and the processing plan that minimizes carbon emissions is searched for.

[0071] In step S331, the processing plan creation unit 13 calculates the power consumption for each time period. The power consumption for each time period can be determined by obtaining the processing volume for each time period from online processing volume information and applying the processing volume for each time period to the power consumption model.

[0072] The processing plan creation unit 13 repeats the following steps S332 and S333 for all deployment schedules.

[0073] In step S332, the processing plan creation unit 13 calculates the carbon emissions for each time period by accumulating the power consumption for each time period and the carbon intensity for each time period in the deployment schedule, and then calculates the daily carbon emissions by summing them up. The carbon intensity for each time period can be obtained from the time period carbon intensity information corresponding to the deployment location ID in the deployment schedule and the deployment location ID in the carbon intensity information.

[0074] In step S333, if the carbon emissions calculated in step S332 are smaller than the carbon emissions calculated so far, the processing plan creation unit 13 sets these carbon emissions as the minimum carbon emissions and sets the deployment locations and throughput for each time period as a processing plan according to the deployment schedule. The processing plan includes the processing volume for each time period obtained from online processing volume information.

[0075] Referring to the flowchart in Figure 6, an example of the process for creating a batch-type processing plan will be explained. The method for creating a batch-type processing plan differs depending on whether the processing can be interrupted or not. If interruption is possible, a processing plan is created by selecting time periods with low carbon intensity within the range where processing can be completed. If interruption is not possible, processing must be done over continuous time periods, so the optimal processing plan is searched for using a different method than when interruption is possible.

[0076] In step S341, the processing plan creation unit 13 calculates the throughput value that maximizes power efficiency from the power consumption model, using the power consumption divided by throughput as the power efficiency, and then divides the total processing volume of processing volume information by this throughput value to determine the processing time when processing is performed at maximum power efficiency. This processing time can be said to be the processing time required for batch processing.

[0077] In step S342, the processing plan creation unit 13 refers to the carbon strength utilization specification proposal and determines whether the software to be processed can interrupt the processing that is currently running.

[0078] If interruption is possible, the processing plan creation unit 13 repeats the following steps S343 to S346 for all deployment schedules.

[0079] In step S343, the processing plan creation unit 13 rearranges the time slots in the deployment schedule in order of increasing carbon intensity.

[0080] In step S344, the processing plan creation unit 13 extracts the minimum time period exceeding the processing time determined in step S341, in order of increasing carbon intensity. However, if a start and end time limit is set in the processing volume information, the extraction is limited to time periods within that limit.

[0081] In step S345, the processing plan creation unit 13 increases the throughput during periods of low carbon intensity and decreases the processing time during periods of high carbon intensity if it determines that carbon emissions can be reduced by performing more processing during periods of low carbon intensity. The amount of processing that should be transferred can be calculated from the ratio of the increase in throughput and the increase in power consumption in the power consumption model, and the ratio of the change in carbon intensity in both periods.

[0082] In step S346, the processing plan creation unit 13 calculates the carbon emissions for each time period by integrating the power consumption for each time period with the carbon intensity for each time period in the deployment schedule, and then calculates the daily carbon emissions by summing them up. The power consumption for each time period can be determined by applying the processing amount for each time period set in step S345 to the power consumption model. If the calculated carbon emissions are smaller than the carbon emissions for other deployment schedules calculated so far, the processing plan creation unit 13 sets these carbon emissions as the minimum carbon emissions and sets the deployment locations and throughput for each time period as a processing plan proposal according to the deployment schedule.

[0083] If interruption is not possible, the processing plan creation unit 13 repeats the following steps S347 to S349 for all deployment schedules.

[0084] In step S347, the processing plan creation unit 13 extracts the minimum number of consecutive time slots from the deployment schedule that exceed the processing time calculated in step S341, and arranges them as processing time slot candidates in descending order of carbon intensity. However, if a start and end time for processing is set in the processing volume information, the system is limited to time slots within that time limit. In addition, combinations that are clearly worse than others may be excluded from the processing time slot candidates. For example, if the carbon intensity value of one combination of time slots is higher than that of the other in all time slots, the combination with the higher carbon intensity is excluded from the processing time slot candidates.

[0085] The processing plan creation unit 13 repeats the following steps S348 to S349 for all candidate processing time slots.

[0086] In step S348, the processing plan creation unit 13 increases the throughput during periods of low carbon intensity and decreases the processing time during periods of high carbon intensity if it determines that carbon emissions can be reduced by performing more processing during periods of low carbon intensity. The amount of processing that should be transferred can be calculated from the ratio of the increase in throughput and the increase in power consumption in the power consumption model, and the ratio of the change in carbon intensity in both periods.

[0087] In step S349, the processing plan creation unit 13 calculates the carbon emissions for each time period by integrating the power consumption for each time period and the carbon intensity for each time period in the deployment schedule, and then calculates the daily carbon emissions by summing them up. The power consumption for each time period can be determined by applying the processing amount for each time period set in step S348 to the power consumption model. If the calculated carbon emissions are smaller than the carbon emissions for other deployment schedules calculated so far, the processing plan creation unit 13 sets these carbon emissions as the minimum carbon emissions and sets the deployment locations and throughput for each time period as a processing plan proposal according to the deployment schedule.

[0088] Referring to the flowchart in Figure 7, an example of the processing of the result output unit 14 will be explained.

[0089] In step S41, the result output unit 14 receives input for the proposed carbon intensity utilization specifications, proposed treatment plan, carbon emissions, and carbon emission requirements. The proposed carbon intensity utilization specifications are input from the carbon intensity utilization specification creation unit 11, the proposed treatment plan and carbon emissions are input from the proposed treatment plan creation unit 13, and the carbon emission requirements are input from an external source.

[0090] In step S42, the result output unit 14 creates a proposal to satisfy the carbon emission requirements. Specifically, the result output unit 14 compares the carbon emissions with the carbon emission requirements. If the carbon emissions are lower, the set of carbon intensity utilization specification proposal and treatment plan proposal is designated as the proposal to satisfy the carbon emission requirements. If the carbon emissions are higher, ε is designated as the proposal to satisfy the carbon emission requirements, indicating that there is no proposal that satisfies the carbon emission requirements.

[0091] In step S43, the result output unit 14 outputs a proposal for satisfying the carbon emission requirements.

[0092] As described above, the software carbon emission requirement satisfaction preparation device 10 of this embodiment takes carbon intensity utilization specification constraints, including locations where the software can be executed, as input, creates a deployment schedule including software execution locations for each time period based on carbon intensity information indicating carbon intensity for each location and time period, and locations where the software can be executed, calculates carbon emissions based on power consumption and carbon intensity when the software is executed according to the deployment schedule, and outputs the software execution locations for each time period created according to the deployment schedule if the carbon emissions satisfy the carbon emission requirements. This makes it possible to obtain software execution patterns that satisfy carbon emission requirements at any point, including before software development. By using this output result, when carbon emission requirements are defined at the requirements definition stage, it is possible to design and implement software that satisfies those requirements, and to improve implemented software to satisfy those requirements.

[0093] In this embodiment, the carbon intensity utilization specification constraint includes whether or not the deployment location can be changed while the software is running. If the deployment location can be changed while the software is running, a deployment schedule is created in which the location with the lowest carbon intensity for each time period is used as the software's deployment location.

[0094] In this embodiment, the software is either an online processing type or a batch processing type. For the batch processing type, the carbon intensity utilization specification constraint maintains whether processing can be interrupted while the software is running. If processing can be interrupted while the software is running, time slots are acquired in descending order of carbon intensity within the time slots included in the deployment schedule, up to the time it takes for the software to process. If processing cannot be interrupted while the software is running, the combination with the lowest carbon intensity among consecutive time slots included in the deployment schedule that exceed the time it takes for the software to process is acquired.

[0095] Thus, this embodiment focuses on the fact that the degree to which carbon emissions can be reduced by utilizing fluctuations in carbon intensity differs depending on the software specifications and requirements to be met, and can explore execution patterns that can maximize the use of low-carbon intensity electricity under given constraints.

[0096] The software carbon emission requirement fulfillment proposal creation device 10 described above can use, for example, a general-purpose computer system as shown in Figure 8, which includes a central processing unit (CPU) 901, memory 902, storage 903, communication device 904, input device 905, and output device 906. In this computer system, the software carbon emission requirement fulfillment proposal creation device 10 is realized when the CPU 901 executes a predetermined program loaded onto the memory 902. This program can be recorded on a computer-readable non-temporary recording medium such as a magnetic disk, optical disk, or semiconductor memory, or it can be distributed via a network.

[0097] 10 Software carbon emission requirement fulfillment proposal generation device 11 Carbon intensity utilization specification generation unit 12 Deployment plan generation unit 13 Processing plan generation unit 14 Result output unit

Claims

1. A creation device for creating software execution patterns that meet carbon emission requirements, comprising: inputting constraints including locations where the software can be executed; creating a deployment schedule including software execution locations for each time period based on carbon intensity information indicating carbon intensity for each location and time period and the locations where the software can be executed; calculating carbon emissions based on power consumption and carbon intensity when the software is executed according to the deployment schedule; and outputting the software execution locations for each time period created according to the deployment schedule if the carbon emissions meet the carbon emission requirements.

2. A creation device according to claim 1, wherein the constraint holds a value indicating whether or not the execution location can be changed while the software is running, and if the execution location can be changed while the software is running, the creation device creates a deployment schedule in which the location with the lowest carbon intensity for each time period is the execution location of the software.

3. A manufacturing apparatus according to claim 1 or 2, wherein the constraint holds a value indicating whether or not processing can be interrupted while the software is running, and if processing can be interrupted while the software is running, the time periods included in the deployment schedule are acquired in order of decreasing carbon intensity until the time required for processing the software is exceeded, and if processing cannot be interrupted while the software is running, the combination of consecutive time periods included in the deployment schedule that exceeds the time required for processing the software has the lowest carbon intensity.

4. A method for creating software execution patterns that meet carbon emission requirements, the method comprising: a computer inputting constraints including locations where the software can be executed; creating a deployment schedule including software execution locations for each time period based on carbon intensity information indicating carbon intensity for each location and time period and the locations where the software can be executed; calculating carbon emissions based on the power consumption and carbon intensity when the software is executed according to the deployment schedule; and, if the carbon emissions meet the carbon emission requirements, outputting the software execution locations for each time period created according to the deployment schedule.

Images