Dependency visualization apparatus and dependency visualization method

Abstract

To provide a dependence relation visualization device capable of grasping dependence relations of software.SOLUTION: A dependency relationship visualization device for visualizing a dependency relationship of software includes a narrowing-down unit that interacts with a user using knowledge information including information of an element related to the software, and gradually narrows down elements related to an update target from among the elements related to the software, and an output unit that outputs a dependency relationship of the software related to the update target based on the elements narrowed down by the narrowing-down unit.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to managing software. [Background technology]

[0002] If there is a defect in the software of an embedded system, such as an automobile, after the defect is fixed, the software is distributed only after checking whether the underlying software versions are met and whether the software combination has information that proves it has achieved performance that meets regulations. This type of dependency checking continues for all vehicle models and grades that are equipped with the defective software, and in some cases for individual vehicles, until it is confirmed that there are no problems.

[0003] As an example of how to deal with such dependency problems, a method has been proposed for detecting dependencies on the fly when a software update is performed (see Patent Document 1). This method performs a simulation, virtual installation, etc., and when the installation program is executed or copied, requests for repositories, system files, etc. are analyzed, the versions of dependent software used during the update are checked, and whether appropriate packages for the dependent software are available.

[0004] In addition, a software development deliverable dependency evaluation device has been proposed that evaluates the state of dependency between deliverables in software development (see Patent Document 2). The software development deliverable dependency evaluation device includes a means for specifying at least one key deliverable from among multiple deliverables involved in the upstream and downstream processes of software development, a means for acquiring correspondence information between multiple deliverables involved in the upstream and downstream processes of software development by referencing a deliverable correspondence table stored in a storage device, and a means for evaluating the complexity of the dependency relationships between the specified deliverable and multiple other deliverables in the upstream and downstream processes. This can be used to allocate software development work, etc. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Special Publication No. 2008-507775 [Patent Document 2] Japanese Patent Application Laid-Open No. 2013-15958 Summary of the Invention [Problem to be solved by the invention]

[0006] Embedded systems, such as those used in automobiles, are becoming increasingly demanding, with an increasing number of functions required, such as communication line connection functions, more advanced user interfaces, and autonomous driving functions, resulting in an increase in the size of the software.

[0007] On the other hand, the intervals between events that affect software development periods, such as model changes and minor changes, remain the same as before, and there are limitations on the time available for development, which means that defects can become apparent after shipping.In addition, the introduction of open source technologies, such as Linux (registered trademark), has begun, and there have been cases where security issues have arisen in introduced products.

[0008] Previously, problems like those described above were addressed by having the dealership update the software. However, in order to have the software updated at the dealership, the customer had to make a reservation with the dealer, arrange for the car to be brought in at a convenient time, and then have the software update carried out, which meant that it took time to update the software after a problem occurred. To solve this problem, software updates using OTA (Over The Air) technology have been introduced and are becoming increasingly popular.

[0009] On the other hand, when updating vehicle software, it is necessary to ensure that the software complies with domestic and international automobile regulations. This requires judgment based on a combination of various knowledge, such as knowledge of regulations (for example, safety standards for road transport vehicles), knowledge of vehicle configuration, knowledge of the systems that make up the vehicle, knowledge of system components, and knowledge of each hardware and software.

[0010] More specifically, when updating specific software, if there is software (collaborative software) that works in cooperation with the specific software to achieve the performance specified in motor vehicle regulations, the collaborating software must be updated at the same time as the specific software.

[0011] Comprehensively detecting software that has dependencies when updating software like the ones described above and distributing the software requires a group of experts with specialized knowledge of regulations, the vehicle as a whole, and systems and parts, to come together and make decisions, which is inefficient.

[0012] The present invention has been made in consideration of the above points, and aims to propose a dependency visualization device and the like that can grasp software dependency relationships. [Means for solving the problem]

[0013] In order to solve this problem, the present invention provides a dependency visualization device that visualizes software dependencies, and is provided with a narrowing-down unit that interacts with a user using knowledge information that includes information on elements related to the software, and gradually narrows down the elements related to the software to those that are to be updated, and an output unit that outputs the dependencies of the software related to the update target based on the elements narrowed down by the narrowing-down unit.

[0014] In the above configuration, the elements related to the update target are gradually narrowed down, so that, for example, a user can naturally interact with the dependency visualization device and easily understand the dependencies of the software related to the update target. [Effects of the Invention]

[0015] According to the present invention, it is possible to realize a highly convenient dependency visualization device. Problems, configurations, and effects other than those described above will become clear from the following description of the embodiments. [Brief explanation of the drawings]

[0016] [Figure 1] FIG. 1 is a diagram illustrating an example of a dependency visualization device according to a first embodiment. [Figure 2] FIG. 4 is a diagram illustrating an example of processing by a knowledge DB creating unit according to the first exemplary embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of a document structure extraction process according to the first embodiment. [Figure 4] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 5] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 6] FIG. 4 is a diagram illustrating an example of a data extraction process according to the first embodiment. [Figure 7] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 8] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 9] FIG. 4 is a diagram illustrating an example of processing by a control unit according to the first embodiment. [Figure 10] FIG. 2 is a diagram showing an example of a prompt collection DB according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of a general question process according to the first exemplary embodiment. [Figure 12] FIG. 2 is a diagram showing an example of an exchange between a user and the dependency visualization device according to the first embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of a common knowledge search process between departments according to the first embodiment. [Figure 14] FIG. 2 is a diagram showing an example of an exchange between a user and the dependency visualization device according to the first embodiment. [Figure 15] FIG. 10 is a diagram illustrating an example of an individual department knowledge search process according to the first exemplary embodiment. [Figure 16] FIG. 2 is a diagram showing an example of an exchange between a user and the dependency visualization device according to the first embodiment. [Figure 17] FIG. 2 is a diagram illustrating an example of visualization processing according to the first embodiment. [Figure 18] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 19] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 20] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 21] FIG. 2 is a diagram illustrating an example of a storage format according to the first embodiment. [Figure 22] FIG. 2 is a diagram illustrating an example of software dependency relationships according to the first embodiment. [Figure 23] FIG. 2 is a diagram illustrating an example of software dependency relationships according to the first embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0017] (I) First embodiment An embodiment of the present invention will be described in detail below, but the present invention is not limited to the embodiment.

[0018] This embodiment relates to configuration management during distribution of software components (software) of embedded systems, such as those in automobiles, and in particular to visualization of software dependencies.

[0019] The dependency visualization device according to this embodiment builds a business knowledge DB. For example, when design information is created that includes diagrams, the dependency visualization device uses generative artificial intelligence (AI) technology to convert the diagram information into text information, and then extracts titles, categories, dates and times, features, keywords, and the like from the text information to build a structured business knowledge DB and register system information. Furthermore, when building the business knowledge DB, the dependency visualization device registers knowledge commonly required by multiple business departments in an inter-departmental shared knowledge DB, and registers knowledge managed by individual departments in a business knowledge DB for a specific department. For example, the dependency visualization device registers information related to laws and regulations, as well as information about vehicles and the systems that make up the vehicles, in the inter-departmental shared knowledge DB, and registers design information for individual ECUs and the like in a department-specific knowledge DB for a specific department.

[0020] When updating software, the dependency visualization device uses the business knowledge DB, including public information, in stages to detect multiple pieces of software that have dependencies and extract the dependencies between the software. For example, when updating software in response to a specific legal amendment, the dependency visualization device detects information about the addition or amendment of the law from public information, detects systems related to the law (for example, systems that conflict), extracts software related to the detected systems, and detects software that has a calling relationship with the software to be updated.

