Information processing system, information processing method, and computer program

Abstract

To provide an information processing system, an information processing method, and a computer program that perform a test on tasks with higher priority first.SOLUTION: An information processing system, which supports development of software executed on an on-vehicle device, includes a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue where the task waits for test execution. The control unit reads the priority information from storage where the priority information including information related to the task is stored, calculates, on the basis of the priority information, priority of the task, compares priority of the task already accumulated in the queue with the priority of the task to be newly added to the queue, and adds the task to the queue with the task having a higher priority being executed first.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to an information processing system, an information processing method, and a computer program. [Background technology]

[0002] Traditionally, software development has used methods known as continuous integration (CI) and continuous delivery (CD). Continuous deployment (CD) is sometimes used instead of continuous delivery. These development methods aim to reduce the number of large-scale revision events and the cost of revisions by frequently and automatically verifying software during development.

[0003] For example, in software development, multiple developers each create source code, and the operation of each source code is checked. However, when multiple source codes are integrated into a single piece of software and run, there is a risk of errors occurring. In this case, it becomes necessary to verify which combination of source codes caused the error, one by one, which can make the operation test take a long time.

[0004] In a development method based on CI / CD, for example, source code created by multiple developers is stored in a repository on the cloud (pushed to the repository). Then, a source control tool (also known as SCM: Source Code Management) such as GitHub (registered trademark) automatically creates tasks based on the source code stored in the repository each time the source code is updated (build tasks). The tasks are automatically tested by a CI / CD tool such as Jenkins (registered trademark).

[0005] In this way, by repeating integration in small cycles and frequently checking for integration errors, large-scale rework can be reduced.

[0006] Patent Document 1 discloses a technology for selecting test cases to be executed based on the importance of the test and the execution time of the test. The technology in Patent Document 1, for example, does not execute test cases with low importance, thereby reducing the time required for automated testing of CI.

[0007] Patent Document 2 discloses a technique for changing the order of execution target information in an automatic execution queue based on a priority attribute or the like included in attribute information of a ticket corresponding to source code. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-134643 [Patent Document 2] Patent Publication No. 2021-105866 Summary of the Invention [Problem to be solved by the invention]

[0009] The software executed by devices (in-vehicle devices) installed in automobiles and other vehicles is becoming larger in scale every year, and development methods based on CI / CD are also being adopted for software for in-vehicle devices.

[0010] In the case of software for in-vehicle devices, task operation tests require the use of hardware resources such as development circuit boards and measurement jigs. Providing a large number of such hardware resources increases the cost of building a test environment, so the number of hardware resources is limited. Therefore, it is difficult to run multiple operation tests in parallel for software for in-vehicle devices. Therefore, it is necessary to quickly identify software corrections by running tests on tasks with higher priority first.

[0011] In view of the above problem, the present disclosure aims to provide an information processing system, an information processing method, and a computer program that are capable of executing tests starting with tasks with higher priority. [Means for solving the problem]

[0012] The information processing system disclosed herein is an information processing system that supports the development of software to be executed on an in-vehicle device, and includes a control unit that adds tasks provided from a repository that stores multiple sources included in the software to a queue in which the tasks await test execution.The control unit reads the priority information including information about the tasks from storage that stores the priority information, calculates the priority of the tasks based on the priority information, compares the priorities of the tasks already stored in the queue with the priority of the task to be newly added to the queue, and adds the tasks to the queue with the execution order of the tasks with higher priorities given first.

[0013] The information processing method disclosed herein is an information processing method for supporting the development of software to be executed on an in-vehicle device, and includes a step of adding a task provided from a repository storing multiple sources included in the software to a queue in which the task awaits test execution, the adding step including: a first step of reading priority information including information about the task from storage storing the priority information; a second step of calculating the priority of the task based on the priority information; and a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue with the execution order of the task with the higher priority given first.

[0014] A computer program disclosed herein is a computer program for supporting the development of software to be executed on an in-vehicle device, the computer program causing a computer to execute a step of adding tasks provided from a repository storing multiple sources included in the software to a queue in which the tasks await test execution, the adding step including a first step of reading priority information including information about the tasks from storage storing the priority information, a second step of calculating the priority of the tasks based on the priority information, and a third step of comparing the priorities of the tasks already stored in the queue with the priority of the tasks to be newly added to the queue, and adding the tasks to the queue with the execution order of the tasks with higher priorities. [Effects of the Invention]

[0015] According to the present disclosure, it is possible to execute testing starting from a task with a higher priority. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 1 is a diagram illustrating an example of an information processing system according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of software according to the embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of the internal configuration of the information processing device according to the embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of a test environment according to the embodiment. [Figure 5] FIG. 5 is a table showing an example of version information according to the embodiment. [Figure 6] FIG. 6 is a table showing an example of execution time information according to the embodiment. [Figure 7] FIG. 7 is a table illustrating an example of required time information according to the embodiment. [Figure 8] FIG. 8 is a table showing an example of test result information according to the embodiment. [Figure 9] FIG. 9 is a table showing an example of safety standard information according to the embodiment. [Figure 10] FIG. 10 is a table illustrating an example of environment information according to the embodiment. [Figure 11] FIG. 11 is a flowchart showing an example of an information processing method according to the embodiment. [Figure 12] FIG. 12 is a flowchart showing an information processing method according to a modified example. [Figure 13] FIG. 13 is a diagram for explaining the priority of each task according to the modified example. [Figure 14] FIG. 14 is a table showing test result information according to a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0017] [Description of the embodiments of the present disclosure] The gist of the present disclosure includes the following configurations.

[0018] (1) The information processing system disclosed herein is an information processing system that supports the development of software to be executed on an in-vehicle device, and includes a control unit that adds tasks provided from a repository that stores multiple sources included in the software to a queue in which the tasks await test execution. The control unit reads priority information including information about the tasks from a storage that stores the priority information, calculates the priority of the tasks based on the priority information, compares the priority of the tasks already stored in the queue with the priority of the tasks to be newly added to the queue, and adds the tasks to the queue with the execution order of the tasks with higher priorities given first.

[0019] By configuring in this way, it is possible to execute the test in order of higher priority.

[0020] (2) In the information processing system of (1), the in-vehicle device may include an in-vehicle ECU.

[0021] Software development for automotive ECUs tends to be large-scale, so testing higher priority tasks first is particularly useful.

[0022] (3) In the information processing system of (1) or (2), the priority information may include information regarding at least one of the test environment, the results of past tests of the task, the time at which the past tests of the task were performed, and the time required for the past tests of the task.

[0023] Since the priority information includes the test environment, etc., it is possible to determine an appropriate priority according to the task.

[0024] (4) In the information processing system according to any one of (1) to (3), the priority information may include information regarding a vehicle safety standard required for the task.

[0025] Since the priority information includes information relating to the safety standards of the vehicle, it is possible to determine an appropriate priority according to the type of vehicle and the on-board devices installed in the vehicle.

