System introduction support device, system introduction support method, and system introduction support program

Abstract

To make it possible to easily and appropriately provide a user with selectable requirements for a system to be introduced.SOLUTION: A system introduction support device 100 for supporting selection of requirements when introducing a system to be introduced comprises a CPU 201 and a storage 205. The storage 205 is configured to store, for the system to be introduced, a plurality of candidate requirement sets each including system configuration information indicating a system configuration, a safety level in the system configuration, and operation requirement information including one or more operation requirements in the system configuration. The CPU 201 is configured to calculate a cost and productivity and / or convenience for each of the candidate requirement sets, and display, for each candidate requirement set in an identifiable manner, a combination of the cost, the productivity and / or convenience, and the safety level in the system configuration as trade-off factors.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a technique for supporting the introduction of a predetermined introduction target system. [Background technology]

[0002] For example, autonomous driving systems are generally expected to be introduced as an alternative to manned driving in applications such as passenger transportation and logistics, and various demonstration experiments are being conducted. When introducing autonomous driving to such applications, it is necessary to comprehensively determine the merits of autonomous driving rather than manned driving, taking into consideration the productivity gained as a result of the introduction, the costs required for construction and operation, and the necessary safety measures. For this reason, it is expected that a PoC (Proof of Concept) will be conducted before practical use in order to verify such aspects.

[0003] In general system development, various system requirements are determined based on customer requests, and design and implementation proceed based on those requirements, but after the release of the system goes into operation, it often becomes clear that the requests or requirements are either excessive or insufficient. In such cases, additional costs such as financial costs for additional hardware and software development, and time costs for updating the system are incurred.

[0004] In the case of autonomous driving systems, it is assumed that a PoC will be carried out as described above, and it is possible to make partial changes to the system based on the results of the PoC before deciding on the final system. However, it is necessary to take into account the cost of modifications and opportunity losses due to the modification period, and to determine system requirements that can prevent rework costs as much as possible so that the system can move quickly to the practical application phase after the PoC.

[0005] As a technique for configuring a system taking such changes in requirements into account, for example, Patent Document 1 discloses a method for predicting future changes in requirements over time that may occur in the system being developed based on past cases, and outputting a system configuration proposal that satisfies the requirements in line with the change scenario. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2018-49361 A Summary of the Invention [Problem to be solved by the invention]

[0007] For example, the technology of Patent Document 1 makes it possible to generate a system configuration plan that has the capacity to respond to changes by considering changes in each requirement over time based on past cases when developing a new system.

[0008] On the other hand, when defining requirements for a system such as an autonomous driving system, multiple trade-off factors must be considered, such as available costs, desired productivity, and how to ensure the safety of the system and its operation. Since it is impossible to generate requirements that satisfy all of them, verification through PoC and reaching a consensus with the customer are necessary.

[0009] Furthermore, in safety-related systems such as autonomous driving systems, system modifications require additional costs such as safety analysis, so requirements must be defined in a way that minimizes additional development costs after PoC.

[0010] The present invention has been made in consideration of the above circumstances, and an object of the present invention is to provide a technique that can easily and appropriately provide a user with selectable requirements for a target system. [Means for solving the problem]

[0011] In order to achieve the above-mentioned object, a system introduction support device according to one aspect is a system introduction support device that supports the selection of requirements when introducing a target system, and is equipped with a processor and a storage device, wherein the storage device stores a plurality of candidate requirement sets for the target system, the candidate requirement sets including system configuration information indicating a system configuration, a safety level for the system configuration, and operational requirement information including one or more operational requirements for the system configuration, and the processor calculates cost, productivity, and / or convenience for each of the candidate requirement sets, and displays in an identifiable manner a combination of safety level, productivity and / or convenience for the system configuration, and cost, which are trade-off elements, for each of the candidate requirement sets. Effect of the Invention

[0012] According to the present invention, selectable requirements for a target system can be easily and appropriately provided to a user. [Brief description of the drawings]

[0013] [Figure 1A] FIG. 1A is a diagram illustrating an example of the configuration of a system introduction support system according to an embodiment. [Figure 1B] FIG. 1B is a diagram illustrating a configuration example of an autonomous driving system to be considered for introduction according to one embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of the configuration of a system introduction support device according to an embodiment. [Figure 3A] FIG. 3A is a diagram illustrating a first example of an input screen according to an embodiment. [Figure 3B] FIG. 3B is a diagram illustrating a second example of an input screen according to an embodiment. [Figure 3C] FIG. 3C is a diagram illustrating an example of an output screen according to an embodiment. [Figure 4A] FIG. 4A is a diagram illustrating a first example of system configuration data according to an embodiment. [Figure 4B] FIG. 4B is a diagram showing a second example of system configuration data according to an embodiment. [Figure 5A] FIG. 5A is a diagram illustrating an example of a usage-based candidate correspondence table according to an embodiment. [Figure 5B] FIG. 5B is a diagram illustrating an example of an operational requirement set detail table according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of KPI calculation method data according to an embodiment. [Figure 7] FIG. 7 is a flowchart of a candidate presentation process according to an embodiment. [Figure 8] FIG. 8 is a flowchart of a requirement presentation process according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] The following embodiments will be described with reference to the drawings. Note that the following embodiments do not limit the scope of the invention, and not all of the elements and combinations thereof described in the embodiments are necessarily essential to the solution of the invention.

[0015] In the following description, information may be described using the expression "AAA table", but the information may be expressed in any data structure. In other words, to show that the information does not depend on the data structure, the "AAA table" may be called "AAA information".

[0016] In the following description, the processing may be described with a "program" as the operating subject, but since the program is executed by a processor to perform a defined processing while appropriately using at least one of the memory unit and the interface unit, the operating subject of the processing may be the processor (or a computer (device) having a processor, or a computer system). The program may be installed on the computer from a program source. The program source may be, for example, a program distribution server or a recording medium readable by a computer. In the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs. At least a part of the processing realized by executing a program may be realized by a hardware circuit (for example, an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array)).