[0021] According to this embodiment, it is possible to reduce the various tasks required to detect dependencies when updating software for a vehicle, which is expected to improve the efficiency of software distribution.

[0022] Next, an embodiment of the present invention will be described with reference to the drawings. The following description and drawings are examples for explaining the present invention, and some omissions and simplifications have been made as appropriate for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural.

[0023] In the following description, identical elements in the drawings are given the same numbers, and descriptions thereof will be omitted as appropriate. When describing elements of the same type without distinction, the common portion (the portion excluding the branch number) of the reference sign including the branch number may be used, and when describing elements of the same type while distinguishing between them, the reference sign including the branch number may be used. For example, when describing storage areas without any particular distinction between them, they may be written as "storage area 500," and when describing individual storage areas while distinguishing between them, they may be written as "storage area 500-1," "storage area 500-2," etc.

[0024] The designations "first," "second," "third," etc. in this specification are used to identify components and do not necessarily limit the number or order. Furthermore, numbers used to identify components are used in different contexts, and numbers used in one context do not necessarily indicate the same configuration in another context. Furthermore, this does not prevent a component identified by a certain number from also serving the function of a component identified by another number.

[0025] In FIG. 1, reference numeral 100 indicates the dependency visualization device according to the first embodiment as a whole.

[0026] 1 is a block diagram showing an example of a dependency visualization device 100 according to this embodiment. The dependency visualization device 100 includes a business knowledge extraction unit 120 that extracts business knowledge from an existing business system 110, a business knowledge DB 130 that stores the extracted business knowledge, and a dependency resolution unit 140 that uses the business knowledge DB 130 to resolve software dependency relationships while interacting with a user.

[0027] The existing business system 110 is composed of existing systems owned by automobile OEMs and the like. The existing business system 110 includes, for example, a regulations management system 111, a vehicle configuration management system 112, a design information management system 113, and a manufacturing information management system 114. The regulations management system 111 registers information on national automobile regulations and UN regulations, etc., and is used for searching and referencing. The vehicle configuration management system 112 manages the association of specifications, parts, software, and regulations information for various units, such as the automobile model, type, and VIN (Vehicle Identification Number). The design information management system 113 manages design-related information, such as design documents, CAD information, software repositories, and performance evaluation test results. The manufacturing information management system 114 manages manufacturing-related information, such as manufacturing schedule information, parts procurement information, and inventory management information, used in manufacturing.

[0028] The business knowledge extraction unit 120 receives user instructions from an input unit 147 (described later) and, under the control of the control unit 146, extracts document structures such as text sections, drawing sections, and tables from each system that constitutes the existing business system 110, converts each section into text, generates structured information from it, and stores it in the business knowledge DB 130.

[0029] The business knowledge DB 130 is composed of an inter-department shared knowledge DB 131 and a department-specific knowledge DB 132. The inter-department shared knowledge DB 131 stores business knowledge used across departments, such as vehicle specification information, component configuration information for systems consisting of multiple components, and linking information for laws and regulations related to the systems. The department-specific knowledge DB 132 stores detailed information managed specifically for each department, such as information on software included in components and information indicating software calling relationships.

[0030] The dependency resolution unit 140 is composed of a prompt collection DB 141, a general question unit 142, an inter-department common knowledge search unit 143, an individual department knowledge search unit 144, a visualization unit 145, a control unit 146, an input unit 147, an output unit 148, and a communication unit 149.

[0031] The prompt collection DB 141 stores query templates and question contents for users when searching. The general question unit 142 uses search sentences created by users using information from the prompt collection DB 141 to collect information from publicly available information while utilizing AI generation services on the Internet. The interdepartmental common knowledge search unit 143 uses search sentences created by users based on the information obtained by the general question unit 142 and the information from the prompt collection DB 141 to collect information across departments related to software dependencies from the interdepartmental shared knowledge DB 131 in the business knowledge DB 130. The individual department knowledge search unit 144 uses search information created by users based on the information obtained by the interdepartmental common knowledge search unit 143 and the information from the prompt collection DB 141 to collect department-specific information related to software dependencies from the department-specific knowledge DB 132 in the business knowledge DB 130. The visualization unit 145 visualizes the results based on the software dependency information obtained so far. The control unit 146 controls each function of the dependency resolution unit 140 based on user input. The input unit 147 receives user information and passes it to the control unit 146. The output unit 148 outputs the various pieces of information received from the control unit 146 to the user. The communication unit 149 communicates with various services and systems on the Internet based on the information received from the control unit 146.

[0032] In addition, the dependency visualization device 100 is an example of an information processing device (computer), such as a laptop computer or server device, and is configured to include a CPU (Central Processing Unit), RAM (Random Access Memory), ROM (Read Only Memory), HDD (Hard Disk Drive), communication device, etc., which are not shown in the figure.

[0033] The functions of the dependency visualization device 100 (such as the business knowledge extraction unit 120, the business knowledge DB 130, and the dependency resolution unit 140) may be realized, for example, by a CPU reading a program stored in a ROM into a RAM and executing it (software), or may be realized by hardware such as a dedicated circuit, or may be realized by a combination of software and hardware. The functions of the dependency visualization device 100 may be a virtual machine (VM) running on a computer, a container running on an operating system (OS), or an application running on an OS. Note that one function of the dependency visualization device 100 may be divided into multiple functions, or multiple functions may be combined into one function. Also, some of the functions of the dependency visualization device 100 may be provided as separate functions or may be included in other functions. Also, some of the functions of the dependency visualization device 100 may be realized by another computer capable of communicating with the dependency visualization device 100. Also, each hardware component of the dependency visualization device 100 may be one or more.

[0034] 2 is an example of a flowchart showing the processing of the knowledge DB creating unit 121. The operation based on the flowchart of FIG.

[0035] Step S201: This is the process in which the user starts using the knowledge DB creation function. Here, the target system and target document (document, software, file, etc.) are specified. After this process, the process of step S202 is performed.

[0036] Step S202: In the document structure extraction process, the knowledge DB creation unit 121 extracts figures and tables other than text from the specified document, creates explanatory text for the extracted figures and tables using a generation AI service, and converts the information of the target document into text and saves it. After this process, the process of step S203 is performed.

[0037] Step S203: In the data extraction process, the knowledge DB creation unit 121 extracts management information such as the title, creation date and time, and keywords, as well as summary information such as an overall summary and chapter summaries, from the document information converted to text in step S202, structures it into a format that can be saved in a database, and saves it in memory. After this process, the process of step S204 is performed.

[0038] Step S204: In the structured information registration process, the knowledge DB creation unit 121 stores the information that was structured in step S203 and stored in memory in the business knowledge DB 130 specified by the user. For example, the knowledge DB creation unit 121 registers information related to laws and regulations, and information related to vehicles and vehicle systems in the inter-department shared knowledge DB 131, and registers information related to the design of individual ECUs, etc. in the department-specific knowledge DB 132. After this process, the process of step S205 is performed.

[0039] Step S205: The knowledge DB creating unit 121 outputs the processing result to the output unit 148 via the control unit 146, and ends the knowledge DB creating process.

[0040] FIG. 3 is an example of a flowchart showing details of the document structure extraction process shown in step S202 of the flowchart in FIG.