[0026] (5) In the information processing system of (3), the tasks may include a first task and a second task whose most recent execution time is earlier than the most recent execution time of the first task. In this case, the control unit may calculate a priority of the second task to be higher than the priority of the first task.

[0027] By running tests sooner for tasks that haven't been tested for a while, you can prevent source modifications from becoming too large.

[0028] (6) In the information processing system of (3) or (5), the tasks may include a first task and a second task whose required time is shorter than the required time of the first task. In this case, the control unit may calculate a priority of the second task to be higher than the priority of the first task.

[0029] By executing tests starting with tasks that can be executed in a short time, the number of tests executed per unit time can be increased, and the number of tasks waiting to be executed can be reduced.

[0030] (7) In the information processing system of (3), (5), or (6), the tasks may include a first task whose most recent result is success and a second task whose most recent result is failure. In this case, the control unit may calculate a priority of the second task to be higher than the priority of the first task.

[0031] By running the test on the failed task first, you can more quickly determine whether the error has been resolved.

[0032] (8) In the information processing system of (3), (5), (6), or (7), the test environment may include a test set including a circuit board and a measurement unit that measures the operation of the circuit board, and an execution unit that executes a test of the task by controlling the test set based on the task output from the queue. In this case, the priority information may include environment information that links the task with the test set used in testing the task, and the control unit may calculate the priority of the task based on the environment information.

[0033] Both the circuit board and the measurement unit are hardware resources. Providing a large number of test sets including such hardware resources increases the cost of building a test environment, so software operation tests must be performed using a limited number of test sets. As a result, when developing software for in-vehicle devices, it is difficult to execute multiple tasks in parallel. Therefore, it is particularly useful to execute tests of higher-priority tasks first, so that software modifications can be found more quickly.

[0034] (9) In the information processing system of (8), the test sets may include a plurality of first test sets and a plurality of second test sets, the number of which is smaller than the number of the first test sets. In this case, the tasks may include a first task associated with the first test set and a second task associated with the second test set in the environment information, and the control unit may calculate a priority of the second task to be higher than the priority of the first task.

[0035] By running tests on the rarer test sets first, the rarer test sets can be made less available.

[0036] (10) In the information processing system of (4), the tasks may include a first task and a second task that requires a stricter safety standard than the safety standard required for the first task. In this case, the control unit may calculate a priority of the second task to be higher than the priority of the first task.

[0037] Tasks with stricter safety standards have a narrower range of acceptable values ​​for testing, making them more prone to errors. Testing these tasks first will help you find errors at the source more quickly.

[0038] (11) In the information processing system of (10), the safety standard is ASIL (Automotive Safety Integrity Level) of ISO26262.

[0039] (12) In any of the information processing systems (1) to (11), the control unit may calculate the priority of the tasks already stored in the queue based on the priority information, and rearrange the order of storage in the queue so that a fourth task, which has a higher priority than a third task, among the tasks already stored in the queue is executed before the third task.

[0040] By configuring in this way, the order in which multiple tasks already stored in the queue are stored can be reviewed, so that the task with the highest priority can be tested first with more certainty.

[0041] (13) In any of the information processing systems (1) to (12), the control unit may divide the task into a plurality of divided tasks based on at least one of the test environment, the safety standard, the result, the execution time, and the required time, calculate the priority of each of the divided tasks based on the priority information, and accumulate a second divided task among the plurality of divided tasks, which has a higher priority than a first divided task, in the queue in the order of execution, prior to the first divided task.

[0042] This configuration allows for more detailed checks of test results, making it easier to narrow down which part of the task is causing the error, and allowing for faster response to the error.

[0043] (14) The information processing method disclosed herein is an information processing method for supporting the development of software to be executed by an in-vehicle device, and includes a step of adding a task provided from a repository storing multiple sources included in the software to a queue in which the task awaits test execution, the adding step including: a first step of reading priority information including information about the task from a storage storing the priority information; a second step of calculating a priority of the task based on the priority information; and a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue with the execution order of the task with the higher priority first.

[0044] By configuring in this way, it is possible to execute the test in order of higher priority.

[0045] (15) A computer program disclosed herein is a computer program for supporting the development of software to be executed on an in-vehicle device, the computer program causing a computer to execute a step of adding a task provided from a repository storing multiple sources included in the software to a queue where the task awaits test execution, the adding step including a first step of reading priority information including information about the task from a storage storing the priority information, a second step of calculating a priority of the task based on the priority information, and a third step of comparing the priority of the task already stored in the queue with the priority of the task to be newly added to the queue, and adding the task to the queue with the execution order of the task with the higher priority first.

[0046] By configuring in this way, it is possible to execute the test in order of higher priority.

[0047] 1. Details of the Embodiments of the Present Disclosure Hereinafter, details of embodiments of the present disclosure will be described with reference to the drawings.

[0048] [1.1 Overall configuration of information processing system] FIG. 1 is a diagram showing an example of the configuration of an information processing system 1 according to an embodiment. The information processing system 1 is a system that supports the development of software SW1 that is executed in a device mounted on a vehicle such as an automobile (hereinafter referred to as an "on-vehicle device").

[0049] The software SW1 is software used in, for example, an on-board ECU (Electronic Control Unit) among on-board devices. More specifically, the software SW1 is used in a central ECU or integrated ECU that has a function of managing multiple ECUs. Since such software SW1 tends to involve large-scale development, development support by the information processing system 1 is particularly useful.

[0050] The information processing system 1 includes an information processing device 10, a repository 20, a test tool 30, a test environment 40, and a storage 50. The information processing system 1 may be realized by a single device (e.g., a server device) concentrated in one location, or may be realized by multiple devices distributed across multiple locations with the units 10, 20, 30, 40, and 50 connected to each other so as to be able to communicate with each other via a network such as the Internet.

[0051] 1.2 Software and Tasks FIG. 2 is a diagram illustrating an example of software SW1 according to an embodiment. The software SW1 and task Tx will be described with reference to FIG. 2. As described above, the software SW1 is software executed by the in-vehicle device. The software SW1 includes multiple components X1, X2, and X3. The component X1 includes multiple modules a1, a2, and a3, and the component X2 includes multiple modules b1 and b2.

[0052] These components X1, X2, and X3 and modules a1, a2, a3, b1, and b2 are collectively referred to as "sources." That is, software SW1 includes multiple sources. These sources may be data written in a specific programming language called source code, or may be data written in binary code after the source code is converted into machine language.

[0053] These sources are individually created, for example, on multiple terminals (referred to as a terminal group 60) operated by multiple developers (suppliers). In the information processing system 1, an operation test of the source alone and an operation test of the multiple sources combined (integrated) are performed. Here, the test items performed in the information processing system 1 are referred to as tasks Tx. Tasks Tx are also referred to as "job tasks."