[0017] FIG. 1A is a diagram illustrating an example of the configuration of a system introduction support system according to an embodiment.

[0018] The system introduction support system 10 includes a system introduction support device 100 and a terminal 102. The system introduction support device 100 and the terminal 102 are connected via a network 101. The network 101 is, for example, a communication path such as a wired LAN (Local Area Network), a wireless LAN, or a WAN (Wide Area Network). The system introduction support device 100 performs a process of supporting the introduction of an autonomous driving system, which is an example of an introduction target system (for example, a support process for selecting requirements). The terminal 102 is a device used by a system builder (also simply called a user) of the autonomous driving system, and displays various information from the system introduction support device 100, accepts various operation inputs by the system builder, and notifies the system introduction support device 100. The system builder may directly use the system introduction support device 100, in which case the system introduction support system 10 does not need to include the terminal 102.

[0019] FIG. 1B is a diagram illustrating a configuration example of an autonomous driving system to be considered for introduction according to one embodiment.

[0020] An autonomous driving system 1, which is an example of a system to be introduced, is a system that manages autonomous driving of an autonomous vehicle 120, which is an example of a moving body. The autonomous driving system 1 includes a control center 110, a base station 111, an autonomous vehicle 120, a bus stop / parking area 150, and the like. The base station 111 is, for example, a base station that constitutes a mobile phone network, and relays communications between the autonomous vehicle 120, the manned vehicle 140, the infrastructure of the bus stop / parking area 150, and the control center 110. The control center 110 monitors the operation status of the autonomous vehicle 120 and manages its operation.

[0021] An autonomous vehicle 120 travels on roads 160 in the target introduction area, circulating around bus stops and parking areas 150. In addition to the autonomous vehicle 120, manned vehicles 140 also travel on the roads 160. Users 130 of the autonomous driving system 1 get on and off the autonomous vehicle 120 at the bus stops and parking areas 150. The autonomous vehicle 120 travels while avoiding contact with manned vehicles 140, pedestrians, and infrastructure such as traffic lights and utility poles.

[0022] Next, the system introduction support device 100 will be described in detail.

[0023] FIG. 2 is a diagram illustrating an example of the configuration of a system introduction support device according to an embodiment.

[0024] The system introduction support device 100 is configured, for example, by a computer such as a general personal computer or a server, and includes a CPU 201, a communication interface (I / F: Interface) 202, memory 204, storage 205 as an example of a storage device, and an internal bus 203 that connects each component.

[0025] The communication I / F 202 is, for example, an interface such as a wired LAN card or a wireless LAN card, and communicates with other devices (for example, the terminal 102) via the network 101.

[0026] The CPU 201 is an example of a processor, and executes various processes according to programs stored in the memory 204 and / or the storage 205 .

[0027] The memory 204 is, for example, a RAM (Random Access Memory), and stores necessary information and programs executed by the CPU 201. A program previously installed in the storage 205 is loaded into the memory 204 by the CPU 201, and the loaded program is executed by the CPU 201.

[0028] The storage 205 is, for example, a hard disk or a flash memory, and stores programs executed by the CPU 201 and data used by the CPU 201. In this embodiment, the storage 205 stores a candidate presentation program 211, a requirement presentation program 212, system configuration data 231, a use-specific candidate correspondence table 232, an operational requirement set details table 233, KPI calculation method data 234, and productivity, convenience, and cost calculation results 235. Details of the tables and data will be described later. In this embodiment, the candidate presentation program 211 and the requirement presentation program 212 correspond to the system introduction support program.

[0029] The candidate presentation program 211 includes a use and driving environment setting program 221, a candidate extraction program 222, a productivity, convenience, and cost calculation program 223, and a candidate display program 224. The processes executed by these programs will be described later in detail.

[0030] The requirement presentation program 212 includes a candidate selection program 225, an operation requirement estimation program 226, and a system requirement / operation rule requirement presentation program 227. Details of the processes executed by these programs will be described later.

[0031] Although FIG. 2 shows an example in which the system introduction support device 100 is configured as a single device, the system introduction support device 100 may be configured as a plurality of devices. For example, the storage 205 may be a database server that is a separate device from the device equipped with a CPU.

[0032] Next, an input screen 301 (301A, 301B) displayed on the terminal 102, for example, for inputting various information to be transmitted to the system introduction assistance device 100 and displaying information from the system introduction assistance device 100 will be described.

[0033] 3A is a diagram illustrating a first example of an input screen according to an embodiment. An input screen 301A in FIG. 3A is a display example when public transportation is selected as the purpose of the autonomous driving system.

[0034] The input screen 301A includes a target use selection area 302, a site information upload area 303, and a requirement setting area 304.

[0035] The target use selection area 302 is an area that accepts the selection of the use of the autonomous driving system 1 to be introduced from the system builder. The use may be selected, for example, from a drop-down list, or may be selected by freely written input. Here, the use may be any use for which the autonomous driving system 1 can be used, such as "public transportation" related to the passenger transport business or "highway logistics" related to the logistics business.

[0036] The site information upload area 303 is an area for accepting a designation for uploading road information (driving environment data: moving environment data) along which a moving object moves, and includes a file name acceptance area 303a and an upload button 303b. Here, the driving road information is information on roads, surrounding maps, topography, etc. within the target area (site) of the autonomous driving system 1.

[0037] The file name reception area 303a is an area for receiving a file name including road information from a system builder. The upload button 303b is a button for receiving an instruction to upload a file with the file name received in the file name reception area 303a to the system introduction support device 100. When the upload button 303b is pressed, the terminal 102 uploads the file with the file name received in the file name reception area 303a to the system introduction support device 100. Based on this, in the system introduction support device 100, the candidate presentation program 211 is started and executed by the CPU 201.

[0038] The requirement setting area 304 is an area where a requirement candidate graph (for example, requirement candidate graph 304a) is displayed, which displays selectable requirement candidates for the use selected in the target use selection area 302. Note that the requirement candidate graph is a graph created by the candidate presentation program 211 (strictly speaking, the CPU 201 that executes the candidate presentation program 211), and if the use is not selected in the target use selection area 302 and the driving road information is not uploaded, the process by the candidate presentation program 211 is not executed, and therefore the requirement candidate graph is not displayed in this area.

