JP2002157037A - License management method and system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a license management method and system capable of automating the license management of software and surely executing a requested processing. SOLUTION: This license management method and system comprises a request accept control part 1 for registering a request; a request cue 2 for cuing the registered request; a request execution control part 5 for reading the request from the request cue 2, judging whether it is executable or not, and controlling the execution of the software; a job dependent relation control part 6 for controlling the dependent relation of the request; a software execution part 9 for executing the software; and a license management part 7 for performing the license management of the software.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] The present invention relates to a license management method and a license management system for software used on a network. Here, the license is a right to use a certain tool (software and hardware).

[0002]

2. Description of the Related Art CAD (Computer Aided Desert) used in LSI design and software development.
ign: computer-aided design) or CASE (Comp
uter Aided Software Engne
(supporting system development by software engineering using a computer) is generally controlled by a license. However, if a license cannot be obtained, the requested processing is not performed. It ends. Therefore, the software performs incomplete processing.

[0003]

As a prior art, several methods for controlling license management acquisition have been proposed. Japanese Patent Application No. 7-34875 discloses a software license management method, but cannot control when a plurality of licenses exist for the same software.
Further, it is not possible to obtain a license in accordance with the execution order of a plurality of software that makes sense for execution control. Execution of CAD software used in LSI design requires execution control based on the order of the design flow. Also, when a series of processes is executed with the highest priority, the requests are individually requested, so that the processes are performed in the order in which they are requested, and a series of related processes to be preferentially executed cannot be executed with the highest priority.

Japanese Patent Application No. 8-305560 discloses a license management method for grouping a series of execution steps of job steps constituting a job and collectively acquiring licenses of a plurality of software corresponding to the job steps. ing. Thus, the entire job is efficiently executed without waiting for execution of a plurality of processing steps that are meaningful in a group.

[0005] However, this method has the following problems. Batch acquisition of licenses as a group of jobs
If the processing often requires a long time, such as CAD software for LSI design support, the serial execution of job steps increases the unused time of the license, and conversely, the license cannot be operated efficiently.

[0006] As in the case of CAD software, license sharing management in the case of having a plurality of different processing functions of the same license program is not considered. That is, the license is shared, and the order relation of the job steps cannot be expressed as another step.

In order to efficiently execute long-time processing, it is necessary to operate job steps in parallel. However, a plurality of job steps of the same processing function of the same license program are operated in parallel, and the process is waited for until these steps are completed. Therefore, the license and the job for executing the job step to be executed next cannot be controlled.

Japanese Patent Application Laid-Open No. 10-171662 considers the dependencies of the files constituting one application, but the purpose of the present invention is to control the dependencies of the execution order of a plurality of applications. is necessary. Also, in JP-A-11-237988,
The present invention is characterized in that the dependency of instructions in parallel processing in software development is determined, but the present invention is characterized in that a license is issued based on the dependency when a series of processing using a plurality of applications is performed, and execution of the processing is performed. It is necessary to control them in association with each other.

SUMMARY OF THE INVENTION The present invention has been made in view of the above problems, and has an object to automate software license management, execute a requested process without fail, and make full use of the number of licenses of each tool owned. The purpose of the present invention is to provide a license management method and a license management system in which a system automatically performs a process dependent on a process flow represented by an LSI or the like, and a user can reliably obtain a result only by requesting a process. I have.

[0010]

FIG. 1 is a flowchart showing the principle of the method of the present invention. The present invention relates to a method for managing a license of a job composed of a plurality of software job steps, wherein the order dependency of the job steps is expressed by a start condition for each job step (step 1), and the start condition of each job step is used. Confirm that the execution of another job step has been completed (Step 2), determine whether or not the job step can be executed (Step 3), and sequentially acquire software licenses for the job step (Step 4). It is characterized by.

With this configuration, software license management can be automated. In the present invention, the order dependency of the job steps is expressed by start / end conditions for each job step, and the end of execution of each job step is used as a trigger to determine the next job step to be executed. The license of the software corresponding to is acquired sequentially.

With this configuration, the system can automatically perform a process dependent on a process flow represented by an LSI or the like. Further, in the present invention, a request reception control unit for registering a request, a request queue for queuing the registered request, and extracting a request from the request queue,
A request execution control unit that determines whether execution is possible and controls execution of software, a job dependency control unit that controls dependency of requests, a software execution unit that executes software, and manages licenses of software. And a license control unit.

With this configuration, software license management can be automated. Further, in the present invention, the job step identifies different processing functions of the same software whose use is controlled based on the same license as separate processing steps, and controls the order dependency of processing and license acquisition. Features.

With this configuration, the system can automatically perform a process depending on a process flow represented by an LSI or the like. Further, in the present invention, the job step identifies a plurality of job steps of the same processing function of the same software, the use of which is controlled based on the same license, as separate processing steps. It is characterized by controlling.

With this configuration, it is possible to automate the processing depending on the processing flow represented by the LSI or the like by the system. Further, in the present invention, it is assumed that a plurality of job steps of the same processing function of the same software are executed in parallel, and it is confirmed that all the job steps executed in parallel have been completed, and a job to be executed next is executed. A step is determined, and a license of software corresponding to the job step is sequentially acquired.

With this configuration, it is possible to reliably execute the requested processing.

[0017]

Embodiments of the present invention will be described below in detail with reference to the drawings. Generally, a plurality of software licenses exist in one management environment (license server). Considering the case where multiple licenses exist in one management environment, even if there are multiple requests to the same tool, it is possible to process multiple requests in parallel as long as it is within the number of available licenses have.

The number of available licenses can be set by the system administrator, and is the maximum number of licenses owned.
The dependency of the processing is included in the request content, and the user does not need to request the processing in the execution order, the system automatically manages the processing, and issues a license as necessary.

The features of the present invention are as follows. (A) Consider that a plurality of licenses exist for one piece of software. When the execution of the requested processing is started, the processing of the next request is started, and the same software can be operated in parallel by one license server for the number of licenses.

(B) In consideration of the dependency of a plurality of requested processes, for example, when a job (Job) 2 is operated,
Consider an execution order that presupposes that job 1 has been completed. For example, when considering the logic synthesis processing of an LSI, the execution order is as follows. Compile package Compile VHDL source Map to Netlist Netlist output Here, VHDL is a hardware design language.
Elist is a method of expressing hardware. As described above, the control unit recognizes the execution order control in a case where it is necessary to execute a series of processes according to different requests in order, and issues a license as necessary.

(C) Priority processing of a series of requests to be processed with priority can be performed, and a processing order that does not depend on the order of requests can be specified. In the present invention, the requested processing is queued, and the execution of one piece of software can be executed for the number of available licenses. In addition, it controls dependent requests, issues a series of licenses in order not only in the order in which the requests were made, but also in accordance with the start condition of the request to be executed, and activates the next process preferentially in accordance with the end condition. It is possible to specify the license acquisition of the process to be performed.

This makes it possible to use the licenses owned by the user efficiently, and to set up necessary items, rather than managing the order of those having dependencies on processes represented by the LSI design flow and the like. By submitting it, management in the system becomes possible. Also, priority processing can be performed regardless of the order in which a series of requests that are to be prioritized over other requests are requested.

The general procedure from logic synthesis to placement and routing in the development of an LSI using VHDL is as follows. VHDL reading Mapping to technology (parallel processing in module unit) Assembling of chip (CHIP) Test circuit generation Arrangement and wiring The same logic synthesis tool is used for above.
Is a test circuit generation tool, and is a layout tool. Here, these are referred to as job steps.

In the process (1), when there are three modules to be processed, the designer requests the process as follows. Here, the numbers up to are the same as those in the drawings, but only 10 is shown as ○ 10. VHDL reading → mapping (1) → mapping (2) → mapping (3) → chip assembly → test circuit generation → placement and wiring FIG. 2 is a diagram showing an LSI development flow, in which user 1 processes (flow 1) and user 2 shows a process (flow 2). In the flow of the user 1, first, VHDL is read (), and mapping processing is performed (). Here, mapping (1) indicates mapping (2), and mapping (3) indicates.

Next, chip assembly is performed (), test circuit generation is performed (), and placement and wiring are performed (○ 1).
0). In the flow of the user 2, a chip is assembled (), a test circuit is generated (), and arrangement and wiring are performed ().