[0054] Task Tx includes any one of the following test items (1) to (4). (1) A test item that verifies whether one module (e.g., module a1) operates independently. (2) A test item that verifies whether multiple modules (e.g., module a1 and module a2) contained in one component work together. (3) A test item that verifies whether a component (e.g., component X1) works, that is, whether all modules included in the component (e.g., modules a1, a2, and a3) work when combined. (4) A test item that verifies whether multiple components (e.g., component X1 and component X2) work together.

[0055] [1.3 Repository] See Figure 1. The repository 20 is a database constructed on a cloud, realized by, for example, a mass storage device. The repository 20 is connected to a group of terminals 60 via a network. Developers send multiple sources created on the group of terminals 60 to the repository via the network. The repository 20 stores the received multiple sources.

[0056] The repository 20 is provided with a source code management tool (also referred to as SCM: Source Code Management) such as GitHub. The SCM automatically generates tasks Tx based on multiple sources stored in the repository 20. The generated tasks Tx are provided from the repository 20 to the information processing device 10.

[0057] [1.4 Information processing device] FIG. 3 is a diagram showing an example of the internal configuration of the information processing device 10 according to the embodiment. The information processing device 10 is a device for executing a process of adding a task Tx to a queue 31 managed by a test tool 30. The information processing device 10 has a control unit 11, a storage unit 12, a communication unit 13, and a reading unit 14. These units 11 to 14 are electrically connected to each other via a bus.

[0058] The control unit 11 includes a circuit configuration such as a processor. Specifically, the control unit 11 includes one or more central processing units (CPUs). The control unit 11 reads out computer programs stored in the storage unit 12 and executes various calculations and controls.

[0059] The control unit 11 may include a processor in which a predetermined program is written in advance. For example, the control unit 11 may be an integrated circuit such as a CPLD (Complex Programmable Logic Device), an FPGA (Field-Programmable Gate Array), or an ASIC (Application Specific Integrated Circuit). In this case, the control unit 11 executes various information processes based on the program written in advance.

[0060] The storage unit 12 has a volatile memory and a nonvolatile memory, and stores various types of data. The volatile memory includes, for example, a RAM (Random Access Memory). The nonvolatile memory includes, for example, a flash memory, an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a ROM (Read Only Memory). The storage unit 12 stores, for example, computer programs and various parameters in the nonvolatile memory.

[0061] The communication unit 13 is a communication interface that communicates with the repository 20, the test tool 30, and the storage 50. The communication unit 13 may communicate with these units 20, 30, and 50 wirelessly via a network or may communicate wired via a communication line. When performing wireless communication, the communication unit 13 has an antenna.

[0062] The reading unit 14 reads information from a computer-readable recording medium 15. The recording medium 15 is, for example, an optical disc such as a CD or a DVD, or a USB flash memory. The reading unit 14 is, for example, an optical drive or a USB terminal. A computer program and various parameters are recorded on the recording medium 15, and by having the reading unit 14 read the recording medium 15, the computer program and various parameters are stored in the non-volatile memory of the storage unit 12.

[0063] A task Tx provided from the repository 20 is received by the communication unit 13 and input to the control unit 11 via the bus. Priority information 51 (described later) read from the storage 50 is also received by the communication unit 13 and input to the control unit 11 via the bus. The control unit 11 calculates the priority of the task Tx based on the priority information 51 in accordance with a computer program read from the memory unit 12. Then, the control unit 11 adds the task Tx to a predetermined position in the queue 31 based on the calculated priority.

[0064] [1.5 Testing Tools] See Figure 1. The test tool 30 is a CI / CD tool such as Jenkins or CircleCI (registered trademark), and is implemented by a computer device including a processor and a memory. The test tool 30 manages a queue 31 in which multiple tasks Tx await test execution. Specifically, the test tool 30 automatically outputs the tasks Tx accumulated in the queue 31 to an execution unit 41 of the test environment 40 in sequence.

[0065] The queue 31 is a memory that stores multiple tasks Tx in a first-in, first-out (FIFO) manner, for example. In the example of Fig. 1, four tasks Tx (referred to as T1, T2, T3, and T4, respectively, when distinguishing between them) are stored in the queue 31.

[0066] 1 shows that task T4 output from the information processing device 10 (specifically, the control unit 11) is added to a queue 31 that already has tasks T1, T2, and T3 stored in that order, in the execution order between tasks T1 and T2, rather than in FIFO order. In this case, the test tool 30 outputs the tasks Tx stored in the queue 31 to the execution unit 41 in the order of tasks T1, T4, T2, and T3.

[0067] [1.6 Test environment] Referring to FIG. 1, the test environment 40 includes an execution unit 41 and a test set 42. The execution unit 41 is a computer device (e.g., a laptop PC) including a processor and a memory, and is also referred to as a "node." The execution unit 41 executes a test of the task Tx by controlling the test set 42 based on the task Tx output from the queue 31. The execution unit 41 also collects information such as the results of the test of the task Tx executed in the test set 42 (e.g., the time when the test was executed, the time required for execution, and a history indicating whether the test was successful or failed), and outputs the information to the storage 50.

[0068] The test set 42 is a hardware resource that simulates the production environment in which the software SW1 operates. Since the software SW1 is so-called "embedded software" that runs on an in-vehicle device, its operation test requires the use of hardware resources that simulate the production environment, such as the test set 42. Specifically, the test set 42 includes a circuit board 43 and a measurement unit 44.

[0069] The circuit board 43 (also referred to as a development board) is a board that imitates a circuit board (for example, a board mounted on an ECU) that will be incorporated into an in-vehicle device. The circuit board 43 may be the circuit board itself that will be incorporated into the in-vehicle device, or may be a prototype of the circuit board that will be incorporated into the in-vehicle device. The measurement unit 44 is a tool that measures the operation of the circuit board 43. The measurement unit 44 is, for example, a software tool for communication such as CANoe (registered trademark).

[0070] FIG. 4 is a diagram illustrating an example of a test environment 40 according to an embodiment. FIG. 4 illustrates a case where the test environment 40 includes a plurality of test sets 42. The plurality of test sets 42 includes a plurality of (two in FIG. 4) first test sets 42a and a second test set 42b. The number of second test sets 42b is smaller than the number of first test sets 42a, and is one in FIG. 4. Note that the plurality of test sets 42 may include a plurality of second test sets 42b.

[0071] The circuit board 43 and measurement unit 44 included in the first test set 42a are referred to as the first circuit board 43a and the first measurement unit 44a. The first measurement unit 44a measures the operation of the first circuit board 43a. Similarly, the circuit board 43 and measurement unit 44 included in the second test set 42b are referred to as the second circuit board 43b and the second measurement unit 44b. The second circuit board 43b is a board having a different function from the first circuit board 43a. The second measurement unit 44b measures the operation of the second circuit board 43b.