[0039] When the candidate presentation program 211 is started, as a result of processing by this program, a requirement candidate graph 304a showing the trade-off elements of safety, productivity, convenience, and cost is displayed in the requirement setting area 304, and a number of candidate areas 304c corresponding to the system requirement / operation rule requirement sets (candidate requirement sets) described below that are candidates for the selected application are displayed in the requirement candidate graph 304a.

[0040] The requirement candidate graph 304a is, for example, a two-dimensional map, and the vertical axis (first axis) indicates the balance of system requirements and operation rule requirements for realizing safety. The upward direction of the vertical axis represents requirements that ensure safety in terms of systems such as hardware and software when realizing the safety of the autonomous driving system 1, and the downward direction of the vertical axis represents requirements that ensure safety in terms of operations and rules rather than in terms of systems. For example, among the candidates for the system requirement and operation rule requirement set, a candidate that ensures safety by installing the maximum configuration of sensors in all autonomous vehicles and installing the maximum configuration of infrastructure such as signals and barriers is displayed at the top of the requirement candidate graph 304a. As a contrasting example, a candidate that ensures safety in terms of operations and rules such as ensuring speed limits and safety confirmation time by minimizing sensors and infrastructure for autonomous vehicles is displayed at the bottom of the requirement candidate graph 304a.

[0041] The horizontal axis (second axis) of the requirement candidate graph 304a indicates the level of productivity and / or convenience realized by the system requirement / operation rule requirement set. For example, when productivity and convenience are the target, the position on the horizontal axis can be determined according to the result of a predetermined calculation (multiplication, addition, or any other calculation) performed on each value, and when only one value of productivity or convenience is the target, the position on the horizontal axis can be determined according to that value. The right direction of the horizontal axis indicates that relatively high productivity and / or convenience is realized, and the left direction indicates that productivity and / or convenience is relatively low. For example, in a system requirement / operation rule requirement set that can efficiently ensure safety by installing sensors and infrastructure, high productivity and / or convenience can be ensured by smooth vehicle operation, so this candidate is displayed on the right side of the requirement candidate graph 304a. On the other hand, in the case of candidate sets of system requirements and operational rule requirements where there is little sensor infrastructure that can ensure safety and where operational rules such as speed limits and ensuring stopping time are the main focus, productivity and / or convenience are also limited, so these candidates are displayed on the left side of the requirements candidate graph 304a.

[0042] The background (plane of the graph) of the requirement candidate graph 304a is displayed in a manner that allows the cost of realizing (implementing) the system requirement and operation rule requirement set to be recognized. The manner in which the cost can be recognized may be a manner in which the area is divided and color-coded according to the cost, or a manner in which a heat map is used. The cost of realizing (implementing) the system requirement and operation rule requirement set may include the cost of sensors to be installed in the autonomous driving vehicle and the cost of infrastructure to be installed on roads, etc., mainly as a factor caused by the vertical axis. As the number and types of these sensors and infrastructure increase, the hardware and software and their development costs also increase, so the cost increases toward the upper side of the vertical axis, and the cost becomes relatively small toward the lower side. On the other hand, the cost may also increase on the horizontal axis due to operation costs to ensure higher productivity and / or convenience. For example, the cost may increase due to the cost of publicizing and educating about the operation rules to ensure productivity and / or convenience, and in some cases, the labor costs.

[0043] Furthermore, in the requirements candidate graph 304a, an optimum area 304b is displayed which indicates the optimum area on the vertical axis and horizontal axis of the set of system requirements and operational rule requirements generally used for this application, according to the application selected in the target application selection area 302. The balance of the system and operation for realizing safety on the vertical axis and the productivity and / or convenience level (importance) on the horizontal axis are not actually determined independently and freely, but rather optimum values ​​are assumed for each application, and therefore this optimum area 304b can be effectively used as a reference when determining the requirements for the autonomous driving system 1.

[0044] In this requirement candidate graph 304a, the system builder selects a candidate area 304c corresponding to a desired set of system requirements and operation rules from among a plurality of candidate areas 304c. When the system builder selects one of the candidate areas 304c, the system requirements and operation rules corresponding to the candidate area are displayed in detail, and processing is executed by the requirement presentation program 212 (more precisely, the CPU 201 executing the requirement presentation program 212), and an output screen 321 (see FIG. 3C) is displayed.

[0045] By checking the requirement candidate graph 304a in the requirement setting area 304 of the input screen 301A, the balance and trade-off relationship between the system requirements and the operation requirements in the multiple system requirement and operation rule requirement set candidates can be understood. For example, in the requirement candidate graph 304a, the relative position on the vertical axis (balance of the system and operation in realizing safety) and the horizontal axis (productivity and / or convenience) within the same use and the realistically selectable position (trade-off) can be easily understood from the position of the candidate area and the positional relationship on the optimal area 304b of the target use. For example, the cost required to secure a certain level of productivity and / or convenience can be easily understood, and the upper limit of productivity and / or convenience and system configuration can also be easily understood when costs are to be kept below a certain level.

[0046] 3B is a diagram illustrating a second example of an input screen according to an embodiment. An input screen 301B in FIG. 3B is a display example when expressway distribution is selected as the use of the automatic driving system. In FIG. 3B, the same parts as those in FIG. 3A are given the same reference numerals, and duplicated explanations are omitted.

[0047] In the target use selection area 302, "expressway logistics" is selected, a file name including driving route information corresponding to the use is accepted in the file name acceptance area 303a, and when the upload button 303b is pressed, the file with the file name accepted in the file name acceptance area 303a is uploaded to the system introduction support device 100, and in the system introduction support device 100, the candidate presentation program 211 is launched and executed by the CPU 201.