That is, each step is composed of job steps as indicated by ○ 10. The queue contains
Request processing to the request queue is arranged as shown in FIG. In the figure, the job steps from の to １０10 are arranged. The part indicated by → in the figure indicates the dependency.
For example, a job step has a dependency relationship with a job step, and a job step has a request relationship with a job step. As shown in FIG. 4, the order in which licenses are issued to tools when this system is used is sequentially executed in consideration of the dependence of requests and the number of licenses of tools.

As described above, according to the present invention, in the job step, different processing functions of the same software whose use is controlled based on the same license are identified as separate processing steps. You can control license acquisition.

With this configuration, the system can automatically perform processing dependent on a processing flow represented by an LSI or the like. Further, in the present invention, the job step identifies a plurality of job steps of the same processing function of the same software, the use of which is controlled based on the same license, as separate processing steps. Can be controlled.

With this configuration, the system can automate the processing depending on the processing flow represented by the LSI or the like. Further, in the present invention, it is assumed that a plurality of job steps of the same processing function of the same software are executed in parallel, and it is confirmed that all the job steps executed in parallel have been completed, and a job to be executed next is executed. The step can be determined, and the license of the software corresponding to the job step can be acquired sequentially.

With this configuration, it is possible to reliably execute the requested processing. Figure 4 shows the job (JOB)
It is a figure showing an example of an execution history. Hereinafter, the execution history of FIG. 4 will be described. The execution history in FIG. 4 is sequentially executed in consideration of the dependence of requests and the number of licenses of tools. First, execute the job step. Since this is the first request start, there is no start condition.

