Method for optimizing critical software

Abstract

One aspect of the invention relates to a method (100) for optimizing critical software by creating a variant of the critical software. This variant is obtained by adding instructions to the instruction set of each elementary interval of the critical software. These added instructions allow, in particular, the generation of interference during the execution of the critical software. Furthermore, these added instructions also allow the measurement of the actual execution time of each elementary interval of the critical software into which the instructions were added and the collection of measurements relating to hardware stresses. The method according to the invention thus makes it possible to evaluate critical software that can be used in the context of optimizing the critical software. Figure to be published with the abstract: Figure 2

Description

Title of the invention: Method for optimizing critical software TECHNICAL FIELD OF THE INVENTION

[0001] The technical field of the invention is that of critical software.

[0002] The present invention relates to a method for optimizing critical software. TECHNOLOGICAL BACKGROUND OF THE INVENTION

[0003] The present invention relates to the field of critical software. Critical software is software whose malfunction would have a significant impact on the safety or lives of people, businesses, or property. This critical software is typically used for the management and control of various aircraft components, for the management and control of sensitive vessels, and for the management of nuclear power plants.

[0004] It is known to define a certification level for software intended to be executed in such a system, i.e., for example, an aircraft. This certification level therefore defines the care and development techniques used and thus reflects an intrinsic quality level of the critical software.

[0005] For example, in the field of critical embedded avionics software, certification levels are defined by the ED-12C and DO-178C standards. These standards define 5 criticality levels or DALs, for "Design Assurance Level", from A, the highest certification level, to E, the lowest level.

[0006] In order to implement critical software, it is known to partition the critical software. Thus, the critical software is divided into elementary intervals. Each elementary interval performs a task. In the context of critical software running on a single-core processor, the concept of partitioning ensures that if a given task fails, this failure will not impact the other tasks. The execution of one task is therefore said to be isolated from the execution of other tasks.

[0007] An important criterion for critical software is compliance with a maximum execution time, commonly denoted WCET for "worst-case execution time." To meet the given WCET for critical software, it is known to allocate a time budget to each elementary interval of the critical software. This time budget corresponds to a maximum execution time that an elementary interval must respect. This time budget incorporates margins, the duration of which is obtained, for example, through analysis, as well as provisions for future enhancements / corrections. The solution based on the isolation between the different tasks of the critical software allows WCET compliance for critical software intended to run on a single-core processor.

[0008] However, recent years have seen the development of multi-core processors as the primary means of continuing the race for processor computing power. It turns out that current multi-core processors do not guarantee operational isolation between the different cores. Thus, it cannot be guaranteed that a task running on one core and subject to interference or failure will not disrupt the proper execution of another task running on a different core. The idea, in the case of execution on a multi-core processor, is therefore to incorporate an additional margin to account for disturbances induced by the processing carried out on the different cores of the multi-core processor.To address this problem, it is currently known, within the context of developing critical software intended to run on a multi-core processor, to model the behavior of the multi-core processor by disrupting its behavior as much as possible by executing generic or standard instructions—that is, instructions not specific to the critical software that will be executed under the real-world operating conditions of the multi-core processor. Asterios Technologies, for example, has developed the concept of a "co-runner," which can be defined as an infinitely repeated sequence of instructions designed to stress a shared hardware resource in order to maximize its bandwidth utilization. The "co-runner" concept allows for quantifying the availability of shared hardware resources and updating certain undocumented characteristics of the multi-core processor.Thus, the current approach aims to characterize the behavior of the multicore processor without taking into account the specific characteristics of the critical software that it is intended to execute under real-world conditions. This current approach notably leads to a risk of oversizing the multicore processor.

[0009] Furthermore, in order to take into account the specific characteristics of running critical software on a multi-core processor, the European Union Aviation Safety Agency (EASA) provides (in a document entitled "General Acceptable Means of Compliance for Airworthiness of Products, Parts and Appliances (AMC-20)") a section dedicated to the use of multi-core processors, "AMC 20-193 Use of multi-core processors." In this section, it is particularly recommended to adhere to the concept of the Intended Final Configuration of the multi-core processor and critical software combination. More specifically, it states that it is necessary to consider "the configuration of the critical software and the hardware in which all the resources of the multi-core processor have been defined by the implementation of the configuration parameters."