[0048] When the candidate presentation program 211 is started, as a result of processing by this program, a requirement candidate graph 314a corresponding to the application indicating safety, productivity, convenience, and cost is displayed in the requirement setting area 304, and a plurality of candidate areas 314c corresponding to the system requirement / operation rule requirement sets that are candidates for the selected application and a selected optimum area 314b are displayed in the requirement candidate graph 314a. This allows the system builder to refer to the requirement candidate graph 314a and select a desired candidate from among the candidates suitable for the application.

[0049] Next, the output screen 321 will be described.

[0050] Fig. 3C is a diagram for explaining an example of an output screen according to an embodiment. The output screen 321 in Fig. 3C is an example of an output screen displayed when one of the multiple candidate areas 304c (in this example, the lower left candidate area 304c) is selected on the input screen 301A shown in Fig. 3A when public transportation is selected as the purpose. Note that the same output screen is displayed when one of the multiple candidate areas 314c is selected on the input screen 301B when highway logistics is selected as the purpose.

[0051] As described above, the output screen 321 is displayed after the processing is executed by the requirement presentation program 212. The output screen 321 includes a selected balance display area 322, a system requirement display area 323, and an operational requirement display area 324.

[0052] A selected requirement graph 322a is displayed in the selected balance display area 322. The selected requirement graph 322a is a similar graph to the requirement candidate graph 304a, with only some differences, and includes an optimum area 322b corresponding to the optimum area 304b, and a selected area 322c corresponding to one candidate area 304c selected by the system builder from among the multiple candidate areas 304c. Note that in the example of FIG. 3C, an area corresponding to the unselected candidate area 304c from among the multiple candidate areas 304c is not displayed, but the area corresponding to the unselected candidate area 304c may be displayed in a manner that makes it distinguishable from the selected area (for example, by lightening the display color). In addition, when a selection instruction is given from the system builder for an unselected candidate area on the output screen 321, the selected candidate area may be displayed as a new selected area on the output screen 321.

[0053] Details of the system configuration data corresponding to the system requirements and operation rule requirement set selected by the system builder are displayed in the system requirement display area 323. The system configuration data is displayed based on the system configuration data 231 by the system requirement and operation rule requirement presentation program 227 as a result of processing by the requirement presentation program 212.

[0054] In the operational requirement display area 324, a list of operational requirements corresponding to the system requirement / operation rule requirement set selected by the system builder and a requirement presentation graph 324a showing values ​​corresponding to each operational requirement are displayed. The requirement presentation graph 324a is created based on the productivity, convenience, and cost calculation result 235 calculated and stored by the productivity, convenience, and cost calculation program 223 of the candidate presentation program 211 for each operational requirement. The requirement presentation graph 324a displays the range of values ​​of each operational requirement that can be taken in the system requirement / operation rule requirement set selected by the user. The requirement presentation graph 324a also includes one or more combination graphs 324b showing combinations of values ​​of each selectable requirement. In the example of FIG. 3C, the combination graph 324b showing combinations of values ​​of other applicable requirements corresponding to multiple values ​​of the applicable requirement 1 (number of vehicles) is displayed, but for example, a combination graph showing combinations of values ​​of other applicable requirements corresponding to multiple values ​​of the applicable requirement may be displayed for other applicable requirements selected by the system builder.

[0055] By checking the selected requirement graph 322a in the selected balance display area 322 on the output screen 321, the balance and trade-off relationship between the system requirements and the operational requirements in the system requirements and operational rule requirement set selected by the system builder can be understood. For example, in the selected requirement graph 322a, the relative position on the vertical axis (balance of the system and operation in realizing safety) and the horizontal axis (productivity and / or convenience) in the same application and the position (trade-off) that can be realistically selected can be easily understood from the position of the selection area 322c and the positional relationship on the optimal area 322b of the target application. For example, the cost required to secure a certain level of productivity and / or convenience can be easily understood, and the upper limit of productivity and / or convenience, system configuration, etc. can also be easily understood when costs are to be kept below a certain level.

[0056] Next, the system configuration data 231 will be described.

[0057] Fig. 4A is a diagram showing a first example of system configuration data according to an embodiment. Fig. 4B is a diagram showing a second example of system configuration data according to an embodiment. Fig. 4A and Fig. 4B are system configuration data of the autonomous driving system 1 assuming public transportation as an application, Fig. 4A shows a full set configuration 401 which is the maximum system configuration, and Fig. 4B shows a minimum configuration 402 which is the minimum system configuration.

[0058] In the full set configuration 401, the autonomous driving system is configured with a business system, a control center, an emergency notification button, an autonomous driving vehicle, infrastructure sensors, gates, traffic lights, and passengers. In the minimum configuration 402, the autonomous driving system is configured by removing the infrastructure side components, that is, infrastructure sensors, gates, and traffic lights, from the configuration of the full set configuration 401. Note that the system configuration data is not limited to the full set configuration and the minimum configuration, but may include data of an intermediate configuration between the full set configuration and the minimum configuration, and is also not limited to these relationships, and may be data of a configuration in which a sensor is replaced with another sensor, for example.

[0059] The system configuration data 231 is not limited to data in the form of a block diagram as shown in FIG. 4A and FIG. 4B, and may be data in another description format such as UML (Unified Modeling Language).

[0060] Next, the usage-based candidate correspondence table 232 will be described.

[0061] FIG. 5A is a diagram illustrating an example of a usage-based candidate correspondence table according to an embodiment.

[0062] The application-specific candidate correspondence table 232 is a table for managing candidate requirement sets (system requirement / operation rule requirement set: candidate requirement set) including the system configuration, safety level, and operational requirement set for each application, and stores an entry for each candidate requirement set. The entry of the application-specific candidate correspondence table 232 includes fields for candidate number 501, application 502, system configuration 503, system safety level 504, and operational requirement set 505.

[0063] The candidate number 501 stores the number (candidate number) of the candidate requirement set corresponding to the entry. The purpose 502 stores the category of the purpose of the autonomous driving system in the candidate requirement set corresponding to the entry. The purpose is the purpose that is expected to be selected and input in the target purpose selection area 302 (312) of the input screen 301 (301A, 301B). Specifically, the purposes include "public transportation" and "highway logistics".