The next job step is as follows. In the order of requests shown in FIG. 3, the job step should be performed after the job step. However, since the operation cannot be performed unless the dependency relationship shown in FIG. 3 is completed, the operation waits until the operation is completed. Therefore, the next job step is:
Next, the process is completed and the dependency can be started. However, since the number of available licenses of the tool 1 is three, only the tool 1 is started and waits. Next, is completed, and the dependencies can be started and started. At the same time, since the number of licenses in use of the tool 1 becomes two, it can be started and started. Hereinafter, the same applies.

As described above, according to the present invention, a process dependent on a process flow represented by an LSI or the like can be automatically performed by the system. FIG. 5 is a diagram showing an embodiment of the system of the present invention. In the figure, 1 is a request reception control unit for receiving a request, 2 is a request queue, 3 is a request extraction unit for extracting a request (job step) from the request queue 2, 4 is an executed queue in which executed job steps are stored, 5 Is a request execution control unit that receives a request from the request fetch unit 3 and controls execution of the request, 6 is a job dependency control unit that receives an instruction from the executed queue 4 and controls job dependence, and 7 is a request execution unit. A license control unit that responds to a license inquiry from the control unit 5; a plurality of licenses 8; a software execution unit 9 that executes processing in response to an instruction from the request execution control unit 5;
0 is software. The request execution control unit 5 instructs the request queue 2 to change the order and delete the end request.

An outline of the operation of the system shown in FIG.
It is as follows. The request reception control unit 1 sequentially registers requests in the request queue 2. The request fetch unit 3 fetches a request from the request queue 2 and passes it to the request execution control unit 3. The request execution control unit 5 inquires of the license control unit 7 whether the extracted request (job step) is executable.

The license control unit 7 checks the status of the license 8 and returns a response to the request execution control unit 5 as to whether or not the license 8 can be executed. If the execution is possible, the request execution control unit 5 instructs the software execution unit 9 to execute the software 10. In this case, the job dependency control unit 6
Receives the instruction from the executed queue 4, checks the dependency, and notifies the request execution control unit 5 of the result.

With this configuration, software management can be automatically performed. FIG. 6 is a diagram showing an example of a processing flow of the present invention. The same components as those in FIG. 5 are denoted by the same reference numerals. In the figure, reference numeral 2 denotes a request queue, 3 denotes a request take-out unit, 4 denotes an executed queue, 9 denotes a software execution unit, and 11 denotes a license-free management file (tool unavailable queue). The first request is accessed from the request queue 2 to check whether the requested tool is currently available (S1). If unavailable, access the next request. The permission / inhibition of use refers to the presence / absence of software, use restrictions, and the like, and is set by a tool administrator in a use-disabled tool management file.