[0041] Step S301: The knowledge DB creation unit 121 starts the document structure extraction process. Here, the target document (document, software, file, etc.) is specified. After the process, the process of step S302 is performed.

[0042] Step S302: The knowledge DB creation unit 121 reads the specified document at regular intervals and repeats the processing from step S303 onwards until it is completed. If the processing is still in progress (for example, if there are remaining pages), the knowledge DB creation unit 121 performs the processing of step S303, and if the processing is completed, it performs the processing of step S309.

[0043] Step S303: The knowledge DB creation unit 121 repeats the process sequentially from the beginning of the unit specified in step S302 to the end of the unit. The knowledge DB creation unit 121 determines whether the processing unit is halfway through or not, and if it is, returns to step S302, and if it is halfway through, performs the process of step S304.

[0044] Step S304: The knowledge DB creation unit 121 detects whether a figure or a table is present during processing. For example, if a file is written in a markup language and a figure or table tag (for example, in the case of HTML language, an HTML tag representing an image such as an img tag, or an HTML tag representing a table such as a table tag) appears, the corresponding processing is performed. If a figure is being processed, the processing of step S305 is performed, and if a table is being processed, the processing of step S307 is performed.

[0045] Step S305: The knowledge DB creation unit 121 uses a generation AI service on the Internet to explain the diagram detected in step S304. For example, using an API (Application Programming Interface) that can use the LLM (Large Language Models) of a specific generation AI service, or an API used in the LLM of a generation AI that you have built yourself, the knowledge DB creation unit 121 sends the image information acquired in step S304 to the LLM to be used and obtains the results of the explanation of the image information. After this processing, the processing of step S306 is performed.

[0046] Step S306: The knowledge DB creating unit 121 stores the file name and explanatory text of the diagram processed in step S305 in memory in association with the item number, and then returns to step S303.

[0047] Step S307: The knowledge DB creating unit 121 extracts the column name of the first row of the table information acquired in step S304, and creates a storage area (recording area) for each column in memory. After this process, the process of step S308 is performed.

[0048] Step S308: The knowledge DB creation unit 121 extracts the information from the second row onwards of the table acquired in step S304, row by row, breaks it down into columns, and stores each column in a storage area (recording area) in memory, and when complete, returns to step S303.

[0049] Step S309: After all figures and tables have been explained, the knowledge DB creating unit 121 rewrites the figures and tables in the specified document with explanatory text in memory. After this process, the process of step S310 is performed.

[0050] Step S310: The knowledge DB creating unit 121 ends the document structure extraction process.

[0051] FIG. 4 is a diagram showing an example of a storage format (storage area 400) when the description of the figure is stored in memory in step S306.

[0052] The storage area 400 consists of an item number area 401, a file name area 402, and an explanation area 403. Each time the knowledge DB creation unit 121 finishes processing an image file, it adds one line, increments the item number by one, records it in the item number area 401, records the file name of the image file in the file name area 402, and saves the explanation created by the generation AI in the explanation area 403.

[0053] FIG. 5 is a diagram showing an example of a storage format (storage area 500) when the tables described in steps S307 and S308 are stored in memory.

[0054] Storage area 500 is an area provided corresponding to the items in a table in a document. For example, in the case of storage area 500-1, an item number area 501, a specification name area 502, and a part name area 503 are provided corresponding to the items in the first row. Also, for example, in the case of storage area 500-2, an item number area 511, a model name area 512, a system name area 513, a function name area 514, a related law name area 515, and a remarks area 516 are provided corresponding to the items in the first row. Knowledge DB creation unit 121 records the area for the item in the first row of the table in the document in memory, and thereafter reads the contents described in the table and records them in the respective areas in memory in the same way.

[0055] FIG. 6 is an example of a flowchart showing details of the data extraction process shown in step S203 of the flowchart in FIG.

[0056] Step S601: The knowledge DB creation unit 121 starts data extraction processing. Here, the processing is started for the document information generated in step S202 of the flowchart in Fig. 2. At the start of processing, the knowledge DB creation unit 121 generates an item number from the last number in the item number field 701 in Fig. 7, records it in the item number field 701 shown in Fig. 7, which will be described later, and performs the processing of step S602.

[0057] Step S602: The knowledge DB creation unit 121 extracts the title from the document information. Possible methods for extracting the title include extracting the title portion from the format, extracting the title using meta information of a markup language (for example, in the case of HTML, extraction is performed using the title tag), and extracting the title using a generation AI service. After acquiring the title, the knowledge DB creation unit 121 records it in the title area 702 shown in FIG. 7, which will be described later, and performs the processing of step S603.

[0058] Step S603: The knowledge DB creation unit 121 extracts the creation date and time from the document information. Possible methods for extracting the creation date and time include extracting the creation date and time from the format, extracting the title using meta information in a markup language (for example, in the case of HTML, extraction using the time tag), or extracting the creation date and time using a generation AI service. After obtaining the creation date and time, the knowledge DB creation unit 121 records it in the creation date and time field 703 shown in Figure 7, which will be described later, and performs the processing of step S604.

[0059] Step S604: The knowledge DB creation unit 121 extracts keyword information from the document information. Here, the keyword extraction method may be a method of counting the number of occurrences of words and extracting the top N (N is an arbitrary number), or a method of inputting document information into a generation AI and extracting N keywords. After acquiring the keywords, the knowledge DB creation unit 121 records them in the keyword group area 704 shown in FIG. 7, which will be described later, and performs the processing of step S605.

[0060] Step S605: The knowledge DB creation unit 121 extracts a summary of the entire document from the document information. Here, the summary can be extracted by extracting parts such as the summary and abstract from the format, or by using a generation AI service. After obtaining the summary, the knowledge DB creation unit 121 records it in the overall summary area 705 shown in Figure 7, which will be described later, and performs the process of step S606.

[0061] Step S606: In order to extract information for each chapter, the knowledge DB creation unit 121 generates a chapter summary ID using any method (for example, it can be the same information as the item number) and records it in the chapter summary ID area 706 shown in Fig. 7, which will be described later. It also allocates a memory area for recording the title and summary for each chapter, as shown in Fig. 8, which will be described later, records the chapter summary ID in the ID area 801, and repeats the processing of step S607 as long as there is chapter information.

[0062] Here, the chapter information can be extracted from a format, extracted using meta information of a markup language (for example, in the case of HTML, extraction is performed using tags such as h1 to h6 that indicate heading elements), extracted using a generation AI service, etc. After extracting the chapter information, the knowledge DB creation unit 121 extracts the number of chapters, saves it as the remaining chapter number, and performs the process of step S607.

[0063] Step S607: The knowledge DB creation unit 121 extracts the chapter numbers, titles and summaries for each chapter in the same manner as in steps S602 and S605, records them in the chapter number area 802, chapter title area 803 and chapter summary area 804 in Figure 8 described below, decrements the remaining chapter numbers by "1", and performs the processing of step S608.

[0064] Step S608: The knowledge DB creating unit 121 determines whether or not there are any remaining chapter numbers (whether the number is 1 or more), and if there are any remaining chapter numbers, the process returns to step S607, and if there are no remaining chapter numbers, the process proceeds to step S609.

[0065] Step S609: The knowledge DB creating unit 121 completes writing of the information recorded in FIGS. 7 and 8, initializes the remaining chapter numbers to "0", and performs the process of step S610.

[0066] Step S610: The knowledge DB creating unit 121 completes the data extraction process and performs the structured information registration process (step S204).