[0064] System configuration 503 stores the name of system configuration data 231 corresponding to the system configuration in the candidate requirement set corresponding to the entry. For example, in the candidate requirement set of candidate number 1, whose use is public transportation, the name of the full set configuration shown in Fig. 4A is stored, in the candidate requirement set of candidate number 4, the name of the minimum configuration shown in Fig. 4B is stored, and in the candidate requirement sets corresponding to candidate numbers 2 and 3, the name of system configuration data that is intermediate between the full set configuration and the minimum configuration is stored. Also, in the candidate requirement sets of candidate numbers 5 to 7, whose use is highway logistics, the system configuration names (configurations 5 to 7) of the system configuration patterns that can be taken for this use are stored.

[0065] In the system safety level 504, the degree of safety (safety level) guaranteed by the system, not in terms of operation and rules, in the system configuration corresponding to the system configuration name in the system configuration 503 corresponding to the entry is stored. The safety level is, for example, in ten stages from 1 to 10, and the higher the value, the higher the safety guaranteed by the system. In the example of FIG. 5A, in the candidate requirement set of candidate number 1, the system configuration is the full set configuration shown in FIG. 4A, so the safety level is the maximum "10". On the other hand, in the candidate requirement set of candidate number 4, the system configuration is the minimum configuration shown in FIG. 4B, and safety needs to be largely borne in terms of operation and rules, so the system safety level is a small value of "2". The value of the safety level in the system safety level 504 corresponds to the position on the vertical axis of the candidate area 304c (314c) showing the candidate requirement set in the two-dimensional map of the requirement setting area 304 (314) on the input screen 301A (301B). For example, a candidate area corresponding to a candidate requirement set with a safety level of "10" is placed at the top of the two-dimensional map, and a candidate area corresponding to a candidate requirement set with a safety level of "1" is placed at the bottom. Note that the safety level may be an index such as the commonly used SIL (Safety Integrity Level).

[0066] The name (or ID) of one or more sets of operational requirements (operational requirement sets) in the candidate requirement set corresponding to the entry is stored in the operational requirement set 505. In this embodiment, the details of a specific operational requirement set corresponding to the name of the operational requirement set are registered in the operational requirement set details table 233.

[0067] The same operational requirement set may be used in the candidate requirement sets, in which case the same operational requirement set name may be set for multiple candidate requirement sets in the application-specific candidate correspondence table 232. The same system configuration may be used in multiple candidate requirement sets, in which case the same system configuration name may be set for multiple candidate requirement sets in the application-specific candidate correspondence table 232.

[0068] Next, the operation requirement set details table 233 will be described.

[0069] FIG. 5B is a diagram illustrating an example of an operational requirement set detail table according to an embodiment.

[0070] 5B is a table for managing details of operational requirement sets, and stores an entry for each operational requirement set. An entry in the operational requirement set details table 233 includes fields for a set number 511, a purpose 512, an operational requirement set 513, and a plurality of individual operational requirements (514 to 517, etc.: operational requirement information).

[0071] The number (set number) of the operational requirement set corresponding to the entry is stored in the set number 511. The purpose 512 stores the category of the purpose of the autonomous driving system in the candidate requirement set corresponding to the entry. Specifically, the purpose may be "public transportation", "highway logistics", etc.

[0072] The name of the operational requirement set corresponding to the entry is stored in the operational requirement set 513. The name of the operational requirement set corresponds to the name of the operational requirement set in the operational requirement set 505 of the application-specific candidate correspondence table 232.

[0073] The individual operational requirements store each operational requirement (individual operational requirement) included in the operational requirement set. The individual operational requirements include, for example, information on whether the individual operational requirement is mandatory (Must) or optional (Optional), as well as information on the values ​​that the individual operational requirements can take (for example, a range). Note that no information is set for fields of unrelated individual operational requirements in the operational requirement set corresponding to the entry. In the example of FIG. 5B, the individual operational requirements include operational requirement 1: number of vehicles 514, operational requirement 2: running speed 515, operational requirement 3: stopping time 516, and operational requirement 4: vehicle distance 517.

[0074] Operational requirement 1: Number of vehicles 514 stores information on requirements regarding the number of autonomous vehicles 120 (number of vehicles). Operational requirement 2: Travel speed 515 stores requirements regarding the travel speed of autonomous vehicles 120. Operational requirement 3: Stopping time 516 stores requirements regarding the stopping time of autonomous vehicles 120. Operational requirement 4: Inter-vehicle distance 517 stores the inter-vehicle distance (distance between moving objects) of autonomous vehicles 120.

[0075] For example, in the example of operational requirement set detail table 233 in Fig. 5B, the operational requirement set of set number 1, i.e., set A, has the requirement of number of vehicles 514 as mandatory, the number of vehicles is set to be in the range of 1 to 10, the requirement of running speed 515 as mandatory, and the running speed is set to be in the range of 30 to 60. Also, the operational requirement set of set number 4, i.e., set D, has the requirement of number of vehicles 514 as mandatory, the number of vehicles is set to be in the range of 1 to 5, the requirement of running speed 515 as mandatory, and the running speed is set to be in the range of 30 to 40, and the requirement of stop time 516 is optional, and the stop time is set to be in the range of 30 to 40.

[0076] Next, the KPI calculation method data 234 will be described.

[0077] FIG. 6 is a diagram illustrating an example of KPI calculation method data according to an embodiment.

[0078] The KPI calculation method data 234 is data showing the relationship between the cost, productivity and / or convenience, system configuration, and operation requirements of the autonomous driving system 1 that is being considered for introduction. Note that the KPI calculation method data is not limited to the form of a KPI tree, and may be in the form of a formula, a model, or the like.

[0079] 6 is a KPI tree composed of multiple nodes (shown as ellipses in the figure), including nodes indicating cost, productivity, and convenience at the top, nodes corresponding to elements (safety equipment) and individual operation requirements set based on the system configuration at lower levels, and nodes indicating various indices located between them, and the relationships between the nodes are expressed by lines connecting them. Here, in the KPI tree, when there is a positive causal relationship between the nodes, the cause side and the result side are expressed by connecting them with a solid line with an arrow, and when there is a negative causal relationship, the cause side and the result side are expressed by connecting them with a dashed line with an arrow.