If the tool is usable, it is checked whether the request to be processed has a dependency with another request. If there is a dependency, it is checked by referring to the executed queue 4 whether the start condition of the own device (for example, a job that cannot be executed without passing through the preceding job step; see FIG. 10) is satisfied (see FIG. 10). S2). If the start condition is not satisfied, the process is not performed and the process of the next request is performed.

If the start condition is satisfied or the request has no dependency, a license is secured (S3). If the license cannot be secured, the tool is registered in the license-free management file 11, and the next request is processed.

If the license has been secured, the software execution unit 9 is started (S4), and the executed request is deleted from the request queue (S5). Further, the process returns to the access to the first request in the request queue 2.

In the case of a request having a dependency, the software activation unit (software execution unit) 9 registers the request in the executed queue 4 after the execution processing. If there is a dependency, and if there is no request to be processed after the own request, the content of the processed request having the dependency is deleted from the executed queue after execution. The deletion method follows the start condition and deletes the request of the related request ID.

Further, the license free space management file 1
In the case where the executed tool is registered in No. 1, the tool is deleted from the license absence management file 11. Requests that are driven later by this completed queue check the completed queue to see if the start condition for their request is satisfied. By repeating these series of processes, tools having a plurality of licenses can be processed in parallel by the number of available licenses.

FIG. 7 is a flowchart showing the request fetching process, showing the operation of the request fetching unit 3 of FIG. First, it is checked whether there is a next queue (S1). Next, it is checked whether there is a request from the request queue 2 (S2). If there is a request, it is checked whether the request is usable by referring to the unusable management file 13 (S3). If not available, step S1
Returning to step S4, if the request can be used, the request is taken out of the request queue 2 (S4).

FIG. 8 shows the software execution unit 9 (see FIG. 5).
It is a figure which shows the processing flow of. First, when there is a request (job step), it is checked whether the request has a dependency with another request (job step) (S1).
If there is no dependency with another request, the requested software can be executed unconditionally and the requested software is executed as it is (S2).

If there is a request relationship with another process, the requested software is executed (S3) and registered in the executed queue 4 (S4). Next, the license vacancy management file 1
1 is accessed and deleted from the tool unavailable queue (S5). Next, it is checked whether it is the end of the dependency (S6). If it is the last of the dependencies, the related request is deleted from the executed queue 4 (S7). If it is not the last of the dependencies, the process ends.

Next, a method of expressing a request dependency will be described. The dependency of the request can be made by describing the request ID of the own device and the request ID to be executed before and after in the request. FIG. 9 is a diagram illustrating a request dependency relationship expression method.
The case where there are a plurality of requests from request 1 is shown. Each request is related based on a start condition and an end condition. Each request includes a request number, a start condition (previous job end confirmation), an execution tool, processing data, and an end condition (next job start command) as shown in the figure.

A request that needs to be completed before its own request is defined as a start condition. A plurality of conditions can be described. If a plurality of conditions are described, all of them are necessary conditions.
A request to be executed after the own request in priority is defined in the end condition, and the request defined in the end condition is executed earlier than the process requested earlier. A start request and an end condition are not described in a single request having no dependency.

FIG. 10 shows the contents of the request. The figure shows the contents of requests from request to o10.
For example, since the processing of the request ID is started unconditionally, there is no start condition. The execution tool is
Tool 1 as described above. Next, the execution data
This is data 1. dir indicates a directory. The termination condition is as follows, and indicates that it is necessary to execute +, with priority, after the processing is completed. Request ID
In the case of, the start condition is, which indicates that the process cannot be executed unless these processes are completed (see FIG. 2 for the request relationship).

In the case of the request ID １０10, the start condition is 、, and the request (job step) that needs to be completed before its own request is で. Since there is no request after ○ 10, there is no termination condition. Note that registration to the request queue is always performed at the end.

(Supplementary Note 1) Regarding a license management method for a job including a plurality of software job steps, the order dependency of the job steps is expressed by a start condition for each job step (step 1), and the start of each job step is started. It is confirmed that the execution of another job step as a condition has been completed (step 2), whether or not the job step can be executed is determined (step 3), and a software license for the job step is sequentially obtained (step 2). 4) A license management method characterized in that:

(Supplementary Note 2) The order dependency of the job steps is expressed by start / end conditions for each job step.
The license management method according to claim 1, wherein a job step to be executed next is determined with an end of execution of each job step as a trigger, and a license of software corresponding to the job step is sequentially acquired.