[0067] FIG. 7 is a diagram showing an example of a storage format (storage area 700) when the contents extracted in the title extraction process in step S602, the creation date and time extraction process in step S603, the keyword extraction process in step S604, and the overall summary extraction process in step S605 of the flowchart in FIG. 6 are stored in memory.

[0068] Storage area 700 consists of an item number area 701, a title area 702, a creation date and time area 703, a keyword group area 704, an overall summary area 705, a chapter summary ID area 706, and a remarks area 707. The contents described in Fig. 6 are recorded in each of areas 701 to 706. The chapter summary ID has the same contents as the ID in area 801 of Fig. 8, which will be described later, and is used when referencing the contents of Fig. 8. Furthermore, remarks area 707 is an area for recording information other than that recorded in areas 702 to 706.

[0069] FIG. 8 is a diagram showing an example of a storage format (storage area 800) when the contents extracted in the chapter title and summary extraction process in step S607 of the flowchart in FIG. 6 are stored in memory.

[0070] The storage area 800 is made up of an ID area 801, a chapter number area 802, a chapter title area 803, and a chapter summary area 804. The contents described in FIG.

[0071] Fig. 9 is an example of a flowchart showing the processing of the control unit 146. The control unit 146 collects information stored in a prompt collection DB 141 such as that shown in Fig. 10 (described later) in conjunction with a general question unit 142, an inter-departmental common knowledge search unit 143, an individual department knowledge search unit 144, an input unit 147, an output unit 148, and a communication unit 149 to collect information on whether there is other software that has a dependency relationship with the software the user is updating, creates visualized information in a visualization unit 145, and presents it to the user via an output unit 148. The operation based on the flowchart in Fig. 9 is as follows.

[0072] Step S901: The control unit 146 starts the operation of the system, and then performs the process of step S902.

[0073] Step S902: The control unit 146 uses the general question unit 142 and a prompt related to the question type "general question" in the prompt collection DB 141 to collect information about the type of local regulations that the user wants to ask using the input unit 147 and the output unit 148, and obtains the information about the regulations necessary for the search, such as the item of the regulation, the name of the regulation, and the name of the target region, via the communication unit 149 using a generation AI application on the Internet, and then performs the processing of step S903.

[0074] Step S903: The control unit 146 uses the information on regulations acquired in step S902, information on the software to be updated acquired from the user, questions common to all departments in the prompt collection DB 141, the common knowledge search unit 143, and the inter-departmental shared knowledge DB 131 in the business knowledge DB 130 to collect information on the vehicle and system related to the software to be updated, and then performs processing in step S904.

[0075] Step S904: The control unit 146 uses the information on regulations acquired in step S902, information on the software to be updated acquired from the user, the vehicle and system information acquired in step S903, the individual department questions in the prompt collection DB 141, the individual department knowledge search unit 144, and the department-specific knowledge DB 132 in the business knowledge DB 130 to collect information on parts and software that have dependencies on the software to be updated, and then performs processing in step S905.

[0076] Step S905: The control unit 146 generates information necessary for visualization from the information relating to the software dependencies acquired in step S905, and displays it to the user using the output unit 148, and then performs the process of step S906.

[0077] Step S906: The control unit 146 ends the process.

[0078] FIG. 10 is a diagram showing an example (table 1000) of the prompt collection DB 141.

[0079] Table 1000 includes information on a question number 1001, a question type 1002, a category 1003, a region 1004, and a prompt example 1005. The question number 1001 is an item for managing prompts. The question type 1002 is an item for managing question types, such as general questions, questions related to multiple departments within a company, questions related to individual departments, or questions related to a combination thereof. The category 1003 is an item indicating the classification of questions, such as questions about laws and regulations, questions about vehicles, questions about systems that configure vehicles, questions about parts that configure vehicles, questions about software that configure vehicles, or questions related to a combination thereof. The region 1004 is an item for specifying the country that has enacted laws and regulations when asking a question, such as Japan, Europe, China, the United States, or other regions. The prompt example 1005 is an item indicating a template question for creating a prompt.

[0080] Figure 11 is an example of a flowchart showing the general question processing (step S902) of Figure 9. Based on the content of the question type 1002 in the example prompts shown in Figure 10 stored in the prompt collection DB 141, which is set to "general question," and on the prompt that the user has modified using the input unit 147 based on that content, the control unit 146 uses the general question unit 142 to collect information on laws and regulations required by the user and various publicly available information via the communication unit 149 using a generation AI service or the like provided as an Internet service. The operation based on the flowchart of Figure 11 is as follows.

[0081] Step S1101: The control unit 146 starts the process and performs the process of step S1102.

[0082] Step S1102: The control unit 146 uses the output unit 148 to output all or some of the combinations of classifications 1003 included in prompts whose question type 1002 is "general question" from the prompt collection DB 141 in a format like example 1201 in Figure 12, which will be described later, and performs the processing of step S1103.

[0083] Step S1103: The control unit 146 receives from the input unit 147 the result selected by the user from the output result of step S1102 and input in a format such as example 1202 in FIG. 12, which will be described later, and performs the process of step S1104.

[0084] Step S1104: Based on the results obtained in step S1103, the control unit 146 uses the output unit 148 to output all or part of the combinations of regions 1004 included in prompts whose question type 1002 is "general question" and whose classification 1003 matches the results obtained in step S1103 from the prompt collection DB 141, in a format like example 1203 in Figure 12 described below, and then performs processing in step S1105.

[0085] Step S1105: The control unit 146 receives from the input unit 147 the result selected by the user from the output result of step S1104 and input in a format such as example 1204 in FIG. 12, which will be described later, and performs the process of step S1106.

[0086] Step S1106: The control unit 146 acquires from the prompt collection DB 141 a prompt that corresponds to "general question" in the category and area acquired in steps S1103 and S1105, and performs the process of step S1107.

[0087] Step S1107: The control unit 146 outputs the prompt acquired in step S1106 using the output unit 148 in a format like an example 1205 in FIG. 12, which will be described later, and performs the process of step S1108.

[0088] Step S1108: The control unit 146 accepts the user's modification of the prompt. The user copies the prompt they want to use from the prompts output to the output unit 148, for example, from the prompts in example 1205 in Fig. 12 (described later), rewrites the contents of the (), requests the control unit 146 to process it, and performs the process of step S1109.

[0089] Step S1109: The control unit 146 uses the general question unit 142 and the API provided by the generation AI service on the Internet via the communication unit 149 to request processing of the prompt input in step S1108, and performs the processing of step S1110.

[0090] Step S1110: The control unit 146 acquires the return value of the process requested by the general inquiry unit 142 in step S1109 via the communication unit 149, and performs the process of step S1111.

[0091] Step S1111: The control unit 146 uses the output unit 148 to output the processing result acquired by the general question unit 142 in step S1110 in the format of example 1207 in FIG. 12, which will be described later, and performs the processing of step S1112.

[0092] Step S1112: The control unit 146 receives an instruction from the user using the input unit 147 and the output unit 148 as to whether to proceed to processing by the inter-departmental common knowledge search unit 143 or to continue asking questions. If the control unit 146 proceeds to processing by the inter-departmental common knowledge search unit 143, it performs the processing of step S1114, and if there are still questions, it performs the processing of step S1113.

[0093] Step S1113: Control unit 146 uses input unit 147 and output unit 148 to accept the user's selection of whether to ask a question using prompt collection DB 141 or to have the user input freely. If control unit 146 uses prompt collection DB 141, the process returns to step S1106; if control unit 146 has the user input freely, the process returns to step S1108.