[0072] See FIG. 1. The circuit board 43 and the measurement unit 44 are both hardware resources with low versatility. For example, the circuit board 43 is not a general-purpose board but a dedicated board tailored for an in-vehicle device. That is, the circuit board 43 and the measurement unit 44 are used exclusively for testing the software SW1 and tend to be expensive. Providing a large number of such test sets 42 increases the cost of building the test environment 40, so it is necessary to perform operational tests of the software SW1 using a limited number of test sets 42.

[0073] As a result, when developing software SW1 for an in-vehicle device, it becomes difficult to execute a large number of tasks Tx in parallel, and it is necessary to execute tests of tasks Tx with higher priorities first in order to more quickly identify areas that need to be corrected in software SW1.

[0074] Therefore, in the information processing system 1, when adding a task Tx to the queue 31, the task Tx is added to a position according to the priority of the task Tx, thereby enabling the test of a task Tx with a high priority to be executed earlier.

[0075] [1.7 Storage] Referring to FIG. 1, the storage 50 is an auxiliary storage device such as an HDD or SSD. Priority information 51 is stored in the storage 50. The priority information 51 is information for calculating the priority of a task Tx. The priority information 51 includes, for example, version information D1, execution time information D2, required time information D3, test result information D4, safety standard information D5, and environment information D6. Note that some of the information D1 to D6 may not be included in the priority information 51. In other words, the priority information 51 is required to include at least one of the information D1 to D6. Furthermore, the priority information 51 may include information other than the information D1 to D6.

[0076] 5 is a table TB1 showing an example of version information D1 according to the embodiment. The version information D1 is information relating to the version of the source at the time when a test of task Tx is executed. For example, the version information D1 is provided from the execution unit 41 to the storage 50 every time the execution unit 41 executes a test of task Tx. The version information D1 is shown as a hash value (i.e., a value uniquely determined for the source) assigned to the source by, for example, the SCM.

[0077] 5, the version of module a1 at test execution time TM1 (e.g., the date and time when the test was executed) is shown as hash Ha1-1, and the version of module a2 at execution time TM1 is shown as hash H2-1. The version of module a1 at execution time TM2 (an execution time closer to the present time) after execution time TM1 is shown as hash Ha1-2, and the version of module a2 at execution time TM1 is shown as hash H2-1.

[0078] That is, at execution time TM2, the version of module a1 is updated from hash Ha1-1 to hash Ha1-2. In the example of FIG. 5, sources other than module a1 are not updated between execution time TM1 and execution time TM2. Therefore, of the multiple sources, module a1 is the most recently updated source. That is, by looking at the difference in hash values ​​between multiple execution times in version information D1, it is possible to determine which source has been most recently updated.

[0079] FIG. 6 is a table TB2 illustrating an example of execution time information D2 according to the embodiment. The execution time information D2 is information linking a task Tx with the execution time (most recent execution time) when a test of the task Tx was last executed. The execution time information D2 is provided from the execution unit 41 to the storage 50, for example, every time the execution unit 41 executes a test of the task Tx. The example of FIG. 6 indicates that the integration test of modules a1 and a2 was last executed at execution time TM2, and the integration test of modules a2 and a3 was last executed at execution time TM1. In other words, based on the execution time information D2, it is possible to determine which task Tx was executed most recently and which task Tx has been left unattended for a long time.

[0080] FIG. 7 is a table TB3 illustrating an example of required time information D3 according to an embodiment. The required time information D3 is information linking a task Tx with the time required to execute a test for the task Tx. The required time information D3 is provided from the execution unit 41 to the storage 50, for example, each time the execution unit 41 executes a test for the task Tx. The table TB3 in FIG. 7 stores the required time for each execution time TM1, TM2. For example, it is shown that the integration test for modules a1 and a2 took 1 minute 2 seconds at the execution time TM1 and 1 minute 6 seconds at the execution time TM2. It is also shown that the integration test for modules a2 and a3 took 2 minutes 30 seconds at the execution time TM1 and was not executed at the execution time TM2.

[0081] The required time information D3 can be used to obtain the time required for the most recent test. For example, the most recent integration test of modules a1 and a2 took 1 minute 6 seconds, and the most recent integration test of modules a2 and a3 took 2 minutes 30 seconds. The required time information D3 can also be used to obtain statistics (e.g., average or median) of the time required for past tests. For example, the average time required for the past two integration tests of modules a1 and a2 is 1 minute 4 seconds.

[0082] 8 is a table TB4 showing an example of test result information D4 according to the embodiment. The test result information D4 is information linking a task Tx with the test result of the task Tx. The test result includes a test failure (NG) and a test success (OK). Here, a test failure includes, for example, a case where the desired measurement values ​​are not met in the measurement unit 44. Furthermore, a test success includes, for example, a case where all the desired measurement values ​​are met in the measurement unit 44.

[0083] Table TB4 in Fig. 8 stores test results for each of execution points TM1 and TM2. Test result information D4 is provided from the execution unit 41 to the storage 50, for example, each time the execution unit 41 executes a test of task Tx. For example, it is shown that the integration test of modules a1 and a2 failed at execution point TM1 and was successful at execution point TM2. It is shown that the integration test of modules a2 and a3 was successful at execution point TM1 and was not executed at execution point TM2. It is also shown that the integration test of components X3 and X1 failed at both execution points TM1 and TM2.

[0084] The test result information D4 can be used to obtain the results of the most recent test. For example, the most recent test result of the integration test of modules a1 and a2 is a success, and the most recent test result of the integration test of modules a2 and a3 is a success. In contrast, the most recent test result of the integration test of components X3 and X1 is a failure. Furthermore, the test result information D4 can be used to obtain information on how many consecutive test failures have occurred in the past. For example, the integration test of components X3 and X1 has failed two consecutive times, counting from the most recent.

[0085] FIG. 9 is a table TB5 illustrating an example of safety standard information D5 according to the embodiment. The safety standard information D5 is information related to the safety standard required of the source at the time when a test of the task Tx is executed. The safety standard information D5 is provided from the execution unit 41 to the storage 50, for example, every time the execution unit 41 executes a test of the task Tx. The safety standard is, for example, a safety standard for a vehicle, more specifically, an automobile. The safety standard is, for example, an Automotive Safety Integrity Level (ASIL) of ISO 26262. The ASIL has multiple stages, for example, QM, ASIL-A, ASIL-B, ASIL-C, and ASIL-D, and the required standards become stricter in this order. That is, the lenientest conditions are imposed on QM, and the strictest conditions are imposed on ASIL-D.

[0086] In the example of Figure 9, the safety standard of module a1 at execution time TM1 is shown as QM, and the safety standard of module a1 at execution time TM2 is shown as ASIL-A. In other words, it is shown that the safety standard of module a1 has been raised by one level following the update from execution time TM1 to execution time TM2 (Figure 5).