[0010] There is therefore a need to provide a method for optimizing critical software, for example intended to run on a multi-core processor, limiting, at least in part, the problems associated with using the aforementioned prior art methods. Summary of the invention

[0011] The invention provides a solution to the problems mentioned above by creating a variant of the critical software. This variant of the critical software is obtained by adding instructions to the instruction set of each elementary interval of the critical software. These added instructions make it possible, in particular, to generate interference during the execution of the critical software. Furthermore, these added instructions also make it possible to measure the actual execution time of each elementary interval of the critical software in which the instructions have been added and to collect measurements relating to the stresses on the hardware. The method according to the invention thus makes it possible to evaluate critical software that can be used in the context of optimizing the critical software.Thus, the method according to the invention makes it possible to determine whether the potential interferences present are acceptable given the software specifications or whether they are prohibitive, in which case it is necessary to modify the choices previously made, for example by optimizing the critical software or by changing the characteristics of the target hardware, i.e., the hardware on which the critical software will be executed under real-world conditions. Indeed, the method according to the invention makes it possible to ensure that the interferences inherent in the operation of critical software on a multi-core processor do not disrupt the execution of tasks running on the different cores. Therefore, it is possible to determine whether it is necessary to optimize the critical software, or to modify the characteristics of the target hardware, so that the execution time of each elementary interval does not exceed its allocated time budget and thus that the WCET of the critical software is respected..

[0012] One aspect of the invention relates to a method, implemented by a computer, for optimizing critical software, the computer comprising a multi-core processor, each core of which includes at least one module adapted to allow the execution of at least one independent sequence of instructions during the execution of the critical software, the method comprising steps of: • Obtaining the critical software, the critical software being divided into a set of elementary intervals, each elementary interval of the set of elementary intervals comprising a first set of instructions forming a fundamental unit of the critical software performing an indivisible task executed by a single module, the set of elementary intervals being executed by the modules according to a sequence predetermined, the sequencing of the execution of the set of elementary intervals consisting of specifying: • a schedule for the execution of all the elementary intervals, and • for each elementary interval, a maximum execution time, • Creation of a variant of the critical software, the creation of the variant of the critical software respecting the ordered sequence of execution of the set of elementary intervals and the specified module in charge of executing each elementary interval, the creation of the variant of the critical software consisting of adding, in the first set of instructions of at least one elementary interval of the set of elementary intervals: • a second set of instructions configured to create at least one interference disrupting the execution of the current elementary interval, the disruption of the execution of the current elementary interval including lengthening the actual execution time of the current elementary interval, • a third set of instructions configured to measure the actual execution time of the current elementary interval, • Execution of the variable critical software allowing measurement of the actual execution time of at least one elementary interval of the set of elementary intervals, • Optimization of critical software when, for at least one elementary interval of the set of elementary intervals, the actual execution time is greater than the maximum execution time specified by the predetermined sequencing.

[0013] Thanks to the invention, the intended final configuration of the "multicore processor and critical software" combination is taken into account. Indeed, the method makes it possible to reproduce, as closely as possible, the execution of the critical software on the multicore processor under real-world operating conditions, for example, in the context of managing and controlling an aircraft component. Thus, the method uses a variant of the critical software whose sequencing is as close as possible to the critical software of interest. Moreover, disrupting the execution of the critical software on the multicore processor allows for the preservation of certain characteristics of the critical software sequencing. Finally, it should be noted that the method according to the invention can be iterated until all the execution times of the critical software, i.e.the sum of the actual execution times of the elementary intervals, either less than a predetermined maximum execution time of the critical software or until the actual execution time. Each elementary interval of the optimized critical software adheres to its allocated time budget. Thus, during the final iteration, the variant of the optimized critical software can reproduce the execution sequence of the critical software as predicted during its use in real-world conditions.

[0014] In addition to the characteristics mentioned in the preceding paragraph, the method according to one aspect of the invention may have one or more additional characteristics from among the following, considered individually or in all technically possible combinations: • at least one interference disrupting the execution of at least one elementary interval is one of the following interferences: • Concurrent access between two modules to a shared resource, • Concurrent access between two modules to an access path IT shared across multiple resources • Critical software optimization includes: • a modification of the first set of instructions by at least one elementary interval, and / or • a change in the execution sequence of the critical software, and / or • the suppression of an interference channel, • The critical software has a criticality level of A according to the DO-178C standard. • The creation of the variant of the critical software further includes the addition, in the first set of instructions of at least one elementary interval of the set of elementary intervals, of a fourth set of instructions configured to measure at least one characteristic of the execution of the variant critical software, the measurement being performed using hardware counters to identify an event such as: • a cache access error, or "cache miss," and / or • a completed instruction, • The measurement of at least one characteristic of the execution of the variant critical software is used to model the behavior of the multi-core processor, • The steps of creating the variant of the critical software, executing the variant critical software, and optimizing the critical software are performed iteratively until a set of critical software execution times is less than a predetermined maximum critical software execution time.