[0094] Step S1114: The control unit 146 ends the general question process.

[0095] According to the general question processing, by using the prompt collection DB 141, it is possible to narrow down the laws and regulations related to recalls from the public information, or to narrow down the laws and regulations that have been added or amended.

[0096] FIG. 12 is a diagram showing an example of an exchange between the user and the dependency relationship visualization device 100 using the input unit 147 and the output unit 148 in the general question process (step S902) shown in FIG.

[0097] Example 1201 shows an example of presenting a classification to the user in step S1102 of FIG. 11. Example 1202 shows an example of receiving a classification from the user in step S1103. Example 1203 shows an example of presenting a region to the user in step S1104. Example 1204 shows an example of receiving a region from the user in step S1105. Example 1205 shows an example of presenting an example prompt to the user in step S1107. Example 1206 shows an example of modifying the prompt by the user in step S1108. Example 1207 shows an example of presenting an answer obtained from the generative AI service to the user in step S1111.

[0098] Figure 13 is an example of a flowchart showing the inter-departmental knowledge search process (step S903) of Figure 9. The control unit 146 uses vector search technology or the like to target the inter-departmental knowledge search unit 143 and collects information about the vehicle and system required by the user from information stored in the inter-departmental shared knowledge DB 131 of the business knowledge DB 130, based on information about the software the user wants to update, information about laws and regulations acquired by the user in the general question process (step S902), prompts shown in Figure 10 stored in the prompt collection DB 141 that have question type 1002 common to all departments, and prompts modified by the user using the input unit 147. The operation based on the flowchart of Figure 13 is as follows.

[0099] Step S1301: The control unit 146 starts the process and performs the process of step S1302.

[0100] Step S1302: The control unit 146 uses the output unit 148 to output all or some of the combinations of classifications 1003 included in prompts whose question type 1002 is "common across departments" from the prompt collection DB 141 in a format like example 1401 in Figure 14 (described later), and performs the processing of step S1303.

[0101] Step S1303: The control unit 146 receives from the input unit 147 the result selected by the user from the output result of step S1302 and input in a format such as example 1402 in FIG. 14, which will be described later, and performs the process of step S1304.

[0102] Step S1304: Based on the results obtained in step S1303, the control unit 146 uses the output unit 148 to output all or some of the combinations of regions 1004 included in prompts whose question type 1002 is "common across departments" and whose classification 1003 matches the results obtained in step S1303 from the prompt collection DB 141 in a format like example 1403 in Figure 14, which will be described later, and then performs processing in step S1305.

[0103] Step S1305: The control unit 146 receives from the input unit 147 the result selected by the user from the output result of step S1304 and input in a format such as example 1404 in FIG. 14, which will be described later, and performs the process of step S1306.

[0104] Step S1306: The control unit 146 acquires from the prompt collection DB 141 a prompt that corresponds to "common among departments" for the category and area acquired in steps S1303 and S1305, and performs the process of step S1307.

[0105] Step S1307: The control unit 146 outputs the prompt acquired in step S1306 using the output unit 148 in a format like an example 1405 in FIG. 14, which will be described later, and performs the process of step S1308.

[0106] Step S1308: The control unit 146 accepts the user's modification of the prompt. The user copies the prompt they want to use from among the prompts output to the output unit 148, for example, from example 1405 in Fig. 14 (described later), rewrites the contents of the (), requests the control unit 146 to process it, and performs the process of step S1309.

[0107] Step S1309: The control unit 146 uses the inter-departmental common knowledge search unit 143, and via the communication unit 149, an API provided by a generation AI service on the Internet, an API provided by a vector search application, etc., and uses the prompt entered in step S1308 to perform a knowledge search on the inter-departmental shared knowledge DB 131 of the business knowledge DB 130, and performs processing of step S1310.

[0108] For example, if the prompt is "Please extract a model that complies with the standard for automated driving devices (UN-R157)," the interdepartmental shared knowledge search unit 143 uses the contents (system configuration table) of the storage area 500-2 stored in the interdepartmental shared knowledge DB 131 to search for the model name "V001" that corresponds to the relevant legal name "UN-R157." At this time, multiple model names may be searched. Also, for example, if the prompt is "Please extract systems that violate the standard for automated driving devices (UN-R157) from among the systems that make up the model (V001)," the interdepartmental shared knowledge search unit 143 uses the system configuration table stored in the interdepartmental shared knowledge DB 131 to search for the system name "automated driving system" that corresponds to the model name "V001" and the relevant legal name "UN-R157," and searches for the function names of functions included in the automated driving system, such as lane keeping function, reverse assist function, and pre-crash braking function. At this time, multiple system names may be searched.

[0109] Note that the knowledge search is not limited to the above. For example, the control unit 146 may be configured to refer to the information (the chapter on relevant laws and regulations in the system design document) in the interdepartmental shared knowledge DB 131 in which the contents of the storage areas 700 and 800 are stored, and search for the system name "Autonomous Driving System" that is associated with the relevant law name "UN-R157."

[0110] Step S1310: The control unit 146 acquires the return value of the process requested by the inter-departmental common knowledge search unit 143 in step S1309, and performs the process of step S1311.

[0111] Step S1311: The control unit 146 uses the output unit 148 to output the processing result acquired by the inter-departmental common knowledge search unit 143 in step S1310 in the format of example 1407 in FIG. 14, which will be described later, and performs the processing of step S1312.

[0112] Step S1312: The control unit 146 receives an instruction from the user using the input unit 147 and the output unit 148 as to whether to proceed to processing of the individual department knowledge search unit 144 or to continue asking questions. If the control unit 146 proceeds to processing of the individual department knowledge search unit 144, it performs the processing of step S1314, and if there are still questions, it performs the processing of step S1313.

[0113] Step S1313: Control unit 146 uses input unit 147 and output unit 148 to accept the user's selection of whether to ask a question using prompt collection DB 141 or to have the user input freely. If control unit 146 uses prompt collection DB 141, the process returns to step S1306; if control unit 146 has the user input freely, the process returns to step S1308.

[0114] Step S1314: The control unit 146 ends the inter-department common knowledge search process.

[0115] According to the cross-departmental knowledge search process, it is possible to narrow down vehicles (models) related to the relevant laws and regulations, or narrow down systems that conflict with the relevant laws and regulations from among the systems that make up a vehicle, by using the prompt collection DB 141. For example, when information on laws and regulations related to recalls or laws and regulations that have been added or amended is extracted, it is possible to easily narrow down common elements (vehicles, systems, etc.) between departments that have a dependency relationship with the relevant laws and regulations.

[0116] FIG. 14 is a diagram showing an example of an exchange between the user and the dependency relationship visualization device 100 using the input unit 147 and the output unit 148 in the inter-departmental common knowledge search process (step S903) shown in FIG.

[0117] Example 1401 shows an example of presenting a classification to the user in step S1302 of FIG. 13. Example 1402 shows an example of receiving a classification from the user in step S1303. Example 1403 shows an example of presenting a region to the user in step S1304. Example 1404 shows an example of receiving a region from the user in step S1305. Example 1405 shows an example of presenting an example of a prompt to the user in step S1307. Example 1406 shows an example of modifying the prompt by the user in step S1308. Example 1407 shows an example of presenting an answer obtained from the generation AI service or business knowledge DB 130 to the user in step S1311.