[0087] For sources other than module a1, there is no update from execution time TM1 to execution time TM2, so there is no change in safety standards. For example, the safety standard for modules a2, a3, b1, and b2 is QM, and the safety standard for component X3 is ASIL-D. By looking at the safety standard information D5 at the most recent execution time (execution time TM2 in Figure 9), it is possible to understand the safety standards currently required.

[0088] 10 is a table TB6 illustrating an example of environment information D6 according to an embodiment. The environment information D6 is information linking a task Tx with a test set 42 used in testing the task Tx. The environment information D6 is provided from the execution unit 41 to the storage 50, for example, each time the execution unit 41 executes a test of the task Tx. For example, the environment information D6 indicates that the integration test of modules a1 and a2 and the integration test of modules a2 and a3 are executed using a first test set 42a, and that the integration test of modules a3 and a1 and the test of component X1 are executed using a second test set 42b. The environment information D6 makes it possible to obtain the type of test set 42 used in testing the task Tx.

[0089] [1.8 Information Processing Methods] 11 is a flowchart showing an example of an information processing method executed by the information processing system 1. First, a developer creates multiple sources using the terminal group 60, and stores the multiple sources in the repository 20 via the network. The multiple sources are stored in the repository 20 at appropriate times.

[0090] The SCM that manages the repository 20 creates a task Tx, for example, periodically (also referred to as a polling process) or when a new source is stored in the repository 20 (also referred to as a push process) (step S11). For example, if a new version of a module a1 is stored in the repository 20 when modules a1, a2, a3, b1, and b2 and a component X3 are already stored in the repository 20, the SCM creates a task Tx related to the module a1. For example, the SCM creates a task Tx for executing an integration test of the modules a1 and a2, a task Tx for executing an integration test of the modules a1 and a3, a task Tx for executing a test of the component X1, and a task Tx for executing an integration test including the component X1 (e.g., an integration test of the components X1 and X2).

[0091] Thereafter, the created one or more tasks Tx are provided from the repository 20 to the information processing device 10. With the above, step S11 is completed.

[0092] The communication unit 13 of the information processing device 10 outputs the task Tx received from the repository 20 to the control unit 11. When the control unit 11 receives a new input of the task Tx, it reads the priority information 51 from the storage 50 (step S12). The control unit 11 may read, for example, all of the information D1 to D6 included in the priority information 51, or may read only a portion of the information D1 to D6 that is used to calculate the priority of the task Tx. The read priority information 51 is input to the control unit 11 via the communication unit 13. This completes step S12.

[0093] Next, the control unit 11 calculates the priority of the task Tx based on the priority information 51 (step S13). The priority is calculated by at least one method from the first to fifth calculation examples shown below. The control unit 11 may calculate multiple types of priorities based on multiple pieces of information D1 to D6 by using two or more of the first to fifth calculation examples. Examples of priority calculation will be described below.

[0094] [1.8.1 First calculation example: Prioritize neglected tasks] The control unit 11 reads the execution time information D2 and calculates a higher priority for a task Tx that has been left untested for a long time (i.e., a task Tx that has been left untested for a long time). By testing a task Tx that has not been tested for a while earlier, it is possible to prevent the scale of source modification from becoming larger.

[0095] For example, in the case of Figure 6, the most recent execution time TM1 of task Tx (in this calculation example, an example of the "second task" of the present disclosure, and referred to as task a2-a3 as appropriate) related to the integration test of modules a2 and a3 is earlier (older) than the most recent execution time TM2 of task Tx (in this calculation example, an example of the "first task" of the present disclosure, and referred to as task a1-a2 as appropriate) related to the integration test of modules a1 and a2.

[0096] Therefore, the control unit 11 calculates the priority of tasks a2-a3 to be higher than the priority of tasks a1-a2. If a higher numerical value is assigned to task Tx as the priority increases, the control unit 11 assigns, for example, a priority of "2" to tasks a2-a3 and a priority of "1" to tasks a1-a2.

[0097] The control unit 11 may calculate the priority according to the values ​​of the execution times TM1 and TM2. For example, the time from the execution times TM1 and TM2 to the present time may be used as the priority value. In this case, since the time from the execution time TM2 to the present time is longer than the time from the execution time TM1 to the present time, a higher value is calculated as the priority of task a2-a3.

[0098] [1.8.2 2nd calculation example: Prioritize tasks that can be completed in the shortest time] The control unit 11 reads the required time information D3 and calculates a higher priority for a task Tx that can be tested in a short time. By testing a task Tx that can be tested in a short time first, the number of tests that can be executed per unit time can be increased, and the number of tasks waiting to be executed can be reduced.

[0099] For example, in the case of Figure 7, the time required to test task Tx (in this calculation example, an example of the "second task" of the present disclosure, and referred to as task a1-a2 as appropriate) related to the integration testing of modules a1 and a2 is shorter than the time required to test task Tx (in this calculation example, an example of the "first task" of the present disclosure, and referred to as task a2-a3 as appropriate) related to the integration testing of modules a2 and a3.

[0100] Therefore, the control unit 11 calculates the priority of tasks a1-a2 to be higher than the priority of tasks a2-a3. If a higher numerical value is assigned to task Tx as the priority increases, the control unit 11 assigns, for example, a priority of "2" to tasks a1-a2 and a priority of "1" to tasks a2-a3.

[0101] The control unit 11 may calculate the priority according to the required time value. For example, the priority value may be a value obtained by subtracting the required time from a predetermined value E1. Here, the predetermined value E1 is set to a value sufficiently larger than each required time. In this case, the value (E1-66) obtained by subtracting the most recent required time for tasks a1-a2 (e.g., 1 minute 6 seconds = 66 seconds) from the predetermined value E1 is greater than the value (E1-150) obtained by subtracting the most recent required time for tasks a2-a3 (e.g., 2 minutes 30 seconds = 150 seconds) from the predetermined value E1. Therefore, a higher value is calculated as the priority of tasks a1-a2. Note that in calculating the priority, the control unit 11 may use the most recent required time value or a statistical value of the required time (e.g., the average value of the required times over the past several times).

[0102] [1.8.3 3rd calculation example: Prioritize tasks with recent failure history] The control unit 11 reads the test result information D4 and calculates a higher priority for the task Tx that has the most recent failure history. By executing the test for the failed task Tx first, it is possible to check more quickly whether the error has been resolved.

[0103] For example, in the case of Figure 8, the most recent test result of task Tx (in this calculation example, an example of the "first task" of the present disclosure, and referred to as task X1-X2 as appropriate) related to the integration test of components X1 and X2 is a success, and the most recent test result of task Tx (in this calculation example, an example of the "second task" of the present disclosure, and referred to as task X3-X1 as appropriate) related to the integration test of components X3 and X1 is a failure.