[0015] Another aspect of the invention relates to a computer configured to implement the method according to the invention and comprising a multi-core processor.

[0016] An additional aspect of the invention relates to a computer program product comprising instructions which, when the program is executed on a computer according to the invention, lead the latter to implement the steps of the process according to the invention.

[0017] An additional aspect of the invention relates to a computer-readable recording medium comprising the computer program product according to the invention.

[0018] The invention and its various applications will be better understood by reading the following description and examining the accompanying figures. BRIEF DESCRIPTION OF THE FIGURES

[0019] The figures are presented for illustrative purposes only and are in no way limiting of the invention. • Fig. 1 is a synoptic diagram illustrating the steps of an example of the process of optimizing critical software according to the invention. • Fig. 2 is a schematic representation of an example of sequencing the execution of critical software on a multi-core processor. DETAILED DESCRIPTION

[0020] Unless otherwise specified, the same element appearing on different figures has a unique reference.

[0021] Fig. 1 is a synoptic diagram illustrating the steps of an example of the method 100 for optimizing critical software according to the invention.

[0022] The process 100 is computer-implemented. "Computer-implemented" means that the steps, or at least one step, are executed by at least one computer or similar system. Thus, steps are carried out by the computer, possibly in a fully automatic or semi-automatic manner. In some examples, the triggering of at least some of the steps of the process can be achieved through user-computer interaction. The level of user-computer interaction required may depend on the intended level of automation and be balanced against the need to implement the user's wishes. In some examples, this level may be user-defined and / or predefined.

[0023] A typical example of a computer implementation of a process consists of executing process 100 with a system adapted for this purpose. The system comprises an execution device for executing instructions (for example, based on one or more scripts) and a measured device. The measured device is the device whose behavior is to be analyzed. The execution device and the measured device are connected by a communication means. The device The measured system includes, in particular, a multi-core processor. A multi-core processor might have, for example, between one and eight cores. Each core of the multi-core processor includes at least one module adapted to allow the execution of at least one independent sequence of instructions during the execution of the critical software. A module is a partitioned execution unit. The system may also include memory and a graphical user interface, a multi-core processor, and system memory containing a computer program with instructions to implement the process. The memory may also store a database. Memory is any hardware adapted for such storage, possibly comprising several distinct physical parts.

[0024] Method 100 is a method for optimizing critical software. The critical software may, for example, have a criticality level between level A and level C according to the DO-178C standard. Preferably, the criticality level of the critical software is level A. The critical software may be intended to be executed by a target system comprising a multi-core processor. For example, the multi-core processor of the target system is identical or similar to the computer implementing Method 100. By "similar multi-core processors," it is understood that multi-core processors allow the critical software to be executed according to an identical predetermined sequence. The term "optimization" therefore refers here to modifying the critical software so that its execution on a target system best respects the predetermined sequence.Indeed, the primary objective of critical software optimization is to ensure compliance with a given WCET (World Wide Acceptance Time) for the critical software when it is executed on the target system. Critical software optimization can therefore, for example, consist of reducing the number of disturbances induced by the execution of the critical software on the target system. For instance, process 100 might involve resolving certain disturbances from a set of identified disturbances, the choice of which disturbances to resolve being linked, for example, to the significance of their impact on the total execution time of the critical software, and therefore on whether or not the WCET is met.

