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

Abstract

The present invention makes it possible to easily and appropriately provide a user with selectable requirements for an introduction subject system. A system introduction support device (100) for supporting selection of requirements when an introduction subject system is introduced comprises a CPU (201) and a storage (205). The storage (205) is configured to store, for the introduction subject system, 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, productivity and / or convenience, and the safety level in the system configuration, as trade-off factors.

Description

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

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

[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 for such applications, it is necessary to comprehensively determine the benefits of autonomous driving over manned driving, taking into consideration aspects such as 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 these aspects.

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

[0004] In the case of autonomous driving systems, as mentioned above, PoC implementation is expected, and it is possible to make partial changes to the system based on the results of PoC before deciding on the final system. However, taking into consideration the cost and opportunity loss due to modification time, it is necessary 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 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, based on past cases, changes in requirements that may occur over time in the system being developed, and outputting a system configuration proposal that satisfies the requirements in accordance with the change scenario.

[0006] JP 2018-49361 A

[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 taking into account 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 the available costs, desired productivity, and ensuring safety and operation of the system. 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 view 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 system to be introduced.

[0011] In order to achieve the above object, one aspect of a system introduction support device 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, each of which includes system configuration information indicating the 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 the combination of the safety level, productivity, and / or convenience for the system configuration, which are trade-off elements, and cost for each of the candidate requirement sets.

[0012] According to the present invention, it is possible to easily and appropriately provide a user with selectable requirements for a target system.

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

[0014] The following description of the embodiments will be given with reference to the drawings. Note that the embodiments described below do not limit the scope of the invention as claimed, 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 indicate that the information does not depend on the data structure, the "AAA table" may be called "AAA information."

[0016] In the following description, processing may be described with a "program" as the operating entity. However, since a program is executed by a processor to perform a predetermined process using at least one of a storage unit and an interface unit as appropriate, the operating entity of the process may also be the processor (or a computer (device) having a processor, or a computer system). A program may be installed on a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable recording medium. In the following description, two or more programs may be realized as a single program, or one program may be realized as two or more programs. At least a portion 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 local area network (LAN), a wireless LAN, or a wide area network (WAN). The system introduction support device 100 performs processing to support the introduction of an autonomous driving system, which is an example of a target system to be introduced (e.g., supporting requirement selection). The terminal 102 is used by a system builder (also simply referred to as a user) of the autonomous driving system. The terminal 102 displays various information from the system introduction support device 100 and accepts various operational inputs from the system builder and notifies the system introduction support device 100. The system builder may also directly use the system introduction support device 100. In this case, the system introduction support system 10 does not need to include the terminal 102.

[0019] FIG. 1B is a diagram illustrating an example of the configuration of an autonomous driving system that is a target for consideration 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 the 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, the autonomous vehicle 120, a bus stop / parking area 150, etc. 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 operating status of the autonomous vehicle 120 and performs operation management.

[0021] The autonomous vehicle 120 travels on roads 160 in the target introduction area, patrolling 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 the 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) 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 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. Programs previously installed in the storage 205 are loaded into the memory 204 by the CPU 201, and the loaded programs are executed by the CPU 201.

[0028] The storage 205 is, for example, a hard disk or 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 requirements presentation program 212, system configuration data 231, a use-specific candidate correspondence table 232, an operational requirements 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 requirements 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. Details of the processes executed by these programs will be described later.

[0030] The requirements presentation program 212 includes a candidate selection program 225, an operational requirements estimation program 226, and a system requirements / operational rule requirements 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 use 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 application selection area 302 is an area where the system builder selects the application of the autonomous driving system 1 to be introduced. The application may be selected, for example, from a drop-down list, or may be selected by free-form input. The application may be any application for which the autonomous driving system 1 can be used, such as "public transportation" related to passenger transportation business or "highway logistics" related to logistics business.

[0036] The site information upload area 303 is an area that accepts a specification for uploading roadway information (driving environment data: travel environment data) along which a mobile object travels, and includes a file name acceptance area 303a and an upload button 303b. Here, the roadway information refers to information such as roads, surrounding maps, and topography in the target area (site) of the autonomous driving system 1.

[0037] The file name reception area 303a is an area where a file name including road information is received from the 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, the CPU 201 in the system introduction support device 100 starts and executes the candidate presentation program 211.

[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 application selected in the target application 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 no application is selected in the target application selection area 302 and no driving route information is uploaded, the candidate presentation program 211 will not execute processing, and therefore no requirement candidate graph will be displayed in this area.

[0039] When the candidate presentation program 211 is launched, 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 multiple 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 between system requirements and operational rule requirements for achieving safety. The upward direction of the vertical axis represents requirements that ensure safety from a system perspective, such as hardware and software, when achieving the safety of the autonomous driving system 1, while the downward direction of the vertical axis represents requirements that ensure safety not from a system perspective but from an operational perspective and operational rule perspective. For example, among the candidate sets of system requirements and operational rule requirements, a candidate that ensures safety by equipping all autonomous vehicles with the maximum number of sensors and installing the maximum number of infrastructure, such as traffic lights and barriers, is displayed at the top of the requirement candidate graph 304a. As a contrasting example, a candidate that ensures safety from an operational perspective and operational rule perspective, such as minimizing the number of sensors and infrastructure on autonomous vehicles and ensuring speed limits and safety confirmation time, 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 achieved by the system requirement and operational rule requirement set. For example, when productivity and convenience are the target, the position on the horizontal axis can be determined according to the results of a predetermined calculation (multiplication, addition, or any other calculation) performed on each value. When only one of productivity or convenience is the target, the position on the horizontal axis can be determined according to that value. The rightward direction on the horizontal axis indicates that relatively high productivity and / or convenience will be achieved, while the leftward direction indicates that productivity and / or convenience will be relatively low. For example, in a system requirement and operational rule requirement set that can efficiently ensure safety by installing sensors and infrastructure, high productivity and / or convenience can be achieved 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 that have few sensors and infrastructure that can ensure safety and are primarily based on operations and rules such as speed limits and ensuring stop times, productivity and / or convenience will also be limited, and therefore such candidates are displayed on the left side of the requirement candidate graph 304a.

[0042] The background (graph plane) of the requirements candidate graph 304a is displayed in a manner that allows the cost of realizing (implementing) the system requirements and operational rule requirement set to be recognized. The cost may be recognized by dividing and color-coding areas according to cost, or by using a heat map. The cost of realizing (implementing) the system requirements and operational rule requirement set may primarily include the cost of sensors to be installed in autonomous vehicles and infrastructure installed on roads, etc., as factors primarily attributed to the vertical axis. As the number and types of sensors and infrastructure increase, the costs of hardware, software, and their development also increase. Therefore, costs increase toward the top of the vertical axis and relatively decrease toward the bottom. On the other hand, costs may also increase along the horizontal axis due to operational costs to ensure higher productivity and / or convenience. For example, costs may increase due to the costs of informing and educating employees about operational rules to ensure productivity and / or convenience, and in some cases, personnel costs.

[0043] Furthermore, in the requirements candidate graph 304a, an optimum area 304b is displayed that indicates the optimum area on the vertical and horizontal axes for the set of system requirements and operational rule requirements that are generally used for the application selected in the target application selection area 302. The balance of the system and operations for achieving safety on the vertical axis and the level of productivity and / or convenience (importance) on the horizontal axis are not actually determined independently and freely, but rather optimal 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 requirements 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 by the requirements presentation program 212 (more precisely, the CPU 201 executing the requirements 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, it is possible to understand the balance and trade-off relationships between the system requirements and operational requirements among multiple candidate sets of system requirements and operational rule requirements. For example, in the requirement candidate graph 304a, the relative positioning on the vertical axis (balance of the system and operations in achieving safety) and the horizontal axis (productivity and / or convenience) within the same application, as well as the realistic positions (trade-offs) that can be selected, can be easily understood from the position of the candidate area and its positional relationship on the optimal area 304b for the target application. For example, it is possible to easily understand the costs required to ensure a certain level of productivity and / or convenience, and also to easily understand the upper limits of productivity and / or convenience, system configuration, etc., 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. Input screen 301B in FIG. 3B is a display example when expressway distribution is selected as the application of the automated driving system. In FIG. 3B, the same parts as those in FIG. 3A are denoted by the same reference numerals, and redundant explanations will be omitted.

[0047] In the target use selection area 302, highway logistics is selected, a file name including road 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 CPU 201 starts and executes the candidate presentation program 211.

[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 multiple candidate areas 314c corresponding to candidate sets of system requirements and operation rules for the selected application, as well as 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] 3C is a diagram illustrating 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 (the lower-left candidate area 304c in this example) is selected on the input screen 301A shown in FIG. 3A when public transportation is selected as the intended use. A similar output screen appears when one of the multiple candidate areas 314c is selected on the input screen 301B when highway logistics is selected as the intended use.

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

[0052] A selected requirement graph 322a is displayed in the selected balance display area 322. The selected requirement graph 322a is similar to the requirement candidate graph 304a, with only some differences. The selected requirement graph 322a includes an optimal area 322b corresponding to the optimal area 304b and a selected area 322c corresponding to one of the multiple candidate areas 304c selected by the system builder. Note that in the example of FIG. 3C , areas corresponding to unselected candidate areas 304c among the multiple candidate areas 304c are not displayed. However, areas corresponding to unselected candidate areas 304c may be displayed in a manner that makes them distinguishable from selected areas (e.g., by displaying them in a lighter color). Furthermore, when the system builder issues a selection instruction 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] The system requirement display area 323 displays details of the system configuration data corresponding to the system requirement and operation rule requirement set selected by the system builder. 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 requirements presentation program 212.

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

[0055] By checking the selected requirements graph 322a in the selected balance display area 322 on the output screen 321, the system builder can understand the balance and trade-off relationship between the system requirements and operational rule requirements in the set of system requirements and operational rule requirements selected. For example, in the selected requirements graph 322a, the relative positioning on the vertical axis (balance of the system and operations in achieving safety) and the horizontal axis (productivity and / or convenience) within the same application, as well as the realistically selectable positions (trade-offs), can be easily understood from the position of the selection area 322c and the positional relationship in the optimal area 322b for the target application. For example, the costs required to ensure a certain level of productivity and / or convenience can be easily understood, and the upper limits 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 for an autonomous driving system 1 when public transportation is assumed as an application, with Fig. 4A showing a full set configuration 401, which is the maximum system configuration, and Fig. 4B showing a minimum configuration 402, which is the minimum system configuration.

[0058] In the full set configuration 401, the autonomous driving system is composed of an operation 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 composed by removing the infrastructure side components, i.e., 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 not limited to these relationships, and may also 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 FIGS. 4A and 4B, but may be data in other description formats such as UML (Unified Modeling Language).

[0060] Next, the use-specific candidate correspondence table 232 will be described.

[0061] FIG. 5A is a diagram illustrating an example of a use-specific 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 sets: candidate requirement sets) 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 purpose may be "public transportation," "highway logistics," etc.

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

[0065] The system safety level 504 stores the degree of safety (safety level) ensured by the system, rather than by operations and rules, for the system configuration corresponding to the system configuration name in the system configuration 503 corresponding to the entry. The safety level is, for example, on a scale of 1 to 10, with higher values ​​indicating higher levels of safety ensured by the system. In the example of FIG. 5A , the candidate requirement set designated by candidate number 1 has the full system configuration shown in FIG. 4A , so the safety level is the maximum, “10.” On the other hand, the candidate requirement set designated by candidate number 4 has the minimum system configuration shown in FIG. 4B , and safety must be largely based on operations and rules, so the system safety level is a low value of “2.” The safety level value of the system safety level 504 corresponds to the position on the vertical axis of the candidate area 304c (314c) indicating 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 operational requirement set 505 stores the name (or ID) of one or more sets of operational requirements (operational requirement sets) in the candidate requirement set corresponding to the entry. In this embodiment, details of the specific operational requirement sets corresponding to the names of the operational requirement sets are registered in the operational requirement set details table 233.

[0067] The same operational requirement set may be used in multiple 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 also 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 operational requirement set detail 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 multiple individual operational requirements (514 to 517, etc.: operational requirement information).

[0071] The set number 511 stores the number (set number) of the operational requirement set corresponding to the entry. 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 requirement 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: driving speed 515, operational requirement 3: stopping time 516, and operational requirement 4: inter-vehicle distance 517.

[0074] Operational requirement 1: The number of vehicles 514 stores information on requirements regarding the number of autonomously driven vehicles 120 (number of vehicles). Operational requirement 2: The driving speed 515 stores requirements regarding the driving speed of the autonomously driven vehicles 120. Operational requirement 3: The stopping time 516 stores requirements regarding the stopping time of the autonomously driven vehicles 120. Operational requirement 4: The inter-vehicle distance 517 stores the inter-vehicle distance (distance between moving objects) of the autonomously driven 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 a mandatory requirement, with the number of vehicles set to be in the range of 1 to 10, the requirement of running speed 515 as a mandatory requirement, with the running speed 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 a mandatory requirement, with the number of vehicles set to be in the range of 1 to 5, the requirement of running speed 515 as a mandatory requirement, with the running speed set to be in the range of 30 to 40, and the requirement of stop time 516 as an optional requirement, with the stop time 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 that indicates the relationship between the cost, productivity and / or convenience, system configuration, and operational 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 mathematical 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 level, nodes corresponding to elements (safety equipment) and individual operational requirements set based on the system configuration at lower levels, and nodes indicating various indicators at intermediate levels connecting these, with the relationships between the nodes being expressed by lines connecting them. Here, in the KPI tree, if there is a positive causal relationship between the nodes, the cause side and the result side are represented by a solid line with an arrow, and if there is a negative causal relationship, they are represented by a dashed line with an arrow.

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

[0081] Furthermore, there may be mutual dependencies between nodes. For example, the faster the traveling speed of an autonomous vehicle, the longer the vehicle's permitted stopping time; conversely, the longer the vehicle's stopping time, the faster the autonomous vehicle's traveling speed must be. Due to this relationship, the "traveling speed" node and the "stopping time" node are connected as having a mutually positive causal relationship. When there is such a mutually positive causal relationship, the values ​​of each node are not independent, but have a certain relationship (constraint).

[0082] For the lower-level safety equipment node, the node value is set based on the system configuration corresponding to the target candidate requirement set. For the lower-level individual operational requirement nodes, possible values ​​are calculated and set based on the information stored in the individual operational requirements (514-517) in 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, and other equipment based on the system configuration data 231 corresponding to the target candidate requirement set. Meanwhile, for the "number of vehicles," "travel speed," and "stop time" nodes corresponding to the individual operational requirements, a range of values ​​obtained from the individual operational requirements (514-517) in the operational requirement set details table 233 is basically set. However, if there are constraints between nodes, values ​​that satisfy the constraints are 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 from the KPI calculation method data 234 and the uploaded driving environment data. Specifically, the productivity, convenience, and cost calculation program 223 inputs values ​​for lower-level nodes, calculates values ​​for intermediate nodes, and finally calculates values ​​for higher-level productivity, convenience, and cost nodes, based on the system configuration corresponding to the system configuration name in the system configuration 503 in the application-specific candidate correspondence table 232 and information on the individual operational requirements (514 to 517) in the operational requirement set details table 233.

[0084] Here, the values ​​of each node in 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 factors such as the length of the driving section and the number of lanes on the road. Therefore, the productivity, convenience, and cost calculation program 223 performs simulations and model calculations based on driving environment data to calculate each node in the KPI calculation method data 234. For example, a traffic simulation reflecting map information of the driving environment is performed, and values ​​of lower nodes in the KPI tree (such as the number of vehicles) are input as parameters, and productivity (such as transportation efficiency) and convenience are obtained from the simulation execution results.

[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 application information read in step S701, the candidate extraction program 222 extracts a candidate requirement set from the application-specific candidate correspondence table 232. Specifically, the candidate extraction program 222 references the application-specific candidate correspondence table 232 and extracts a candidate requirement set based on records whose application 502 matches the application 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 for the use "public transportation" 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 identified record. Furthermore, for each record, the candidate extraction program 222 obtains from the system configuration data 231 the system configuration corresponding to the name of the system configuration in the system configuration 503, and obtains from the operational requirement set detail table 233 the operational requirement set corresponding to the name of the operational requirement set in the operational requirement set 505. For the latter, the candidate extraction program 222 obtains the set of applicable requirements for records whose use in the use 512 in the operational requirement set detail table 233 matches the name of the operational requirement set in the operational requirement set 513. Here, the set of the value of the safety level 504, the system configuration obtained from the system configuration data 231, and the operational requirement set obtained from the operational requirement set detail table 233 corresponds to a candidate requirement set.

[0090] In step S703, the productivity / convenience / cost calculation program 223 calculates the 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 storage 205 as productivity / convenience / cost calculation results 235.

[0091] For example, when the KPI calculation method data 234 is provided in the form of a KPI tree shown in Figure 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) in the operational requirement set detail table 233 as input parameters in a simulator corresponding to the autonomous driving system 1 being considered for introduction, and executes a simulation to obtain the productivity, convenience, and cost corresponding to the upper node as output results. Note that when the values ​​of the operational requirements can have a range, the productivity, convenience, and cost calculation program 223 identifies combinations of the ranges of values ​​that each operational requirement can take, performs a simulation using each combination as input parameters, and obtains calculation results of the productivity, convenience, and cost for each combination. However, in the case of operational requirements that are not independent, i.e., that have constraints, such as "driving speed" and "stop time" in the KPI tree of Figure 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 rather uses a combination of values ​​determined in accordance with 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 Figure 3A, the candidate extraction program 222 extracts, as candidate requirement sets, the requirement sets corresponding to the entries with candidate numbers 1 to 4 from the use-specific candidate correspondence table 232. 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 results 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 the requirement candidate graph 304a in the requirement setting area 304, the candidate display program 224 draws, for each of the four candidate requirement sets, a candidate area 304c in which the position on the vertical axis corresponds to the value of the system safety level 504 in the application-specific candidate correspondence table 232, and the position on the horizontal axis corresponds to the value of the calculation results of productivity and convenience in the productivity, convenience, and cost calculation results 235.

[0095] As shown in the operational requirement set details table 233, each operational requirement has a range of possible values, and therefore the productivity and convenience values ​​may not be unique but may take on a certain range. When a range is taken in this way, the candidate display program 224 sets the width of each candidate area 304c when drawing it to correspond to the range of productivity and convenience. On the other hand, since the vertical axis is uniquely determined by the value of the system's safety level 504, there is no need to give it a vertical width when drawing it. However, 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 based on the cost calculation results for each of the four candidate requirement sets in the productivity, convenience, and cost calculation results 235. The cost calculation results for the four candidate requirement sets may also be displayed as numerical values. 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. 3 .

[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. Because there is often a trade-off between the target on the vertical axis, the target on the horizontal axis, and the cost, the system builder and customer can easily and appropriately determine the position that the target autonomous driving system 1 should take 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. 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 about the candidate requirement set (referred to as the 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 about 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 storage 205.

[0101] In step S803, the system requirement / operation rule requirement presentation program 227 displays the selected balance display area 322, system requirement display area 323, and operational 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, if "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 obtained in step S802, along with information on the value (range) corresponding to each operational requirement. The list of each operational requirement displays the individual operational requirements that are set as "Must" in the operational requirement set details table 233 for the target requirement set. The value ranges of these operational requirements are obtained 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.

[0104] Here, because there may be a positive or 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 result in a trade-off. For example, possible options include increasing the driving speed of the autonomous vehicle and lengthening the stopping time, or decreasing the driving speed and shortening the stopping time. A larger trade-off also occurs in 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 end up displaying a larger number of operational requirements with greater constraints.

[0105] This allows system builders and businesses introducing 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 appropriately without departing from the spirit of the present invention.

[0107] For example, in the above embodiment, the user is asked to input the intended use of the autonomous driving system. However, if the autonomous driving system is to be used only for a specific predetermined use, the system may be designed to process only that specific use without accepting the intended use. In this case, instead of a candidate-by-use correspondence table, a table for managing candidate requirement sets for only that specific use may be prepared.

[0108] In the above embodiment, 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 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 displayed one of productivity and convenience.

[0109] Furthermore, 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 was used as an example of a system to be introduced, but 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-described embodiment, some or all of the processing performed by the CPU 201 may be performed by a hardware circuit. The programs in the above-described 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).

[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...Operational requirement set details table, 234...KPI calculation method data, 301A, 302B...Input screen, 321...Output screen

Claims

1. A system introduction support device that supports the selection of requirements when introducing a target system, comprising 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, the processor calculates cost, productivity and / or convenience for each of the candidate requirement sets, and the system introduction support device 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.

2. A system introduction support device as described in claim 1, wherein the processor receives from a user a selection of a candidate requirement set to be displayed in detail from among the plurality of candidate requirement sets, and displays, for the selected candidate requirement set, the system configuration information, a list of operational requirements included in the operational requirement information, and combinations of possible values ​​for each of the operational requirements.

3. A system introduction support device as described in claim 1, wherein the target system for introduction is a mobile system that manages the movement of a specified mobile object, and the processor acquires mobile environment data about an environment in which the mobile object moves, and calculates cost, productivity and / or convenience for each of the candidate requirement sets based on the mobile environment data.

4. A system introduction support device as described in claim 3, wherein the storage device stores a plurality of candidate requirement sets for each use of the target system, and the processor accepts a use designation from a user, calculates cost, productivity and / or convenience for each of the plurality of candidate requirement sets corresponding to the designated use, and identifiably displays a combination of safety level, productivity and / or convenience, and cost in the system configuration, which are trade-off elements, for each candidate requirement set.

5. A system introduction support apparatus as described in claim 1, wherein the storage device stores KPI calculation method data indicating a method for calculating costs, productivity and / or convenience in the target system, and the processor calculates costs, productivity and / or convenience for each of the candidate requirement sets based on the KPI calculation method data.

6. A system introduction support device as described in claim 1, wherein the processor displays, for each of the candidate requirement sets, a combination of the trade-off elements of safety level, productivity and / or convenience, and cost in the system configuration, using a graph with safety level on a first axis, productivity and / or convenience on a second axis, and a background formed by the first axis and the second axis as an area indicating cost.

7. A system introduction support device as described in claim 1, wherein the system to be introduced is a mobile system that manages the movement of specified mobile objects, and the one or more operational requirements include at least one of the number of the mobile objects, the traveling speed of the mobile objects, the stopping time of the mobile objects, and the distance between the mobile objects.

8. A system introduction support device according to claim 1, wherein the system to be introduced is an autonomous driving system that manages the autonomous driving of a specified mobile object.

9. A system introduction support method using a system introduction support device that supports the selection of requirements when introducing a target system, wherein the system introduction support device stores, for the target system, a plurality of candidate requirement sets each 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, the system introduction support device 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.

10. A system introduction support program to be executed by a computer constituting a system introduction support device that supports the selection of requirements when introducing a target system, wherein the computer stores, for the target system, a plurality of candidate requirement sets each 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, the system introduction support program causes the computer to calculate cost, productivity, and / or convenience for each of the candidate requirement sets, and identifiably displays a combination of safety level, productivity and / or convenience, and cost for the system configuration, which are trade-off elements, for each of the candidate requirement sets.

Images