[0118] Figure 15 is an example of a flowchart showing the individual department knowledge search process (step S904) of Figure 9. The control unit 146 uses vector search technology or the like to collect information on parts and software required by the user from information stored in the department-specific knowledge DB 132 of the business knowledge DB 130, based on information on the software the user wants to update, information on laws and regulations acquired by the user in the general question unit 142, information on the vehicle and system acquired by the user in the inter-departmental common knowledge search unit 143, prompts shown in Figure 10 stored in the prompt collection DB 141 that have question type 1002 for individual departments, and prompts modified by the user using the input unit 147. The control unit 146 uses vector search technology or the like to collect information on parts and software required by the user from information stored in the department-specific knowledge DB 132 of the business knowledge DB 130. The operation based on the flowchart of Figure 15 is as follows.

[0119] Step S1501: The control unit 146 starts the process and performs the process of step S1502.

[0120] Step S1502: The control unit 146 uses the output unit 148 to output all or some of the combinations of classifications 1003 included in prompts whose question type 1002 is "individual department" from the prompt collection DB 141 in a format like example 1601 in Figure 16, which will be described later, and performs the processing of step S1503.

[0121] Step S1503: The control unit 146 receives from the input unit 147 the result selected by the user from the output result of step S1502 and input in a format such as example 1602 in FIG. 16, which will be described later, and performs the process of step S1504.

[0122] Step S1504: Based on the results obtained in step S1503, the control unit 146 uses the output unit 148 to output all or some of the combinations of regions 1004 included in prompts whose question type 1002 is "individual department" and whose classification 1003 matches the results obtained in step S1503 from the prompt collection DB 141 in a format like example 1603 in Figure 16 described below, and then performs processing in step S1505.

[0123] Step S1505: The control unit 146 receives from the input unit 147 the result selected by the user from the output result of step S1504 and input in a format such as example 1604 in FIG. 16, which will be described later, and performs the process of step S1506.

[0124] Step S1506: The control unit 146 acquires from the prompt collection DB 141 a prompt that corresponds to the "individual department" for the category and area acquired in steps S1503 and S1505, and performs the process of step S1507.

[0125] Step S1507: The control unit 146 outputs the prompt acquired in step S1506 using the output unit 148 in a format like an example 1605 in FIG. 16, which will be described later, and performs the process of step S1508.

[0126] Step S1508: The control unit 146 accepts the user's modification of the prompt. The user copies the prompt they want to use from the prompts output to the output unit 148, for example, from the prompts in example 1605 in Fig. 16 (described later), rewrites the contents of the (), requests the control unit 146 to process it, and performs the process of step S1509.

[0127] Step S1509: The control unit 146 uses the inter-departmental common knowledge search unit 143, and via the communication unit 149, an API provided by a generation AI service on the Internet, an API provided by a vector search application, etc., and uses the prompt entered in step S1508 to perform a knowledge search on the inter-departmental shared knowledge DB 131 in the business knowledge DB 130, and performs processing of step S1510.

[0128] Although not shown, similar to the contents of storage area 500-2, the contents extracted from vehicle configuration management system 112 (a parts composition table in which systems, parts, and software are associated with each other) are stored in department-specific knowledge DB 132 for each department. For example, if the prompt is "Please extract information about ECUs related to a system (autonomous driving system) from information about a department (department A)," inter-departmental common knowledge search unit 143 uses the contents of the parts composition table of department A stored in department-specific knowledge DB 132 to search for the part name "AD-ECU" that corresponds to the system name "autonomous driving system." At this time, multiple part names may be searched. Also, for example, if the prompt is "Please extract the software names contained in the ECU (AD-ECU) installed in the system (autonomous driving system) from the information of the department (department A)," the inter-departmental common knowledge search unit 143 will use the contents of the parts composition list of department A stored in the department-specific knowledge DB 132 to search for the software names "image recognition software, cruise control judgment software, accelerator control software, brake control software, meter display software" that correspond to the system name "autonomous driving system" and the part name "AD-ECU."

[0129] Although not shown in the figure, similar to the contents of storage area 500-2, the contents extracted from vehicle configuration management system 112 (contents of ALM (Application Lifecycle Management), SBOM (Software Bill Of Materials), etc.) are stored in department-specific knowledge DB 132 as a software management table (a table in which software call relationships are associated). For example, if the prompt reads, "Please check from ALM / SBOM whether there is a call relationship between the software to be updated (cruise control determination software) and other software (image recognition software, accelerator control software, brake control software, meter display software)," then inter-departmental common knowledge search unit 143 uses the contents of the software management table stored in department-specific knowledge DB 132 to search for another software name, "meter display software," that matches the software name, "cruise control determination software."

[0130] Note that the knowledge search is not limited to the above. For example, the control unit 146 may be configured to search for the part name "AD-ECU" corresponding to the system name "automated driving system" by using information (e.g., a diagram description) in the department-specific knowledge DB 132 in which the contents of the storage area 400 are stored. Also, for example, the control unit 146 may be configured to search for the software name "meter display software" of the software in a calling relationship by referring to the basic design or external design chapter of the software design document for the software to be updated (cruise control determination software) from the information in the department-specific knowledge DB 132 in which the contents of the storage areas 700 and 800 are stored.

[0131] Step S1510: The control unit 146 acquires the return value of the process requested by the inter-departmental common knowledge search unit 143 in step S1509, and performs the process of step S1511.

[0132] Step S1511: The control unit 146 uses the output unit 148 to output the processing result acquired by the inter-departmental common knowledge search unit 143 in step S1510 in the format of example 1607 in FIG. 16, which will be described later, and performs the processing of step S1512.

[0133] Step S1512: The control unit 146 receives a user instruction as to whether to proceed to processing by the visualization unit 145 or to continue asking questions, using the input unit 147 and the output unit 148. If the control unit 146 proceeds to processing by the visualization unit 145, it performs the processing of step S1514, and if there are still questions, it performs the processing of step S1513.

[0134] Step S1513: Control unit 146 uses input unit 147 and output unit 148 to receive a user selection of whether to ask a question using prompt collection DB 141 or to have the user input freely. If control unit 146 uses prompt collection DB 141, the process returns to step S1506; if control unit 146 has the user input freely, the process returns to step S1508.

[0135] Step S1514: The control unit 146 ends the individual department knowledge search process.

[0136] According to the individual department knowledge search process, it is possible to narrow down the parts (ECUs, etc.) related to the system and the software included in the parts from information about the system by using the prompt collection DB 141. For example, when information about laws and regulations related to recalls and laws and regulations that have been added or amended is extracted, it is possible to narrow down the vehicles and systems that have dependencies on the laws and regulations using the cross-department knowledge search process, and then narrow down the department-specific elements (parts, software, etc.) that have dependencies on the system using the individual department knowledge search process.

[0137] FIG. 16 is a diagram showing an example of an exchange between the user and the dependency relationship visualization device 100 using the input unit 147 and the output unit 148 in the individual department knowledge search process (step S904) shown in FIG.

[0138] Example 1601 shows an example of presenting a classification to the user in step S1502 of FIG. 15. Example 1602 shows an example of receiving a classification from the user in step S1503. Example 1603 shows an example of presenting a region to the user in step S1504. Example 1604 shows an example of receiving a region from the user in step S1505. Example 1605 shows an example of presenting an example of a prompt to the user in step S1507. Example 1606 shows an example of the user modifying the prompt in step S1508. Example 1607 shows an example of presenting an answer obtained from the generation AI service or business knowledge DB 130 to the user in step S1511.