[0104] Therefore, the control unit 11 calculates the priority of tasks X3-X1 to be higher than the priority of tasks X1-X2. If a higher numerical value is assigned to task Tx as the priority increases, the control unit 11 assigns, for example, a priority of "2" to tasks X3-X1 and a priority of "1" to tasks X1-X2.

[0105] The control unit 11 may calculate the priority according to the number of consecutive failures since the most recent time. For example, the priority may be a value obtained by adding a constant (for example, 1) to the number of consecutive failures. In this case, the control unit 11 calculates the priority of tasks X1-X2 as 1 (=0+1) because the number of consecutive failures since the most recent time for tasks X1-X2 is 0 (the most recent test result was successful). Similarly, the control unit 11 calculates the priority of tasks X3-X1 as 3 (=2+1) because the number of consecutive failures since the most recent time for tasks X3-X1 is 2. As a result, a higher priority value is calculated for tasks X3-X1, which have a longer failure history.

[0106] [1.8.4 4th calculation example: Prioritize tasks that require stricter safety standards] The control unit 11 reads the safety standard information D5 and calculates a higher priority for a task Tx that requires stricter safety standards. Tasks Tx that require stricter safety standards have a narrower range of values ​​that are allowable in tests by the measurement unit 44, for example, and are more likely to produce errors. By executing tests on such tasks Tx first, source errors can be found more quickly.

[0107] For example, in the case of Figure 9, the ASIL-D required for component X3 is the strictest among the sources at the most recent execution time, followed by ASIL-A required for module a1. The QM required for other sources (e.g., modules a2, a3, etc.) is the lenientest.

[0108] Consider task Tx, which combines sources as shown in Figure 8. For example, when performing an integration test of modules a1 and a2, the safety standard required for task a1-a2, which includes modules a1 and a2, is ASIL-A (the safety standard of module a1), which is the strictest of the standards required for the sources included in task a1-a2. Also, when performing an integration test of modules a2 and a3, the safety standard required for task a2-a3, which includes modules a2 and a3, is QM (the safety standard of modules a2 and a3), which is the strictest of the standards required for the sources included in task a2-a3.

[0109] As a result of the above, the safety standard required for testing tasks a1-a2 (which in this calculation example is an example of the "second task" of the present disclosure) is stricter than the safety standard required for testing tasks a2-a3 (which in this calculation example is an example of the "first task" of the present disclosure), so the control unit 11 calculates the priority of tasks a1-a2 to be higher than the priority of tasks a2-a3. If a higher numerical value is assigned to task Tx the higher the priority, the control unit 11 assigns, for example, a priority of "2" to tasks a1-a2 and a priority of "1" to tasks a2-a3.

[0110] The control unit 11 may calculate the priority according to the strictness (level) of the safety standard. For example, the control unit 11 may assign a priority of "5" to task Tx, which requires the strictest ASIL-D, "4" to ASIL-C, "3" to ASIL-B, "2" to ASIL-A, and "1" to QM.

[0111] [1.8.5 5th calculation example: Prioritize tasks with smaller test sets] The control unit 11 reads the environment information D6 and calculates a higher priority for the task Tx that uses a test set 42 that is less numerous in the environment information D6. By executing tests on the rarer test set 42 first, it is possible to reduce the free time of the rarer test set 42.

[0112] For example, consider a case where the test environment 40 includes two first test sets 42a and one second test set 42b, as shown in Fig. 4. In the example of Fig. 10, the number of second test sets 42b linked to tasks Tx (in this calculation example, an example of a "second task" in the present disclosure and referred to as task a3-a1 as appropriate) related to integration testing of modules a3 and a1 is smaller than the number of first test sets 42a linked to tasks Tx (in this calculation example, an example of a "first task" in the present disclosure and referred to as task a1-a2 as appropriate) related to integration testing of modules a1 and a2.

[0113] Therefore, the control unit 11 calculates the priority of task a3-a1 to be higher than the priority of task a1-a2. If a higher numerical value is assigned to task Tx as the priority increases, the control unit 11 assigns, for example, a priority of "2" to task a3-a1 and a priority of "1" to task a1-a2.

[0114] The control unit 11 may calculate the priority according to the number of test sets 42. For example, the priority value may be a value obtained by subtracting the number of test sets 42 from a predetermined value E2. Here, the predetermined value E2 is set to a value that is sufficiently larger than the number of each test set 42. In this case, the value (E2-1) obtained by subtracting the number of second test sets 42b (1) from the predetermined value E2 is larger than the value (E2-2) obtained by subtracting the number of first test sets 42a (2) from the predetermined value E2. Therefore, a higher value is calculated as the priority of task a3-a1 linked to the second test set 42b.

[0115] 1.8.6 Adding a task to the queue The calculated priority is stored, for example, in the storage unit 12. This completes step S13.

[0116] Next, the control unit 11 adds the task Tx to the queue 31 based on the priority (step S14). For example, consider a case where a new task T4 is added to the queue 31 when tasks T1, T2, and T3 are already stored in the queue 31, as shown in FIG.

[0117] If the priority of task T4 is lower than task T1 but higher than task T2, the control unit 11 adds task T4 to the queue 31 in an execution order that is later than task T1 but earlier than task T2 (i.e., between tasks T1 and T2).

[0118] For example, if the priority calculation is based on the above "First Calculation Example," the priority of task T1 is "3," the priorities of tasks T2 and T3 are each "1," and the priority of newly added task T4 is "2," the control unit 11 adds task T4 between task T1 and task T2 as described above. As a result, multiple tasks Tx are accumulated in the queue 31 in descending order of priority, so that the task Tx with the highest priority can be tested first.

[0119] Furthermore, when calculating the priority based on a plurality of calculation examples, the importance may be set in advance for each calculation example, and when adding the task Tx to the queue 31, the priority may be evaluated in descending order of importance in the calculation example.

[0120] Here, consider a case where two types of priorities are calculated using a first calculation example and a second calculation example. For example, the importance of the priority calculated using the first calculation example (hereinafter referred to as the first priority) is set higher than the importance of the priority calculated using the second calculation example (hereinafter referred to as the second priority). This setting is made, for example, by an operator who manages the information processing device 10, and is stored in advance in the storage unit 12 as one of the parameters.

[0121] In this case, the control unit 11 first compares the first priorities of the tasks T1, T2, and T3 stored in the queue 31 and the newly added task T4. For example, if the first priorities of the tasks T1, T2, and T3 are all "2" and the first priority of the task T4 is also "2," it is not possible to identify an appropriate position in the queue 31 for adding the task T4 based on the first priority alone.

[0122] Therefore, next, the control unit 11 compares the second priorities of the tasks T1, T2, and T3 stored in the queue 31 with the newly added task T4. For example, if the second priority of task T1 is "3," the second priorities of tasks T2 and T3 are each "1," and the second priority of the newly added task T4 is "2," the control unit 11 adds task T4 between task T1 and task T2 as described above.