(Supplementary Note 3) A registration unit for registering a request, a request queue for queuing the registered request, a request is taken out of the request queue, it is determined whether or not the request can be executed, and a request execution for controlling the execution of software is performed. A license management system including a control unit, a job dependency control unit for controlling a request dependency relationship, a software execution unit for executing software, and a license management unit for managing software licenses.

(Supplementary Note 4) In the job step, different processing functions of the same software whose use is controlled based on the same license are identified as separate processing steps, and the order dependency of processing and license acquisition are controlled. 3. The license management method according to any one of supplementary notes 1 and 2, wherein

(Supplementary Note 5) In the job step, a plurality of job steps of the same processing function of the same software, whose use is controlled based on the same license, are identified as separate processing steps. 4. The license management method according to claim 4, wherein

(Supplementary Note 6) On the premise that a plurality of job steps of the same processing function of the same software are executed in parallel, it is necessary to confirm that all the job steps executed in parallel have been completed and to execute next. 6. The license management method according to claim 5, wherein a job step is determined, and a license of software corresponding to the job step is sequentially acquired.

[0054]

As described above, according to the present invention, the following effects can be obtained. According to the present invention, software license management can be automated.

Further, according to the present invention, a process depending on a process flow represented by an LSI or the like can be automatically performed by the system. Further, according to the present invention, software license management can be automated.

Further, according to the present invention, the requested processing can be executed without fail. As described above, according to the present invention, the software license management is automated, the requested processing is reliably executed, the number of licenses of each tool possessed is fully utilized, and the processing flow represented by an LSI or the like is performed. And a license management method and a license management system can be provided in which the system automatically performs a process depending on the license, and a user can reliably obtain a result only by requesting the process.

[Brief description of the drawings]

FIG. 1 is a flowchart showing the principle of the method of the present invention.

FIG. 2 is a diagram showing an LSI development flow.

FIG. 3 is a representation diagram of storage in a request queue and dependence.

FIG. 4 is a diagram illustrating a job execution history.

FIG. 5 is a diagram showing an embodiment of the system of the present invention.

FIG. 6 is a diagram showing an example of a processing flow of the present invention.

FIG. 7 is a flowchart showing a request extraction process.

FIG. 8 is a diagram showing a processing flow of a software execution unit.

FIG. 9 is a diagram illustrating a method of expressing a dependency relationship of a request.

FIG. 10 is a diagram illustrating an example of a request content.

[Explanation of symbols]

 Reference Signs List 1 Request reception control unit 2 Request queue 3 Request extraction unit 4 Executed queue 5 Request execution control unit 6 Job dependence control unit 7 License control unit 8 License 9 Software light receiving unit 10 Software

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Tomoaki Koga 3-22-8 Hakata Ekimae, Hakata-ku, Fukuoka-shi, Fukuoka Fujitsu Kyushu Digital Technology Co., Ltd. (72) Inventor Hideki Sakamoto Hakata-ku, Fukuoka-shi, Fukuoka Fujita Kyushu Digital Technology Co., Ltd. (72) Inventor Masayuki Tsuda 3-22-8 Hakata Ekimae 3-chome, Hakata-ku, Fukuoka City, Fukuoka Prefecture Reference) 5B076 FD00

Claims (3)

[Claims] 1. A method for managing a license of a job including a plurality of software job steps, wherein the order dependency of the job steps is expressed by a start condition for each job step (step 1). It is confirmed that the execution of another job step has been completed (step 2), whether or not the job step can be executed is determined (step 3), and a software license for the job step is sequentially obtained (step 4). And a license management method. 2. The order dependency of the job steps is as follows:
Expressed as start / end conditions for each job step, triggered by the end of execution of each job step as a trigger, the next job step to be executed is determined, and the software license corresponding to the job step is sequentially acquired. 2. The license management method according to claim 1, wherein: 3. A request reception control unit for registering a request, a request queue for queuing the registered request, a request being taken out of the request queue, whether the execution is possible, and a request execution for controlling the execution of the software. A license management system comprising a control unit, a job dependency control unit for controlling a request dependency relationship, a software execution unit for executing software, and a license control unit for managing software licenses.