[0025] A first step 110 of process 100 involves obtaining the critical software. The term "obtaining" can mean, in this application, that the software code is received by the computer. Thus, this code is modified during process 100 by adding instructions to create a variant of the critical software. The critical software is divided into a set of elementary intervals. An elementary interval is an indivisible set of instructions to be executed. Each elementary interval in the set of elementary intervals therefore comprises a first set of instructions forming a fundamental unit of the critical software. The first The instruction set for each elementary interval thus performs an indivisible task executed by a single module of a core in the multi-core processor. The execution of the different elementary intervals by the modules of the different cores of the multi-core processor is sequenced. The sequencing is predetermined, meaning it is determined before the start of the process. Figure 2 illustrates an example of the sequencing of critical software. The sequencing specifies, in particular, three characteristics of the execution of the critical software. First, the sequencing specifies an execution schedule for the set of elementary intervals. Thus, the sequencing specifies when the execution of each of the elementary intervals in the set of elementary intervals must begin.For example, the sequencing might specify that a first elementary interval must be executed at time t and a second elementary interval at time t+1, with the previous t occurring within time t+1. Furthermore, the sequencing might specify that a third elementary interval must be executed at time t, simultaneously with the first elementary interval. For example, in [Fig. 2], the execution of elementary intervals 211 to 214, 221 and 222, and 231 and 232 begins at different times, denoted t, t+1, t+2, and t+3. The execution of elementary intervals 211 and 221, for instance, begins at time t, while the execution of elementary intervals 212 and 231 begins at time t+1. Secondly, the sequencing specifies a maximum execution time for each elementary interval. This maximum execution time is the maximum duration that must be respected for executing each of the elementary intervals.This maximum execution time can differ between two elementary intervals within the set of elementary intervals. In [Fig. 2], this maximum execution time is, for example, the time between time t and time t+1; thus, the execution of elementary intervals 211 and 221 has a maximum execution time equal to the time difference between t and t+1. Third, the sequencing specifies a module responsible for executing each of the elementary intervals. More precisely, the sequencing specifies that two elementary intervals must be executed on two different modules, for example, because their execution is performed in parallel. For example, in [Fig. 2], the three modules 210, 220, and 230 are each responsible for executing different elementary intervals. Module 210, for instance, is responsible for executing elementary intervals 211 through 214. Furthermore, it can be noted that modules 210 and 220 are part of the same core 240, while module 230 is part of a different core 250.

[0026] A second step 120 of the process 100 comprises the creation of a variant of the critical software. The variant of the critical software aims to reproduce the execution of the critical software by adding interferences that could occur during its execution under real-world conditions. This step aims, in particular, to add instructions that create interference in order to observe its impact on the execution of the critical software, and specifically on its execution time. The variant of the critical software must reproduce the execution of the critical software under real-world conditions as closely as possible. Thus, the variant of the critical software, during its execution, respects at least two of the three aforementioned characteristics of the predetermined sequencing. The execution of the variant critical software therefore respects the ordered sequence of execution of all the elementary intervals and the specified module responsible for executing each elementary interval.The critical software variant therefore allows us to verify whether each of the elementary intervals respects its maximum execution time or not when the other characteristics of the predetermined sequencing are applied.

[0027] Creating variant 120 of the critical software variant involves modifying the critical software code by adding instructions to the first instruction set of at least one elementary interval of the set of elementary intervals. Thus, a second instruction set is added to the first instruction set of one or more elementary intervals of the critical software. This second instruction set is configured to create at least one interference that disrupts the execution of the current elementary interval. The disruption of the execution of the current elementary interval includes, in particular, extending the actual execution time of the current elementary interval. The added interference may vary in nature and intensity. The nature of the added interference may aim to reproduce a disturbance that could occur during the execution of the critical software under real-world conditions.Similarly, the intensity of the interference can be sized to reproduce the intensity of the disturbance that may occur during the execution of the critical software under real-world conditions.

[0028] In an example consistent with the preceding examples, at least one interference disrupting the execution of one or more elementary intervals is one of the following: • Concurrent access between two modules, or, for example, a module and a processor peripheral, to a shared resource, • concurrent access between two modules to a computer access path common to several resources.

[0029] A third set of instructions is also added to the first set of instructions for one or more elementary intervals of the critical software. This third set of instructions is configured to measure the actual execution time of the current elementary interval. This third set of instructions therefore makes it possible to verify that the actual execution time of the current elementary interval respects or does not respect the maximum execution time, particularly when at least one interference is created by the second set of instructions.

[0030] In an example consistent with the preceding examples, a fourth instruction set can also be added to the first instruction set of one or more elementary intervals. This fourth instruction set is configured to measure at least one characteristic of the execution of the variant critical software. The measurement is performed using hardware counters. More precisely, the measurement can be performed by reading and storing the values ​​of the hardware counters available for the target multicore processor at the beginning and end of the execution of the current elementary interval. The hardware counters can, for example, identify an event such as: • A cache access error, or "cache miss," and / or • a completed instruction.