[0123] In this way, by comparing the tasks Tx in descending order of importance among a plurality of types of priority, it is possible to add the task Tx to a more suitable position in the queue 31. Note that when all priorities are the same, a newly added task Tx may be added to the queue in the execution order after previously accumulated tasks Tx, based on the FIFO method.

[0124] Furthermore, when calculating the priority based on multiple calculation examples, the "weight" of the priority may be set in advance for each calculation example, and the position at which task Tx is added to queue 31 may be determined based on the overall priority calculated by adding up the multiple priorities with each priority assigned a "weight."

[0125] For example, consider a case where the weight of the first priority is set to "2" and the weight of the second priority is set to "1." In this case, the overall priority is calculated as "first priority x 2 + second priority x 1." The weight of each priority is set, for example, by an operator who manages the information processing device 10, and is stored in advance in the storage unit 12 as one of the parameters.

[0126] This completes step S14. The tasks Tx stored in the queue 31 are output to the execution unit 41 at an appropriate timing by the test tool 30, and the tests are executed. As a result, the tests can be executed starting with the task Tx with the highest priority.

[0127] 2. Variations Modifications of the embodiment will be described below. In the modifications, the same components as those in the above embodiment will be denoted by the same reference numerals and the description thereof will be omitted.

[0128] [2.1 Variations in information processing methods] 12 is a flowchart showing an information processing method according to a modified example. In the above embodiment, for example, the priority of a task T4 to be newly added to the queue 31 is calculated, and the priority is compared with the priorities (already calculated priorities) of the tasks T1, T2, and T3 already stored in the queue 31, thereby determining the position where the task T4 is to be added.

[0129] In contrast to this, in this modified example, when a new task T4 is added to the queue 31, the priorities of the tasks T1, T2, and T3 already stored in the queue 31 are recalculated. Then, based on the priorities, not only is task T4 simply added to the queue 31, but the order of tasks T1 to T3 in the queue 31 is also reassigned.

[0130] 12, steps S11 and S12 are executed in the same manner as in the above embodiment. Thereafter, the control unit 11 calculates the priority of task T4 in the same manner as in step S13, and recalculates the priorities of tasks T1, T2, and T3 in the queue 31 (step S15).

[0131] 13 is a diagram illustrating the priority of each task according to a modified example. For example, suppose that the priorities of tasks T1, T2, and T3 already stored in queue 31 are "3," "2," and "1," respectively, before task T4 is added. Then, suppose that in step S15, the priority of task T4 is calculated to be "3," and the priorities of tasks T1, T2, and T3 are recalculated to be "4," "1," and "2," respectively.

[0132] In this case, the control unit 11 rearranges the accumulation order of tasks T1 to T3 in the queue 31 based on their respective priorities after step S15. Specifically, the control unit 11 rearranges the tasks T1, T3, and T2 in descending order of priority. Then, the control unit 11 adds task T4 between tasks T1 and T3. As a result, the final accumulation order of tasks in the queue 31 becomes tasks T1, T4, T3, and T2 in descending order of test execution.

[0133] In this way, not only is task T4 added to a suitable position, but in the above example, the order of tasks T2 and T3 is also swapped. Therefore, each time a task Tx is added to the queue 31, the order of the tasks Tx already stored in the queue 31 can be reviewed, making it possible to more reliably execute the test of a task Tx with a higher priority first. This method is particularly suitable when it is desired to advance the execution order of a task Tx that has been postponed (i.e., left unattended) for a long time in the queue 31.

[0134] Note that if the priorities of all tasks Tx in the queue 31 are recalculated every time a task Tx is added to the queue 31, an excessive processing load may be placed on the control unit 11. For this reason, the control unit 11 may execute steps S15 and S16, for example, every time a predetermined number of tasks Tx are added to the queue 31, and execute steps S13 and S14 at other times. Also, the control unit 11 may not recalculate the priorities of the tasks Tx in the queue 31 during push processing, but may recalculate the priorities of the tasks Tx in the queue 31 only during polling processing. With this configuration, it is possible to reorder the tasks Tx in the queue 31 while reducing the processing load on the control unit 11.

[0135] [2.2 Task Variations] The control unit 11 may subdivide the task Tx into a plurality of divided tasks DTx for each test item, for example, and then calculate the priorities of the plurality of divided tasks DTx. The control unit 11 divides the task Tx into a plurality of divided tasks DTx based on at least one of the test environment used by the task Tx, the safety standard required for the task Tx, the test result of the task Tx, the execution time of the test of the task Tx, and the time required for the test of the task Tx.

[0136] For example, an example will be described in which a task Tx is divided into a plurality of divided tasks DTx based on a safety standard. As shown in Fig. 9, a task Tx (hereinafter referred to as task X3) related to an operation test of a component X3 requires ASIL-D as a safety standard. However, ASIL-D is not required for all test items included in task X3. For example, some of the test items included in task X3 may include items that require QM as a safety standard.

[0137] For this reason, when calculating the priority, the control unit 11 divides task X3 into divided tasks X3a and X3b for each test item based on the safety standard. For example, divided task X3a includes only test items of task X3 that require QM. Also, divided task X3b includes only test items of task X3 that require a safety standard of ASIL-A or higher (ASIL-A, B, C, D).

[0138] 14 is a table TB4a showing test result information D4 according to a modified example. In table TB4a, task X3 is divided into multiple divided tasks X3a and X3b. By subdividing the test result information D4 for each of the multiple divided tasks X3a and X3b, it is possible to check the test results in more detail, for example, to determine whether the test of divided task X3a was successful and the test of divided task X3b was unsuccessful at execution time TM1. This makes it easier to narrow down which part of task X3 has an error, allowing for a more rapid response to the error.

[0139] Furthermore, in step S13, the control unit 11 may calculate the priority of each of the divided tasks TDx. Furthermore, in step S14, the control unit 11 may determine the position of the divided task TDx to be newly added to the queue 31 based on the priority of the divided tasks TDx already stored in the queue 31. This allows for more detailed testing.

[0140] [3. Notes] This disclosure includes the contents set forth in the following appendices.

[0141] [Appendix 1] An information processing device that supports development of software to be executed in an in-vehicle device, a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority being given priority in the execution order; Information processing device.

[0142] [4. Supplementary Notes] It should be noted that at least some of the above-described embodiments and various modifications may be combined with each other in any desired manner. Furthermore, the embodiments and modifications disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present disclosure is defined by the claims, and all modifications within the meaning and scope equivalent to the claims are intended to be included. [Explanation of symbols]