[0139] Fig. 17 is an example of a flowchart showing the visualization process (step S905) of Fig. 9. The control unit 146 uses the visualization unit 145 to display dependencies related to the software update on the output unit 148 based on information about the software the user wants to update, information about laws and regulations acquired by the user in the general question unit 142, information about the vehicle and system acquired by the inter-departmental knowledge search unit 143, and information about the parts and software to be updated acquired in the individual department knowledge search unit 144. The operation based on the flowchart of Fig. 17 is as follows.

[0140] Step S1701: The control unit 146 allocates a vehicle name storage area shown in FIG. 18, a system name storage area shown in FIG. 19, a part name storage area shown in FIG. 20, and a software name storage area shown in FIG. 21, which will be described later, generates a drawing ID, stores the drawing ID in the drawing ID areas 1802, 1902, 2002, and 2102 of each area, starts processing, and performs the processing of step S1702.

[0141] Step S1702: The control unit 146 extracts the vehicle name from the inter-department shared knowledge DB 131 by character string search or the like from the information on the vehicle name (model name) obtained in the inter-department shared knowledge search process (step S903), and performs the process of step S1703.

[0142] Step S1703: The control unit 146 stores the vehicle name in the area 1803 shown in FIG. 18, and performs the process of step S1704.

[0143] Step S1704: The control unit 146 extracts the names of the systems included in the vehicle and the dependency information related to the current visualization of the dependency relationships from the information obtained in the inter-departmental common knowledge search process (step S903) by using a string search or the like, and performs the process of step S1705. For example, the control unit 146 obtains the names of the systems corresponding to the system names from the public information or the business knowledge DB 130, and extracts the systems searched in step S1309 as systems related to the current visualization of the dependency relationships.

[0144] Step S1705: The control unit 146 assigns a number to each system name, stores the system number in the area 1903, the system name in the area 1904, and the presence or absence of a dependency in the area 1905, and then performs the process of step S1706.

[0145] Step S1706: The control unit 146 extracts the names of the components that make up the system and the dependency information related to the current visualization of the dependency relationships from the information obtained in the individual department knowledge search process (step S904) by using a string search or the like, and performs the process of step S1707. For example, the control unit 146 obtains the names of components that correspond to the component names from the public information or the business knowledge DB 130, and extracts the components searched for in step S1509 as components related to the current visualization of the dependency relationships.

[0146] Step S1707: The control unit 146 assigns a number to each component name, stores the system number that includes the component in area 2003, the component number in area 2004, the component name in area 2005, and the presence or absence of a dependency in area 2006, and then performs the processing of step S1708.

[0147] Step S1708: The control unit 146 extracts the software name and dependency information related to the current visualization of dependency relationships from the information obtained in the individual department knowledge search process by using a string search or the like, and performs the process of step S1709. For example, the control unit 146 obtains the software name corresponding to the software name from the public information or the business knowledge DB 130, and extracts the software searched in step S1509 as software related to the current visualization of dependency relationships.

[0148] Step S1709: The control unit 146 assigns a number to each software name, stores the system number of the system containing the software in area 2103, the part number of the part on which the software is installed in area 2104, the name of the software in area 2106, and the presence or absence of a dependency in area 2107, and performs processing of step S1710.

[0149] Step S1710: The control unit 146 visualizes the memory structures of Figures 18, 19, 20, and 21 in order as a hierarchical structure as shown in Figure 22. Each element is described, and the elements marked with a circle in the dependency column are connected by a line to visualize them.

[0150] Step S1711: The control unit 146 determines whether or not to analyze other vehicles. If the control unit 146 determines to analyze other vehicles, the process returns to step S1702, and if the control unit 146 determines not to analyze other vehicles, the process proceeds to step S1712.

[0151] Step S1712: The control unit 146 ends the visualization process.

[0152] Fig. 18 shows an example of a storage format (storage area 1800) in which vehicle-related information is written in memory write step S1703 shown in Fig. 17. The storage area 1800 consists of an area 1801 for the drawing ID and an area 1803 for the vehicle name. The drawing ID generated in step S1701 is recorded in area 1802.

[0153] Fig. 19 shows an example of a storage format (storage area 1900) in which information about the system is written in memory write step S1705 shown in Fig. 17. The storage area 1900 consists of an area 1901 for a drawing ID, an area 1903 for a system number, an area 1904 for a system name, and an area 1905 indicating whether or not there is a dependency. The drawing ID generated in step S1701 is recorded in area 1902.

[0154] Fig. 20 shows an example of a storage format (storage area 2000) in which information about a part is written in memory write step S1707 shown in Fig. 17. The storage area 2000 consists of an area 2001 for a drawing ID, an area 2003 for a system number, an area 2004 for a part number, an area 2005 for a part name, and an area 2006 indicating whether or not there is a dependency. The drawing ID generated in step S1701 is recorded in area 2002.

[0155] Fig. 21 shows an example of a storage format (storage area 2100) in which information about software is written in memory write step S1709 shown in Fig. 17. The storage area 2100 consists of an area 2101 for a drawing ID, an area 2103 for a system number, an area 2104 for a part number, an area 2105 for a software ID, an area 2106 for a software name, and an area 2107 indicating dependencies. The drawing ID generated in step S1701 is recorded in area 2102.

[0156] FIG. 22 is an example (display example 2200) showing software dependencies output to the output unit 148 by the visualization process (step S905).

[0157] In the display example 2200, systems, parts, and software that have dependencies are displayed for each vehicle (model), and software dependencies are visualized.

[0158] 23 is an example (display example 2300) showing software dependencies output to the output unit 148 by the visualization process (step S905). In the case of display example 2300, for example, instead of step S1704, the control unit 146 extracts the name of the regulation applicable to the vehicle and dependency information related to the current visualization of the dependency from the information obtained in the general question process (step S902) by using a string search or the like. Then, instead of step S1705, the control unit 146 assigns a number to each regulation name, saves the regulation number, the regulation name, and whether or not there is a dependency, and performs the process of step S1706.

[0159] In display example 2300, for each vehicle (model), the legal requirements to which it applies, the components that make up the vehicle for each legal requirement, and the software underneath are displayed, visualizing software dependencies.

[0160] Here, the legal regulations are shown as United Nations regulations, "UN-R," but they can also be Japanese automobile-related laws or laws specific to each country, such as the EU, North America, or China. Also, not only those related to autonomous driving as shown in Figure 22, but also other parts and the software that make up the parts can be shown, as shown in Figure 23.

[0161] (II) Supplementary Note The above-described embodiment includes, for example, the following contents.

[0162] In the above embodiment, the present invention is described as being applied to a dependency visualization device, but the present invention is not limited to this and can be widely applied to various other systems, devices, methods, and programs.

[0163] One of the features of the present invention is the use of RAG (Retrieval-Augmented Generation). The use of the business knowledge DB 130 and the dependency resolver 140 are examples of RAG. The present invention can also be applied to industrial fields other than the automotive industry.

[0164] Furthermore, in the above-described embodiment, the dependency visualization device 100 narrows down the list of laws, regulations, vehicles, systems, parts, and the like. However, the present invention is not limited to this. For example, the list may be narrowed down based on the user's contract. For example, if an autonomous driving subscription contract is made to provide the latest functions, the dependency visualization device 100 may narrow down the list of users who have made the subscription for the current update.