[0031] The maximum number of usable hardware counters depends, among other things, on the characteristics of the multi-core processor. For example, on a PowerPC-type processor, one hundred or even several hundred hardware counters are available, but only four counters can be selected at a time for a given core. To acquire a large number of measurements with the hardware counters, it is therefore necessary to perform step 130 several times with different hardware counter activations.

[0032] This fourth set of instructions is therefore configured to identify the occurrence of events impacting the execution of the critical software, and in particular the execution time of the critical software. This fourth set of instructions thus makes it possible to understand why interference lengthens the actual execution time of an elementary interval and potentially how it impacts the execution of other elementary intervals besides the one whose execution was disrupted by the execution of the second set of instructions.

[0033] In an example consistent with the preceding examples, the measurement of at least one characteristic of the execution of the varied critical software can be used to model the behavior of the multicore processor. Indeed, as previously mentioned, it is common practice to model the behavior of a multicore processor by perturbing its behavior as much as possible. Thanks to the information obtained by measuring at least one characteristic of the execution of the varied critical software, it is possible to improve this modeling by identifying, in particular, errors or approximations related to the degree of maximum perturbation used to perform the initial modeling of the multicore processor's behavior.

[0034] In an example consistent with the preceding examples, the execution of the different instruction sets is conditional upon a parameter that can be enabled or disabled during the execution of the critical software variant. For example, it is possible for an elementary interval within the set of elementary intervals to not enable the call to the fourth instruction set, which will therefore not be executed. In another example, it is possible for an elementary interval within the set of elementary intervals to not enable the call to the second instruction set. Thus, the execution of this elementary interval is not disrupted by interference generated by the execution of the second instruction set. By enabling or disabling different instruction sets, it is therefore possible to test a large number of scenarios in order to understand how the execution of the critical software unfolds under real-world conditions.To enable or disable the execution of different instruction sets, it is possible, for example, to use a macro during the compilation of the software variant; thus, if an instruction set is not enabled, this instruction set will not be present in the executable version of the critical software variant.

[0035] A third step 130 of the method 100 includes the execution of the variant critical software. This execution makes it possible, in particular, to measure the actual execution time of at least one elementary interval of the set of elementary intervals. This measurement is performed using the second set of instructions, the execution of which is activated for at least one elementary interval of the set of elementary intervals.

[0036] A fourth step 140 of the process 100 comprises the optimization of the critical software. This optimization of the critical software is necessary when, for at least one elementary interval of the set of elementary intervals, the actual execution time exceeds the maximum execution time specified by the predetermined sequencing. Indeed, if the execution of one of the elementary intervals of the critical software does not comply with the maximum execution time specified by the predetermined sequencing, this non-compliance can cause disruptions in the execution of other elementary intervals.Thus, if the impact of not respecting the maximum execution time specified by the predetermined sequencing by an elementary interval is too great, for example by preventing the critical software from respecting a given WCET, the optimization of the critical software must reduce the impact of this interference so that the critical software respects the given WCET. For example, the optimization of the critical software may include: • a modification of the first set of instructions by at least one elementary interval, or • a modification of the execution sequence of the critical software, • the suppression of an interference channel

[0037] In an example consistent with the preceding examples, steps 120 to 140 are iterated until the critical software complies with the given WCET. In other words, steps 120 to 140 are performed as long as the execution of the critical software exceeds the WCET defined for that critical software.

[0038] In an example consistent with the preceding examples, steps 130 to 140 are performed on the target multicore processor by loading onto the target system, i.e., the system on which the critical software is executed under real-world conditions, using a programming probe. Furthermore, after the kernel starts and before the application starts, the programming probe is used to initialize: • the hardware counters from which measurements are to be obtained, and • the configuration of the activation or not of the different sets of instructions.

[0039] Next, the critical software is executed for a chosen duration, allowing the entire predetermined sequence to be performed several times. Finally, at the end of this chosen duration, the probe is used again to retrieve the measurements taken, notably using the hardware counters.