[0080] Here, there is a positive causal relationship between the "safety equipment" node and the "implementation cost" node, which indicates that the more sensors, infrastructure, etc. in the system configuration, the higher the implementation cost. On the other hand, as the number of autonomous vehicles in operation increases, passenger waiting time decreases, so there is a negative causal relationship between the "number of operations" node and the "passenger waiting time" node.

[0081] In addition, there may be mutual dependencies between nodes. For example, the faster the traveling speed of an autonomous vehicle, the longer the stopping time allowed for the vehicle, and conversely, the longer the stopping time of the vehicle, the faster the traveling speed of the autonomous vehicle must be. Due to such a relationship, the "traveling speed" node and the "stopping time" node are connected to each other as being mutually positively causal. In such a case where there is a mutually positive causal relationship, the values ​​of each node are not independent, but have a certain relationship (constraint condition).

[0082] For the lower node, the safety equipment node, the node value is set based on the system configuration corresponding to the target candidate requirement set. For the lower node, the individual operational requirement node, the possible value is calculated and set based on the information stored in the individual operational requirements (514 to 517) of the operational requirement set details table 233 corresponding to the target candidate requirement set. In the example of FIG. 6, the "safety equipment" node is set with data on the presence or absence of safety equipment sensors, infrastructure, etc., based on the system configuration data 231 corresponding to the target candidate requirement set. On the other hand, for the nodes of "number of vehicles," "traveling speed," and "stop time" corresponding to the individual operational requirements, the range of values ​​obtained from the individual operational requirements (514 to 517) of the operational requirement set details table 233 is basically set. However, when there is a constraint between the nodes, a value satisfying the constraint is set for the individual applicable requirements.

[0083] The productivity, convenience, and cost calculation program 223 of the candidate presentation program 211 calculates productivity, convenience, and cost using information of the KPI calculation method data 234 and the uploaded driving environment data. Specifically, the productivity, convenience, and cost calculation program 223 inputs values ​​of lower nodes, calculates values ​​of intermediate nodes, and finally calculates values ​​of higher-level productivity, convenience, and cost nodes based on the system configuration corresponding to the system configuration name of the system configuration 503 of the application-specific candidate correspondence table 232 and information of the individual operational requirements (514 to 517) of the operational requirement set details table 233.

[0084] Here, the values ​​of each node of the KPI tree, such as productivity and convenience, depend on the driving environment of the automated driving system 1 to be introduced. For example, the transportation efficiency of passengers (or cargo) is affected by the length of the driving section, the number of lanes of the driving road, etc. Therefore, the productivity, convenience, and cost calculation program 223 performs simulation and model calculation based on the driving environment data in order to calculate each node of the KPI calculation method data 234. For example, a traffic simulation reflecting map information of the driving environment is performed, and the values ​​of the lower nodes of the KPI tree (such as the number of vehicles) are input as parameters, and the productivity (such as transportation efficiency) and convenience are obtained from the results of the simulation execution.

[0085] Next, the processing operation of the system introduction support device 100 will be described.

[0086] 7 is a flowchart of the candidate presentation process according to an embodiment. The candidate presentation process is executed by the candidate presentation program 211 (strictly speaking, by the CPU 201 executing the candidate presentation program 211).

[0087] In step S701, the purpose / driving environment setting program 221 reads driving environment data corresponding to a file name including information on the purpose selected in the target purpose selection area 302 (312) of the input screen 301A, 301B and driving road information selected (input) in the site information upload area 303 (313).

[0088] In step S702, based on the use information read in step S701, candidate extraction program 222 extracts a candidate requirement set from use-specific candidate correspondence table 232. Specifically, candidate extraction program 222 refers to use-specific candidate correspondence table 232, and extracts a candidate requirement set based on a record whose use in use 502 matches the use acquired in step S701.

[0089] For example, when "public transportation" is selected as the use as shown in FIG. 3A, the candidate extraction program 222 identifies records with candidate numbers 1 to 4 having "public transportation" as the use from the use-specific candidate correspondence table 232, and extracts information on the system configuration 503, the system safety level 504, and the operational requirement set 505 for each of the identified records. Furthermore, the candidate extraction program 222 acquires a system configuration corresponding to the name of the system configuration in the system configuration 503 from the system configuration data 231, and acquires an operational requirement set corresponding to the name of the operational requirement set in the operational requirement set 505 from the operational requirement set detail table 233 for each. For the latter, the candidate extraction program 222 acquires a set of application requirements of a record in which the use in the use 512 in the operational requirement set detail table 233 and the name of the operational requirement set in the operational requirement set 513 match. Here, the set of the value of the safety level 504, the system configuration acquired from the system configuration data 231, and the operational requirement set acquired from the operational requirement set detail table 233 corresponds to the candidate requirement set.

[0090] In step S703, the productivity, convenience, and cost calculation program 223 calculates productivity, convenience, and cost for each candidate requirement set extracted in step S702 based on the driving environment data read in step S701, using data such as the KPI tree, formulas, and models shown in the KPI calculation method data 234, and records the calculated results in the storage 205 as productivity, convenience, and cost calculation results 235.

[0091] For example, when the KPI calculation method data 234 is given in the form of a KPI tree shown in Fig. 6, the productivity, convenience, and cost calculation program 223 may calculate the productivity, convenience, and cost by means of, for example, simulation. In this case, the productivity, convenience, and cost calculation program 223 inputs the system configuration data 231 corresponding to the lower node and the data (values) of the individual operational requirements (514 to 517) of the operational requirement set details table 233 as input parameters in a simulator corresponding to the autonomous driving system 1 to be introduced, and executes a simulation to obtain the productivity, convenience, and cost corresponding to the upper node as output results. Note that, when the value of the operational requirement can have a range, the productivity, convenience, and cost calculation program 223 identifies combinations of the range of values ​​that each operational requirement can take, performs a simulation using each combination as an input parameter, and obtains the calculation results of the productivity, convenience, and cost for each combination. However, in the case of an operational requirement that is not independent, i.e., has constraints, such as the "driving speed" and "stopping time" in the KPI tree of FIG. 6, the productivity / convenience / cost calculation program 223 does not freely set input parameters within the range of values ​​that each applicable requirement can take, but uses a combination of values ​​determined according to the relationship between them (constraints) as input parameters.