[0165] In the above embodiment, the dependency visualization device 100 displays software dependencies in a hierarchical structure, but the present invention is not limited to this. For example, the dependency visualization device 100 may display software that is to be updated in a list.

[0166] In the above-described embodiments, some or all of the programs may be installed from a program source into a device such as a computer that realizes the dependency visualization device. The program source may be, for example, a program distribution server connected via a network or a computer-readable recording medium (e.g., a non-transitory recording medium). In the above description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0167] Furthermore, in the above-described embodiments, the configuration of each table is an example, and one table may be divided into two or more tables, or all or part of two or more tables may be one table.

[0168] In addition, in the above-described embodiment, for convenience of explanation, the information related to the dependency visualization device has been described using a table, but the data structure is not limited to a table. The information related to the dependency visualization device may be expressed using a data structure other than a table, such as XML (Extensible Markup Language), YAML (YAML Ain't a Markup Language), a hash table, a tree structure, or the like.

[0169] Furthermore, in the above-described embodiment, the screens shown and described are merely examples, and any design may be used as long as the information received is the same.

[0170] Furthermore, the screens shown and described in the above-described embodiment are merely examples, and any design may be used as long as the information presented is the same.

[0171] In the above-described embodiment, the output of information is not limited to display on a display screen, but may be audio output from a speaker, output to a file, printed on paper or the like by a printer, projected onto a screen or the like by a projector, or in other forms.

[0172] In addition, in the above description, information such as programs, tables, files, etc. that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.

[0173] The above-described embodiment has the following characteristic configurations, for example.

[0174] (1) A dependency visualization device (e.g., dependency visualization device 100) that visualizes software dependencies comprises a narrowing-down unit (e.g., dependency resolution unit 140, control unit 146) that interacts with a user using knowledge information (e.g., business knowledge DB 130) that includes information on software-related elements (e.g., laws and regulations, vehicles, systems, parts, software), and gradually narrows down the software-related elements to elements that are subject to update (e.g., recalls, legal amendments, etc.), and an output unit (e.g., dependency resolution unit 140, output unit 148) that outputs the dependencies of software related to the update target based on the elements narrowed down by the narrowing-down unit.

[0175] In the above configuration, the elements related to the update target are gradually narrowed down, so that, for example, a user can naturally interact with the dependency visualization device and easily understand the dependencies of the software related to the update target.

[0176] (2) The system includes an acquisition unit (e.g., business knowledge extraction unit 120, knowledge DB creation unit 121, step S202) that acquires descriptions of images contained in documents managed by an existing business system via a generation AI service, an extraction unit (e.g., business knowledge extraction unit 120, knowledge DB creation unit 121, step S203) that replaces the image of the document with the description acquired by the acquisition unit and extracts data on the creation date and time of the replaced document, the file name of the document, and keywords contained in the document, and a storage unit (e.g., business knowledge extraction unit 120, knowledge DB creation unit 121, step S204) that stores the data extracted by the extraction unit as knowledge information.

[0177] According to the above configuration, images included in existing documents are stored as explanatory text in knowledge information, so that existing documents can be effectively utilized, for example, in visualizing software dependencies using RAG.

[0178] (3) The narrowing down unit includes a first narrowing down unit (e.g., general question unit 142) that receives information on the update target and acquires information on laws and regulations related to the received update target from public information, a second narrowing down unit (e.g., inter-department common knowledge search unit 143) that identifies vehicles related to the laws and regulations acquired by the first narrowing down unit based on the knowledge information and dialogue with the user, and identifies systems that violate the laws and regulations from among the systems that make up the identified vehicles, and a third narrowing down unit (e.g., individual department knowledge search unit 144) that identifies components related to the systems identified by the second narrowing down unit and identifies software included in the identified components.

[0179] With the above configuration, for example, it is possible to identify the laws and regulations related to the update target, the vehicle related to the laws and regulations, the systems that constitute the vehicle that conflict with the laws and regulations, the parts related to the systems, and the software included in the parts. With the above configuration, for example, the user can associate the vehicle, the system, and the parts to understand the software dependencies.

[0180] (4) The output unit outputs a list of elements that are dependent on each other for the vehicle, system, part, and software identified by the narrowing down unit (see, for example, FIG. 22). Note that the output unit may output a list of elements that are dependent on each other for the vehicle, system, part, and software identified by the narrowing down unit.

[0181] In the above configuration, elements that have a dependency relationship are linked and output, so that, for example, a user can easily understand the dependency relationship of software.

[0182] (5) The system is provided with a memory unit (e.g., a prompt collection DB141, table 1000) that stores example prompts for identifying laws and regulations, example prompts for identifying models related to laws and regulations, example prompts for identifying systems that conflict with laws and regulations, example prompts for identifying components related to the system, and example prompts for identifying software included in the components.

[0183] In the above configuration, for example, example prompts are presented in a dialogue with the user, which reduces the work required for the user to create a prompt. Also, for example, using example prompts reduces the likelihood of the user providing an answer that is not intended by the user, allowing for efficient use of computer resources.

[0184] Furthermore, the above-described configurations may be modified, rearranged, combined, or omitted as appropriate within the scope of the present invention.

[0185] It should be understood that items included in a list in the format "at least one of A, B, and C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Similarly, items listed in the format "at least one of A, B, or C" can mean (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). [Explanation of symbols]

[0186] 100...dependency visualization device, 120...business knowledge extraction unit, 130...business knowledge DB, 140...dependency resolution unit.

Claims

1. A dependency visualization device that visualizes software dependency relationships, a narrowing-down unit that interacts with a user using knowledge information including information on elements related to the software, and narrows down elements related to the software to be updated in stages; an output unit that outputs dependencies of software related to the update target based on the elements narrowed down by the narrowing unit; A dependency visualization device comprising:

2. An acquisition unit that acquires, via a generation AI service, description text of an image included in a document managed by an existing business system; an extraction unit that replaces the image of the document with the explanatory text acquired by the acquisition unit, and extracts data on the creation date and time of the replaced document, the file name of the document, and keywords included in the document; a storage unit that stores the data extracted by the extraction unit as knowledge information; The dependency visualization device according to claim 1 , comprising:

3. The narrowing portion is a first narrowing-down unit that receives information on an object to be updated and acquires information on laws and regulations related to the received object to be updated from public information; a second narrowing-down unit that identifies vehicles related to the regulations acquired by the first narrowing-down unit based on the knowledge information and a dialogue with a user, and identifies systems that violate the regulations from among systems that constitute the identified vehicles; a third narrowing-down unit that identifies components related to the system identified by the second narrowing-down unit and identifies software included in the identified components; The dependency visualization device according to claim 1 .

4. the output unit outputs the vehicle, system, part, and software identified by the narrowing unit by connecting elements having a dependency relationship with each other. The dependency visualization device according to claim 3 .

5. a storage unit that stores an example of a prompt for identifying a law, an example of a prompt for identifying a model related to the law, an example of a prompt for identifying a system that conflicts with the law, an example of a prompt for identifying a component related to the system, and an example of a prompt for identifying software included in the component; The dependency visualization device according to claim 3 .

6. A dependency visualization method for visualizing software dependency relationships, comprising: a narrowing-down unit that interacts with a user using knowledge information including information on elements related to the software, and narrows down elements related to the software to be updated in stages; an output unit outputs dependencies of software related to the update target based on the elements narrowed down by the narrowing unit; Dependency visualization methods including:

Images