[0040] When all the measurements are retrieved for a scenario, i.e., for a set of activation combinations of different instruction sets, it may be necessary to merge this data, which comes from a number of executions of different variants of the critical software that have made it possible to perform all the combinations foreseen in the scenario despite the limited number of hardware counters allowed for a single execution of the critical software. Thus, while the main objective of method 100 is to optimize the critical software to ensure compliance with a given WCET, method 100 also makes it possible to identify the most relevant hardware counters that are specific to the "critical software-multicore processor" pair. In order to identify the most relevant hardware counters, it is possible to perform a few iterations of steps 120 to 140 by: • Identifying inactive physical meters (whose value remains unchanged) • Identifying constant or quasi-constant physical counters (whose deviation over an interval does not change) • Identifying redundant hardware meters (some meters measure very similar things) • Analyzing the sensitivity of the remaining hardware counters using algorithms from deep learning, commonly called "deep learning" in English, a calculation of a Wasserstein distance, etc...

[0041] Thus, inactive, constant, and redundant hardware counters can be considered irrelevant and therefore no longer used in the iterations following. The time required to obtain the most relevant measurements, and therefore to optimize the critical software, is thus reduced.

Claims

1. Demands Method (100), implemented by a computer, for optimizing critical software, the computer comprising a multi-core processor, each core of which includes at least one module adapted to allow the execution of at least one independent sequence of instructions during the execution of the critical software, the method comprising steps of: - Obtaining (110) the critical software, the critical software being divided into a set of elementary intervals, each elementary interval of the set of elementary intervals comprising a first set of instructions forming a fundamental unit of the critical software performing an indivisible task executed by a single module, the set of elementary intervals being executed by the modules according to a predetermined sequence, the sequencing of the execution of the set of elementary intervals consisting of specifying: • an execution schedule for the set of elementary intervals, and • for each elementary interval, a maximum execution time, - Creation (120) of a variant of the critical software, the creation of the variant of the critical software respecting the ordered sequence of execution of the set of elementary intervals and the specified module in charge of executing each elementary interval, the creation of the variant of the critical software consisting of adding, in the first set of instructions of at least one elementary interval of the set of elementary intervals: • a second set of instructions configured to create at least one interference disrupting the execution of the current elementary interval, the disruption of the execution of the current elementary interval including the lengthening of the actual execution time of the current elementary interval, • a third set of instructions configured to measure the actual execution time of the current elementary interval, - Execution (130) of the variant critical software to measure the actual execution time of at least one elementary interval of the set of elementary intervals, - Optimization (140) of the critical software when, for at least one elementary interval of the set of elementary intervals, the actual execution time is greater than the maximum execution time specified by the predetermined sequencing.

2. A method (100) for optimizing critical software according to claim 1 wherein at least one interference disrupting the execution of at least one elementary interval is an interference among: - Concurrent access between two modules to a shared resource, - Concurrent access between two modules to a computer path common to several resources.

3. A method (100) for optimizing critical software according to claim 1 or 2 wherein the optimization (140) of critical software comprises: - A modification of the first set of instructions by at least one elementary interval, and / or - A modification of the execution sequence of critical software, and / or - A removal of an interference channel.

4. Method (100) of optimizing critical software according to any one of the preceding claims wherein the critical software has a criticality level of level A according to DO-178C.

5. A method (100) for optimizing critical software according to any one of the preceding claims, wherein the creation (120) of the variant of critical software further comprises adding, in the first set of instructions of at least one elementary interval of the set of elementary intervals, a fourth set of instructions configured to measure at least one characteristic of the execution of the variant critical software, the measurement being carried out using hardware counters to identify an event such as: - A cache miss, and / or - A completed instruction.

6. A method for optimizing critical software according to the preceding claim, further comprising measuring at least one characteristic of the execution of the varied critical software used to model the behavior of the multi-core processor.

7. A method for optimizing critical software according to any one of the preceding claims, wherein the steps of creating (120) the variant of critical software, executing (130) the variant critical software and optimizing (140) the critical software are carried out iteratively until a set of execution times of the critical software is less than a predetermined maximum execution time of the critical software.

8. Computer configured to implement the method according to any one of the preceding claims and comprising a multi-core processor.

9. Computer program product comprising instructions which, when the program is executed on a computer according to claim 8, cause the computer to carry out the steps of the process (100) according to any one of claims 1 to 7.

10. Computer-readable recording medium comprising the computer program product according to the preceding claim.

Images