[0092] In step S704, the candidate display program 224 displays a requirement candidate graph 304a (314a) in the requirement setting area 304 (314) of the input screen 301A (301B) for each candidate requirement set based on the productivity, convenience, and cost data calculated in step S703.

[0093] According to the candidate presentation process, when "public transportation" is selected as the use as shown in Fig. 3A, the candidate extraction program 222 extracts the requirement sets corresponding to the entries of candidate numbers 1 to 4 from the use-specific candidate correspondence table 232 as candidate requirement sets. Next, the productivity, convenience, and cost calculation program 223 calculates the productivity, convenience, and cost for these four candidate requirement sets, and records them in the productivity, convenience, and cost calculation result 235 in the storage 205. In this case, the candidate display program 224 draws a two-dimensional map of the requirement candidate graph 304a in the requirement setting area 304 of the selected input screen, and an optimal area 304b for the selected use.

[0094] On the two-dimensional map of requirement candidate graph 304a in requirement setting area 304, candidate display program 224 draws candidate area 304c for each of the four candidate requirement sets, with the vertical axis position corresponding to the value of system safety level 504 in use-specific candidate correspondence table 232 and the horizontal axis position corresponding to the calculation results of productivity and convenience in productivity, convenience, and cost calculation results 235.

[0095] Here, as shown in the operation requirement set details table 233, since each operation requirement has a range of possible values, the productivity and convenience values ​​may not be unique and may take a certain range. When taking a range in this way, the candidate display program 224 sets the width when drawing each candidate area 304c to a width corresponding to the range of productivity and convenience. On the other hand, since the vertical axis is uniquely determined by the value of the safety level 504 by the system, it is not necessary to give the vertical width when drawing, but in this embodiment, for ease of viewing, the candidate display program 224 draws the candidate areas with a certain vertical width.

[0096] Furthermore, the candidate display program 224 displays the background of the two-dimensional map in a different color according to the cost corresponding to each of the four candidate requirement sets, based on the cost calculation results in the productivity, convenience, and cost calculation results 235. As a form of displaying the costs, the cost calculation results of the four candidate requirement sets may be displayed as numerical values, etc. Through these processes, the candidate display program 224 displays four candidate areas 304c corresponding to each candidate requirement set in the requirement setting area 304 of the input screen 301A, as shown in FIG.

[0097] This allows the system builder, together with the business operator (customer) introducing the autonomous driving system 1, to compare the positions on the two-dimensional map of the candidate areas displayed on the input screens 301A and 301B and the associated costs, and then select an appropriate one from among those candidate areas. Since there is often a trade-off relationship between the target on the vertical axis, the target on the horizontal axis, and the cost, the system builder and the customer can easily and appropriately determine the position to be taken by the target autonomous driving system 1 by referring to information such as the relative positional relationship with the optimal area 304b for the same application.

[0098] 8 is a flowchart of a requirement presentation process according to an embodiment of the present invention. The requirement presentation process is executed by the requirement presentation program 212 (strictly speaking, by the CPU 201 executing the requirement presentation program 212).

[0099] In step S801, the candidate selection program 225 acquires information on the candidate requirement set (referred to as a target requirement set in the explanation of the requirements presentation process) selected by the user in the requirement setting area 304 of the input screen (301A, 301B). The information on the target requirement set here includes the system configuration for the target requirement set (corresponding data in the system configuration data 231) and the operational requirement set (corresponding operational requirement set in the operational requirement set details table 233).

[0100] In step S802, the operational requirements estimation program 226 obtains the range of possible values ​​for each operational requirement corresponding to the operational requirements set obtained in step S801 from the productivity, convenience, and cost calculation results 235 recorded in the storage 205.

[0101] In step S803, the system requirement / operation rule requirement presentation program 227 displays the selected balance display area 322, the system requirement display area 323, and the operation requirement display area 324 on the output screen 321. In the system requirement display area 323, the system requirement / operation rule requirement presentation program 227 displays the system configuration corresponding to the system configuration data 231 acquired in step S801.

[0102] For example, when "public transportation" is selected as the use and the topmost candidate area 304c is selected in the requirement setting area 304 of the input screen 301A, that is, the candidate requirement set whose system configuration is a full set configuration, the system requirement display area 323 of the output screen 423 displays the public transportation full set configuration 401 shown in Figure 4A as the system configuration.

[0103] The operational requirement display area 324 displays a list of each operational requirement in the operational requirement set acquired in step S802, and information on the value (range) corresponding to each operational requirement. As a list of each operational requirement, individual operational requirements that are set as "Must" in the operational requirement set details table 233 in the target requirement set are displayed. The value ranges of these operational requirements are acquired from the productivity, convenience, and cost calculation results 235 calculated by a simulation or the like of the productivity, convenience, and cost calculation program 223, and are displayed, for example, as a graph or the like.

[0104] Here, since there may be a positive correlation or a negative correlation between each operational requirement, if there is a degree of freedom (range) in the value of each operational requirement, the combination of values ​​may be a trade-off. For example, a possible option is to increase the driving speed of the autonomous vehicle and extend the stopping time, or to decrease the driving speed and shorten the stopping time. In addition, a larger trade-off is the trade-off related to the selection of a candidate requirement set. For example, if a candidate requirement set with a lower cost and a smaller system configuration is selected in the requirement setting area 304, the operational requirement display area 324 will generally display more operational requirements with greater constraints as a result.