[0143] 1. Information Processing Systems 10. Information processing equipment 11 Control section 12 Storage section 13 Communications Department 14 Reading unit 15 Recording media 20 Repositories 30 Testing Tools 31 Queue 40 Test Environment 41 Executive Department 42 test sets 42a First test set 42b Second test set 43 Circuit Board 43a First circuit board 43b 2nd circuit board 44 Measuring part 44a 1st measurement section 44b Second measuring section 50 Storage 51 Priority information 60 terminals SW1 Software a1,a2,a3,b1,b2 modules X1, X2, X3 components Tx,T1,T2,T3,T4 tasks DTx Split Task D1 Version Information D2 Execution time information D3 Travel time information D4 Test Result Information D5 Safety standard information D6 Environmental information TB1,TB2,TB3,TB4,TB4a,TB5,TB6 Tables TM1, TM2 execution time E1,E2 Predetermined value

Claims

1. An information processing system that supports the development of software executed by an on-board device including an on-board ECU, a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; the tasks include a first task and a second task whose most recent execution time is earlier than the most recent execution time of the first task; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority given first in the execution order; calculating a priority of the second task to be higher than a priority of the first task; the priority information includes information regarding at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task; Information processing system.

2. An information processing system that supports development of software executed by an in-vehicle device including an in-vehicle ECU, a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority given first in the execution order; the priority information includes information on at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task, and environment information linking the task and a test set used in the test of the task; The test environment includes: the test set including a circuit board and a measurement unit for measuring the operation of the circuit board; an execution unit that executes a test of the task by controlling the test set based on the task output from the queue. Information processing system.

3. the test sets include a plurality of first test sets and a plurality of second test sets, the number of which is smaller than the number of the first test sets; the tasks include a first task linked to the first test set and a second task linked to the second test set in the environment information; the control unit calculates the priority of the second task to be higher than the priority of the first task; The information processing system according to claim 2 .

4. The control unit Calculating the priority of the task already stored in the queue based on the priority information; rearranging the order of accumulation in the queue so that a fourth task, which has a higher priority than the third task, among the tasks already accumulated in the queue, is executed before the third task; The information processing system according to any one of claims 1 to 3.

5. The control unit Dividing the task into a plurality of sub-tasks based on at least one of the test environment, the vehicle safety standard required for the task, the results, the time points at which past tests of the task were performed, and the required time; calculating priorities of the divided tasks based on the priority information; Among the plurality of divided tasks, a second divided task having a higher priority than the first divided task is stored in the queue in the order of execution prior to the first divided task. The information processing system according to any one of claims 1 to 3.

6. An information processing system that supports the development of software executed by an on-board device including an on-board ECU, a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority given first in the execution order; the priority information includes information regarding at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task; the tasks include a first task and a second task whose required time is shorter than the required time of the first task; The control unit calculating a priority of the second task to be higher than a priority of the first task; Calculating the priority of the task already stored in the queue based on the priority information; rearranging the order of accumulation in the queue so that a fourth task, which has a higher priority than the third task, among the tasks already accumulated in the queue, is executed before the third task; Information processing system.

7. An information processing system that supports the development of software executed by an on-board device including an on-board ECU, a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority given first in the execution order; the priority information includes information regarding at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task; the tasks include a first task whose most recent result is success and a second task whose most recent result is failure; The control unit calculating a priority of the second task to be higher than a priority of the first task; Calculating the priority of the task already stored in the queue based on the priority information; rearranging the order of accumulation in the queue so that a fourth task, which has a higher priority than the third task, among the tasks already accumulated in the queue, is executed before the third task; Information processing system.

8. An information processing system that supports the development of software executed by an on-board device including an on-board ECU, a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority given first in the execution order; the priority information includes information regarding at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task; the tasks include a first task and a second task whose required time is shorter than the required time of the first task; The control unit calculating a priority of the second task to be higher than a priority of the first task; Dividing the task into a plurality of sub-tasks based on at least one of the test environment, the vehicle safety standard required for the task, the result, the execution time, and the required time; calculating priorities of the divided tasks based on the priority information; Among the plurality of divided tasks, a second divided task having a higher priority than the first divided task is stored in the queue in the order of execution prior to the first divided task. Information processing system.

9. An information processing system that supports the development of software executed by an on-board device including an on-board ECU, a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority given first in the execution order; the priority information includes information regarding at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task; the tasks include a first task whose most recent result is success and a second task whose most recent result is failure; the control unit calculates a priority of the second task to be higher than a priority of the first task; Dividing the task into a plurality of sub-tasks based on at least one of the test environment, the vehicle safety standard required for the task, the result, the execution time, and the required time; calculating priorities of the divided tasks based on the priority information; Among the plurality of divided tasks, a second divided task having a higher priority than the first divided task is stored in the queue in the order of execution prior to the first divided task. Information processing system.

10. An information processing system for supporting the development of software to be executed on an in-vehicle device, comprising: a control unit that adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test; The control unit reading out priority information including information about the task from a storage in which the priority information is stored; Calculating the priority of the task based on the priority information; comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority given first in the execution order; the priority information includes information regarding a vehicle safety standard required for the task; the tasks include a first task and a second task for which the safety standard required is stricter than the safety standard required for the first task; the control unit calculates the priority of the second task to be higher than the priority of the first task; Information processing system.

11. The on-board device includes an on-board ECU, The information processing system according to claim 10.

12. the priority information includes information regarding at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task; The information processing system according to claim 11.

13. The safety standard is ASIL (Automotive Safety Integrity Level) of ISO 26262. The information processing system according to any one of claims 10 to 12.

14. An information processing method for an information processing system that supports development of software executed by an in-vehicle device including an in-vehicle ECU, comprising: the information processing system includes a control unit, The method includes a step in which the control unit adds a task provided from a repository storing a plurality of sources included in the software to a queue in which the task waits for execution of a test, The adding step includes: a first step of reading priority information including information about the task from a storage in which the priority information is stored; a second step of calculating a priority of the task based on the priority information; a third step of comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority being given priority in the execution order; Including, the priority information includes information on at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task, and environment information linking the task and a test set used in the test of the task; The test environment includes: the test set including a circuit board and a measurement unit for measuring the operation of the circuit board; an execution unit that executes a test of the task by controlling the test set based on the task output from the queue. Information processing methods.

15. A computer program for supporting the development of software executed by an in-vehicle device including an in-vehicle ECU, The computer program includes: adding a task provided from a repository storing a plurality of sources included in the software to a queue in which the task is to be tested; The adding step includes: a first step of reading priority information including information about the task from a storage in which the priority information is stored; a second step of calculating a priority of the task based on the priority information; a third step of comparing the priorities of the tasks already stored in the queue with the priorities of the tasks to be newly added to the queue, and adding the tasks to the queue with the higher priority being given priority in the execution order; Including, the priority information includes information on at least one of a test environment, a result of a past test of the task, a time point at which the past test of the task was performed, and a time required for the past test of the task, and environment information linking the task and a test set used in the test of the task; The test environment includes: the test set including a circuit board and a measurement unit for measuring the operation of the circuit board; an execution unit that executes a test of the task by controlling the test set based on the task output from the queue. Computer program.

Images