[0105] This allows system builders and businesses implementing the autonomous driving system 1 to easily and effectively make trade-off decisions by comprehensively looking at the safety, productivity, convenience, and cost in the selected balance display area 322 of the output screen 321 and the contents of the operational requirements display area 324.

[0106] The present invention is not limited to the above-described embodiment, and can be modified as appropriate without departing from the spirit of the present invention.

[0107] For example, in the above embodiment, the input of the intended purpose of the autonomous driving system is accepted from the user, but if the autonomous driving system is to be used only for a specific purpose determined in advance, the purpose may not be accepted and processing may be performed for that specific purpose. In this case, instead of a candidate correspondence table by purpose, a table for managing candidate requirement sets for only that specific purpose may be prepared.

[0108] In the above embodiment, the productivity, convenience, and cost are calculated using the KPI calculation method data 234 in the form of a KPI tree, but the method of calculating the productivity, convenience, and cost is not limited to this, and any method may be used. In addition, when the horizontal axis of the requirement candidate graph 304a is displayed for only one of productivity and convenience, it is sufficient to calculate the value of only the productivity or convenience that is displayed.

[0109] In the above embodiment, the driving environment data specified by the user is used, but the present invention is not limited to this. For example, the driving environment data prepared as a default may be used.

[0110] In addition, in the above embodiment, an autonomous driving system is used as an example of a system to be introduced. However, the system to be introduced is not limited to an autonomous driving system, and may be, for example, a mobile system that controls the operation of a mobile body that is not autonomous.

[0111] In the above embodiment, a part or all of the processing performed by the CPU 201 may be performed by a hardware circuit. The program in the above embodiment may be installed from a program source. The program source may be a program distribution server or a recording medium (e.g., a portable recording medium). [Explanation of symbols]

[0112] 1...Autonomous driving system, 10...System introduction support system, 100...System introduction support device, 110...Control center, 120...Autonomous driving vehicle, 201...CPU, 202...Communication interface, 203...Internal bus, 204...Memory, 205...Storage, 211...Candidate presentation program, 212...Requirements presentation program, 231...System configuration data, 232...Application-specific candidate correspondence table, 233...Operation requirements set details table, 234...KPI calculation method data, 301A, 302B...Input screen, 321...Output screen

Claims

1. A system introduction support device that supports selection of requirements when introducing a target system, A processor and a storage device, The storage device stores a plurality of candidate requirement sets for the introduction target system, the candidate requirement sets including system configuration information indicating a system configuration, a safety level in the system configuration, and operational requirement information including one or more operational requirements in the system configuration; The processor, Calculating the cost and the productivity and / or convenience for each of the candidate requirement sets; A system introduction support device that identifiably displays a combination of safety level, productivity and / or convenience, and cost in the system configuration, which are trade-off elements, for each of the candidate requirement sets.

2. In the system introduction support device according to claim 1, The processor, accepting a selection from a user of a candidate requirement set to be displayed in detail from among the plurality of candidate requirement sets; Displaying the system configuration information, a list of operational requirements included in the operational requirement information, and combinations of values ​​that each of the operational requirements can take, for the selected candidate requirement set. System implementation support device.

3. In the system introduction support device according to claim 1, The introduction target system is a mobile system that manages the movement of a predetermined mobile object, The processor, acquiring movement environment data regarding an environment in which the moving object moves; Calculating a cost, a productivity and / or a convenience for each of the candidate requirement sets based on the travel environment data. System implementation support device.

4. 4. The system introduction support device according to claim 3, The storage device stores a plurality of the candidate requirement sets for each use of the introduction target system; The processor, Accept the user's request for use, Calculating the cost, productivity and / or convenience for each of the candidate requirement sets corresponding to the specified use, and displaying in an identifiable manner a combination of the safety level, productivity and / or convenience, and cost in the system configuration, which are trade-off elements, for each of the candidate requirement sets. System implementation support device.

5. 2. The system introduction support device according to claim 1, The storage device is Store KPI calculation method data indicating a method for calculating the cost, productivity, and / or convenience of the introduction target system; The processor, Calculating the cost, productivity and / or convenience for each of the candidate requirement sets based on the KPI calculation method data System implementation support device.

6. 2. The system introduction support device according to claim 1, The processor displays a combination of the safety level, productivity and / or convenience, and cost in the system configuration, which are trade-off elements for each of the candidate requirement sets, in a graph in which a first axis represents the safety level, a second axis represents the productivity and / or convenience, and a background formed by the first axis and the second axis represents an area indicating cost. System implementation support device.

7. 2. The system introduction support device according to claim 1, The introduction target system is a mobile system that manages the movement of a predetermined mobile object, The one or more operational requirements include at least one of the number of the moving objects, the traveling speed of the moving objects, the stopping time of the moving objects, and the distance between the moving objects. System implementation support device.

8. 2. The system introduction support device according to claim 1, The system to be introduced is an automatic driving system that manages the automatic driving of a specified moving body, and is a system introduction support device.

9. A system introduction support method using a system introduction support device that supports selection of requirements when introducing a target system, comprising: The system introduction support device stores a plurality of candidate requirement sets for the introduction target system, the candidate requirement sets including system configuration information indicating a system configuration, a safety level in the system configuration, and operational requirement information including one or more operational requirements in the system configuration; The system introduction support device includes: Calculating the cost and the productivity and / or convenience for each of the candidate requirement sets; A system implementation support method for identifiably displaying a combination of safety level, productivity and / or convenience, and cost in the system configuration, which are trade-off elements, for each of the candidate requirement sets.

10. A system introduction support program executed by a computer constituting a system introduction support device that supports selection of requirements when introducing a target system, The computer stores a plurality of candidate requirement sets for the introduction target system, the candidate requirement sets including system configuration information indicating a system configuration, a safety level in the system configuration, and operational requirement information including one or more operational requirements in the system configuration; The system introduction support program includes: causing the computer to calculate costs, productivity and / or convenience for each of the candidate requirement sets; A system implementation support program that identifiably displays a combination of safety level, productivity and / or convenience, and cost in the system configuration, which are trade-off elements, for each of the candidate requirement sets.

Images