Dependence visualization device and dependency visualization method

Abstract

The invention provides a dependency relationship visualization device and a dependency relationship visualization method, which can grasp the dependency relationship of software and visualize the dependency relationship of the software, the dependency relationship visualization device is provided with a screening part which makes a conversation with a user by using knowledge information including information of elements related to the software, periodically screening elements related to the update object from the elements related to the software; and an output unit that outputs the dependency relationship of the software relating to the update target on the basis of the elements screened by the screening unit.

Description

Technical Field

[0001] This invention generally relates to software management. Background Technology

[0002] In cases where embedded systems, such as automobiles, have software defects, after the defects are corrected, the versions of the prerequisite software are identified, and the combination of software containing information that serves as evidence of achieving regulatory compliance is verified to ensure that the dependencies are met. The software is then distributed. This dependency verification continues until it can be confirmed, across all vehicle types and classes equipped with the defective software, and, where appropriate, on a vehicle-by-vehicle basis.

[0003] As an example of addressing such dependency issues, a method for detecting dependencies in an on-the-fly manner during software updates has been proposed (see Patent Document 1). In this method, during the execution or copying of the installer, requests to repositories, system files, etc., are analyzed, the versions of the dependent software used during the update are checked, and the availability of appropriate dependent software packages is verified.

[0004] Furthermore, a software development deliverable dependency evaluation device (see Patent Document 2) is proposed for evaluating the dependency relationship status between software development deliverables. The software development deliverable dependency evaluation device includes: means for designating at least one deliverable as a key deliverable from multiple deliverables related to upstream and downstream processes of software development; means for obtaining correspondence information between multiple deliverables related to upstream and downstream processes of software development by referring to a deliverable correspondence table stored in a storage device; and means for evaluating the complexity of the dependency relationship between the designated deliverable and other deliverables in upstream and downstream processes. This can be applied to tasks such as software development task sharing.

[0005] Patent Document 1: Japanese Patent Publication No. 2008-507775

[0006] Patent Document 2: Japanese Patent Application Publication No. 2013-15958 Summary of the Invention

[0007] Embedded systems, exemplified by automobiles, have seen an increase in software size due to the increased demands for communication line connectivity, sophisticated user interfaces, and autonomous driving capabilities.

[0008] On the other hand, the intervals between events that affect software development, such as type changes and minor modifications, remain largely unchanged, limiting development time and sometimes causing defects to become apparent after the product leaves the factory. Furthermore, the introduction of technologies like Linux (registered trademark) and OSS (Service-Oriented System) has begun, leading to security issues in the resulting products.

[0009] Previously, such defects were addressed through software updates at dealerships. However, getting a car into the dealership for a software update required scheduling an appointment, coordinating a time for the update, and thus wasting time after the problem occurred. To solve this problem, software updates using OTA (Over-The-Air) technology are being introduced and are becoming more widespread.

[0010] On the other hand, when updating automotive software, updates must be made in accordance with domestic and international automotive regulations. Therefore, this requires a combination of knowledge related to regulations (e.g., safety standards for road transport vehicles), vehicle configuration, the systems that make up the vehicle, system-related components, and various hardware and software components.

[0011] More specifically, when updating specific software, if there is software that works in coordination with the specific software and achieves the performance required by automotive regulations (coordinating software), the coordinating software must be updated simultaneously with the specific software.

[0012] In order to comprehensively detect software dependencies that exist during software updates as described above and to distribute the software, it is necessary to gather experts with expertise in regulations, vehicles as a whole, systems, and components to make judgments, which is inefficient.

[0013] This invention was made with the above considerations in mind, and proposes a dependency visualization device that can grasp the dependency relationships of software.

[0014] To address this issue, the present invention provides a dependency visualization device that visualizes software dependencies. The dependency visualization device comprises: a filtering unit that uses knowledge information containing information about software-related elements to engage in dialogue with a user and periodically filters elements related to the update object from the software-related elements; and an output unit that outputs the software dependencies related to the update object based on the elements filtered by the filtering unit.

[0015] In the above structure, elements related to the updated object are filtered in stages, so that, for example, users can easily communicate with the dependency visualization device and easily grasp the software dependencies related to the updated object.

[0016] According to the present invention, a highly convenient dependency visualization device can be realized. Other issues, configurations, and effects beyond those described above will become clear through the following description of embodiments. Attached Figure Description

[0017] Figure 1 This is a diagram illustrating an example of a dependency visualization device according to the first embodiment.

[0018] Figure 2 This diagram illustrates an example of the processing of the knowledge database generation unit in the first embodiment.

[0019] Figure 3 This is a diagram illustrating an example of the document construction and extraction processing of the first embodiment;

[0020] Figure 4 This is a diagram illustrating an example of the storage format of the first embodiment.

[0021] Figure 5 This is a diagram illustrating an example of the storage format of the first embodiment.

[0022] Figure 6 This is a diagram illustrating an example of data extraction processing in the first embodiment.

[0023] Figure 7 This is a diagram illustrating an example of the storage format of the first embodiment.

[0024] Figure 8 This is a diagram illustrating an example of the storage format of the first embodiment.

[0025] Figure 9 This diagram illustrates an example of the processing of the control unit in the first embodiment.

[0026] Figure 10 This is a diagram representing an example of the prompt set DB in the first embodiment.

[0027] Figure 11 This diagram illustrates an example of the general query processing in the first embodiment.

[0028] Figure 12 This is a diagram illustrating an example of the interaction between a user and a dependency visualization device according to the first embodiment.

[0029] Figure 13 This diagram illustrates an example of interdepartmental shared knowledge retrieval processing in the first embodiment.

[0030] Figure 14 This is a diagram illustrating an example of the interaction between a user and a dependency visualization device according to the first embodiment.

[0031] Figure 15 This diagram illustrates an example of the individual department knowledge retrieval process in the first embodiment.

[0032] Figure 16 This is a diagram illustrating an example of the interaction between a user and a dependency visualization device according to the first embodiment.

[0033] Figure 17 This is a diagram illustrating an example of the visualization process of the first embodiment.

[0034] Figure 18 This is a diagram illustrating an example of the storage format of the first embodiment.

[0035] Figure 19 This is a diagram illustrating an example of the storage format of the first embodiment.

[0036] Figure 20 This is a diagram illustrating an example of the storage format of the first embodiment.

[0037] Figure 21 This is a diagram illustrating an example of the storage format of the first embodiment.

[0038] Figure 22 This is a diagram illustrating an example of the software dependencies in the first implementation.

[0039] Figure 23 This is a diagram illustrating an example of the software dependencies in the first implementation. Detailed Implementation

[0040] (I) First Embodiment

[0041] The following describes one embodiment of the present invention in detail. However, the present invention is not limited to this embodiment.

[0042] This implementation relates to configuration management during the distribution of software components (software) in embedded systems, such as automobiles, and particularly to the visualization of software dependencies.

[0043] The dependency visualization device in this embodiment constructs a business knowledge database. For example, when design information is generated from a diagram, the dependency visualization device uses generative artificial intelligence (AI) technology to transform the diagram information into text information, and then extracts titles, categories, dates, times, features, keywords, etc., from the text information to construct a structured business knowledge database and register system information. Furthermore, when constructing the business knowledge database, the dependency visualization device registers knowledge commonly needed by multiple business departments in an inter-departmental shared knowledge database, and registers knowledge managed in each department in a specific department's business knowledge database. For example, the dependency visualization device registers regulatory information and information related to vehicles and the systems constituting the vehicles in the inter-departmental shared knowledge database, and registers individual ECU design information, etc., in a specific department's departmental-specific knowledge database.

[0044] When updating software, the dependency visualization device uses a business knowledge database in stages, including publicly available information, to detect the dependencies between multiple software programs and the dependencies between them. For example, in updating software accompanied by specific regulatory changes, the dependency visualization device detects dependencies through the following stages: detecting information on the addition or modification of regulations from publicly available information; detecting systems related to the regulations (e.g., conflicting systems); extracting software related to the detected systems; and detecting software that has a calling relationship with the software to be updated.

[0045] According to this embodiment, various tasks aimed at detecting dependencies during software updates for automobiles can be reduced. Therefore, improved efficiency in software distribution can be expected.

[0046] Next, embodiments of the present invention will be described based on the accompanying drawings. The following description and drawings are illustrative of the invention; for clarity, appropriate omissions and simplifications have been made. The present invention can also be implemented in various other ways. Unless otherwise specified, each component may be a single element or a plurality of elements.

[0047] Furthermore, in the following description, the same number will be used for the same element in the accompanying drawings, and descriptions will be omitted as appropriate. Additionally, when describing elements without distinguishing between them, the common part (excluding the branch number) of the reference symbol containing the branch number may be used; when describing elements with distinction, the reference symbol containing the branch number may be used. For example, when describing without specifically distinguishing between preservation areas, it may be referred to as "Preservation Area 500," while when describing different preservation areas, it may be referred to as "Preservation Area 500-1" or "Preservation Area 500-2."

[0048] The terms "first," "second," and "third" used in this specification are for the purpose of identifying constituent elements and do not necessarily limit the number or order. Furthermore, the numbering used to identify constituent elements is used in each context, and a number used in one context may not represent the same structure in other contexts. Additionally, this does not preclude a constituent element identified by a certain number from also having the function of a constituent element identified by other numbers.

[0049] exist Figure 1 In the text, 100 represents the dependency visualization device of the first embodiment.

[0050] Figure 1 This is a block diagram illustrating an example of the dependency visualization device 100 of this embodiment. The dependency visualization device 100 is configured to include: a business knowledge extraction unit 120 that extracts business knowledge from an existing business system 110; a business knowledge database 130 that stores the extracted business knowledge; and a dependency resolution unit 140 that uses the business knowledge database 130 to resolve software dependencies while interacting with the user.

[0051] The existing business system 110 consists of existing systems owned by automotive OEMs, etc. The existing business system 110 may include, for example, a regulatory management system 111, a vehicle configuration management system 112, a design information management system 113, and a manufacturing information management system 114. The regulatory management system 111 registers automotive regulations from various countries, including UN regulations, for retrieval and reference. The vehicle configuration management system 112 manages the association between various units such as vehicle type, model, and VIN (Vehicle Identification Number) and specifications, components, software, and regulatory information. 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 schedules, component procurement information, and inventory management information.

[0052] The business knowledge extraction unit 120 is configured to include a knowledge database generation unit 121. The knowledge database generation unit 121 receives instructions from the user from the input unit 147 (described later) and, under the control of the control unit 146, extracts document structures such as text, drawing, and table from each system constituting the existing business system 110, digitizes each part, thereby generating structured information, and stores it in the business knowledge database 130.

[0053] Business knowledge DB130 comprises inter-departmental shared knowledge DB131 and department-specific knowledge DB132. Inter-departmental shared knowledge DB131 stores cross-departmental business knowledge such as vehicle specifications, component configuration information for systems consisting of multiple parts, and regulatory information related to the system. Department-specific knowledge DB132 stores detailed information managed by each department, including information about the software contained in the components and information representing software calling relationships.

[0054] The dependency resolution unit 140 is configured to include a prompt set DB 141, a general questioning unit 142, an interdepartmental common knowledge retrieval unit 143, an individual departmental knowledge retrieval unit 144, a visualization unit 145, a control unit 146, an input unit 147, an output unit 148, and a communication unit 149.

[0055] The prompt set DB141 stores samples of user queries and query content. The general query unit 142 uses the user-generated query statement generated by the prompt set DB141, effectively utilizing generative AI services on the Internet while collecting information from publicly known information. The interdepartmental shared knowledge retrieval unit 143 uses the user-generated query statement based on information obtained from the general query unit 142 and the prompt set DB141 to collect cross-departmental information related to software dependencies from the interdepartmental shared knowledge DB131 of the business knowledge DB130. The individual departmental knowledge retrieval unit 144 uses the query information generated by the user based on information obtained from the interdepartmental shared knowledge retrieval unit 143 and the prompt set DB141 to collect departmental-specific information related to software dependencies from the departmental-specific knowledge DB132 of the business knowledge DB130. The visualization unit 145 visualizes the results based on the software dependency information obtained so far. The control unit 146 controls the functions of the dependency resolution unit 140 according to user input. Input unit 147 receives user information and passes it to control unit 146. Output unit 148 outputs various information received from control unit 146 to the user. Communication unit 149 interacts with various services and systems on the Internet based on the information received from control unit 146.

[0056] In addition, the dependency visualization device 100 is an example of an information processing device (computer), such as a notebook computer or server device, and is composed of a central processing unit (CPU), random access memory (RAM), read-only memory (ROM), hard disk drive (HDD), communication device, etc. (not shown).

[0057] The functions of the dependency visualization device 100 (business knowledge extraction unit 120, business knowledge database 130, dependency resolution unit 140, etc.) can be implemented, for example, by the CPU reading a program stored in ROM into RAM and executing it (software), or by dedicated circuitry or other hardware, or by a combination of software and hardware. The functions of the dependency visualization device 100 can be a VM (Virtual Machine) operating on a computer, a container operating on an OS (Operating System), or an application operating on an OS. Furthermore, one function of the dependency visualization device 100 can be divided into multiple functions, or multiple functions can be combined into one function. Additionally, a part of the functions of the dependency visualization device 100 can be set as other functions, or included in other functions. Furthermore, a part of the functions of the dependency visualization device 100 can also be implemented by other computers capable of communicating with the dependency visualization device 100. Finally, the hardware components of the dependency visualization device 100 can be one or multiple.

[0058] Figure 2 This is an example of a flowchart illustrating the processing of the knowledge database generation unit 121. Based on Figure 2 The actions in the flowchart are as follows.

[0059] Step S201: The user begins processing using the knowledge database generation function. Here, the system as the object and the document as the object (document, software, file, etc.) are specified. After processing, proceed to step S202.

[0060] Step S202: In the document construction and extraction process, the knowledge database generation unit 121 extracts diagrams and tables other than text from the specified document, generates explanatory text for the extracted diagrams and tables using the generation AI service, and textualizes and saves the information of the document as the object. After processing, the process in step S203 is performed.

[0061] Step S203: In the data extraction process, the knowledge database generation unit 121 extracts management information such as title, generation date and time, and keywords, as well as abstract information such as overall summary and summary of each chapter, from the textualized document information in step S202. This information is then structured into a form that can be stored in the database and stored in memory. After processing, step S204 is performed.

[0062] Step S204: In the structured information registration process, the knowledge database generation unit 121 stores the information structured and stored in memory in step S203 into the user-specified business knowledge database 130. For example, the knowledge database generation unit 121 registers information related to regulations and information related to vehicles and vehicle systems into the inter-departmental shared knowledge database 131, and registers information related to the design of individual ECUs into the departmental proprietary knowledge database 132. After processing, step S205 is performed.

[0063] Step S205: The knowledge database generation unit 121 outputs the processing result to the output unit 148 via the control unit 146, thus ending the knowledge database generation process.

[0064] Figure 3 It means Figure 2 The flowchart shown in step S202 is an example of a flowchart detailing the document construction and extraction process.

[0065] Step S301: The knowledge database generation unit 121 begins document construction and extraction processing. Here, the document (document, software, file, etc.) is specified as the object. After processing, step S302 is performed.

[0066] Step S302: The knowledge database generation unit 121 reads the specified document at certain intervals and repeats the processing from step S303 onwards until the end. If the knowledge database generation unit 121 is still in the middle of processing (for example, if there are remaining pages), it performs the processing of step S303; if the processing is finished, it performs the processing of step S309.

[0067] Step S303: The knowledge database generation unit 121 repeatedly processes the unit from the beginning to the end of the unit specified in step S302. The knowledge database generation unit 121 determines whether the end of the processing unit is intermediate. If it is the end, it returns to step S302; if it is intermediate, it proceeds to step S304.

[0068] Step S304: The knowledge database generation unit 121 detects whether there are any graphs or tables in the processing. For example, if the document is written in a markup language, and if there are tags for graphs or tables (e.g., in the case of HTML, HTML tags representing images such as the `img` tag, and HTML tags representing tables such as the `table` tag), the corresponding processing is performed. In the case of graph processing, step S305 is performed, and in the case of table processing, step S307 is performed.

[0069] Step S305: The knowledge database generation unit 121 describes the graph detected in step S304 using generative AI services on the Internet. For example, it sends the image information obtained in step S304 to the LLM (Large Language Models) that uses specific generative AI services, or the API used in its own generative AI LLM, to obtain the result of the image information description. After processing, it proceeds to step S306.

[0070] Step S306: The knowledge database generation unit 121 saves the file name and description of the diagram processed in step S305 in memory in association with the project number, and returns to step S303.

[0071] Step S307: The knowledge database generation unit 121 extracts the column names of the first row of the table information obtained in step S304, and generates a storage area (record area) on the memory for each column. After processing, the process in step S308 is performed.

[0072] Step S308: The knowledge DB generation unit 121 extracts the information from the second row onwards of the table obtained in step S304 by each row and decomposes it by each column, and saves it by each column into the storage area (record area) on the memory. If the task is completed, it returns to step S303.

[0073] Step S309: Since the descriptions of all diagrams and tables of the processed object have been completed, the knowledge database generation unit 121 rewrites the diagram and table portions of the specified document into description text in memory. After processing, proceed to step S310.

[0074] Step S310: Knowledge DB Generation Department 121 completes document construction and extraction processing.

[0075] Figure 4 This is an example of a storage format (storage area 400) when the description of the diagram described in step S306 is stored in memory.

[0076] The storage area 400 consists of an item number area 401, a file name area 402, and a description area 403. The knowledge database generation unit 121 adds a new line each time the image file processing is finished, incrementing the item number by 1 and recording it in the item number area 401. The file name of the image file is recorded in the file name area 402, and the description content generated by the AI ​​is stored in the description area 403.

[0077] Figure 5This is a diagram showing an example of the storage format (storage area 500) when the table recorded in steps S307 and S308 is stored in memory.

[0078] Storage area 500 is an area set up corresponding to the items in the table in the document. For example, in the case of storage area 500-1, the item number area 501, specification name area 502, and component name area 503 are set up corresponding to the items located in the first row. Additionally, for example, in the case of storage area 500-2, the item number area 511, type name area 512, system name area 513, function name area 514, associated regulation name area 515, and remarks area 516 are set up corresponding to the items located in the first row. The knowledge database generation unit 121 records the areas of the items in the first row of the table in the document into memory, and subsequently reads the contents recorded in the table and similarly records them into the respective areas of memory.

[0079] Figure 6 It means Figure 2 The flowchart shown in step S203 is an example of a flowchart detailing the data extraction and processing.

[0080] Step S601: The knowledge database generation unit 121 begins data extraction and processing. Here, we take... Figure 2 The document information generated in step S202 of the flowchart is used to begin object processing. The Knowledge Database Generation Unit 121, at the start of processing, based on... Figure 7 The project number is generated from the last digit of the project number range 701, and is recorded as described later. Figure 7 In the recorded project number area 701, the processing step S602 is performed.

[0081] Step S602: The Knowledge DB Generation Unit 121 extracts the title from the document information. Here, the title extraction method may include extracting the title portion from the format, extracting the title using metadata from markup languages ​​(e.g., using the title tag in the case of HTML), or using a title generation AI service. After obtaining the title, the Knowledge DB Generation Unit 121 records it as described later. Figure 7 In the title area 702 recorded in the document, the processing of step S603 is performed.

[0082] Step S603: The Knowledge DB Generation Unit 121 extracts the generation date and time from the document information. Here, the extraction method may include extracting the generation date and time from the format, extracting the title using metadata from markup languages ​​(e.g., using the time tag in the case of HTML), or using a generation AI service to extract the generation date and time. After obtaining the generation date and time, the Knowledge DB Generation Unit 121 records it as described later. Figure 7 In the date and time region 703 recorded in the document, the processing in step S604 is performed.

[0083] Step S604: The knowledge database generation unit 121 extracts keyword information from the document information. Here, the keyword extraction method can be either counting the occurrences of words and extracting the top N keywords (N is any number), or inputting document information into the generation AI and extracting N keywords. After obtaining the keywords, the knowledge database generation unit 121 records them as described later. Figure 7 In the keyword group region 704 recorded in the document, the processing in step S605 is performed.

[0084] Step S605: The Knowledge DB Generation Unit 121 extracts a summary of the entire document from the document information. Here, the summary extraction method may include extracting parts such as the summary or abstract from the format, or using a generation AI service for extraction. After obtaining the summary, the Knowledge DB Generation Unit 121 records it as described later. Figure 7 In the overall summary area 705 recorded in the document, the processing step S606 is performed.

[0085] Step S606: Knowledge DB Generation Unit 121 generates a chapter summary ID by any method (e.g., information with the same project number) to extract information for each chapter, and records it as described later. Figure 7 The chapter summary ID is located in area 706. Furthermore, ensure that, as described below... Figure 8 The storage area that records the title and summary of each chapter records the chapter summary ID in the ID area 801. As long as there is chapter information, the processing of step S607 is repeated.

[0086] Here, regarding chapter information, methods for extraction include extracting from the format, extracting chapters using metadata from markup languages ​​(e.g., in the case of HTML, using tags such as h1 to h6 to represent heading elements), and extraction methods using AI generation services. After extracting the chapter information, the Knowledge DB Generation Unit 121 extracts the number of chapters, saves it as the remaining chapter numbers, and proceeds to step S607.

[0087] Step S607: The Knowledge DB Generation Unit 121 extracts the chapter number, the title of each chapter, and a summary using the same method as in steps S602 and S605, and records them as described later. Figure 8 In the chapter numbering area 802, chapter title area 803, and chapter summary area 804, set the remaining chapter numbers to "-1" and proceed to step S608.

[0088] Step S608: The knowledge database generation unit 121 determines whether the remaining chapter numbers are remaining (whether they are 1 or more). If they are remaining, it returns to step S607. If they are not remaining, it proceeds to step S609.

[0089] Step S609: Knowledge DB generation unit 121 completed. Figure 7 and Figure 8 Write the information recorded in the middle, initialize the remaining chapter numbers to "0", and proceed to step S610.

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

[0091] Figure 7 It means that it will be Figure 6 The flowchart shows an example of the storage format (storage area 700) when the content extracted in steps S602 (title extraction processing), S603 (date and time extraction processing), S604 (keyword extraction processing), and S605 (overall summary extraction processing) is saved to the memory.

[0092] The storage area 700 consists of the following sections: Project Number Area 701, Title Area 702, Generation Date and Time Area 703, Keyword Group Area 704, Overall Summary Area 705, Chapter Summary ID Area 706, and Remarks Area 707. Records are stored in each of the areas 701 to 706. Figure 6 The content described herein. The chapter summary ID is the same as that described later. Figure 8 The content with the same ID in ID range 801 is referenced. Figure 8 This is used when recording content. Additionally, notes area 707 is used to record information other than that recorded in areas 702 to 706.

[0093] Figure 8 It means to Figure 6 The flowchart shows the title of each section of step S607 and an example of the storage format (storage area 800) when the content extracted by the summary extraction process is saved to the memory.

[0094] The storage area 800 consists of an ID area 801, a chapter number area 802, a chapter title area 803, and a chapter summary area 804. Records are stored in each of the areas 801 to 804. Figure 6 The content explained in the document.

[0095] Figure 9 This is an example of a flowchart illustrating the processing of the control unit 146. The control unit 146 stores information as described later. Figure 10 The information in the prompt set DB141, in collaboration with the general inquiry unit 142, the inter-departmental shared knowledge retrieval unit 143, the individual departmental knowledge retrieval unit 144, the input unit 147, the output unit 148, and the communication unit 149, collects information on whether there is other software that depends on the software updated by the user. Visualization information is generated by the visualization unit 145 and presented to the user via the output unit 148. Based on... Figure 9 The actions in the flowchart are as follows.

[0096] Step S901: The control unit 146 starts the operation of the system, and then proceeds to step S902.

[0097] Step S902: The control unit 146 uses the prompts related to the question type "general question" in the general question unit 142 and the prompt set DB141, uses the input unit 147 and the output unit 148 to collect the question related to the regulations that are intended for which region, and uses the communication unit 149 to obtain the required information about the regulations, such as the items of the regulations, the name of the regulations, and the regional name of the target area, by using a generation AI application on the Internet. Then, the processing in step S903 is performed.

[0098] Step S903: The control unit 146 uses the regulatory information obtained in step S902, the information related to the software to be updated obtained from the user, the interdepartmental joint questioning of the prompt set DB141, the interdepartmental joint knowledge retrieval unit 143, and the interdepartmental shared knowledge DB131 of the business knowledge DB130 to collect information related to the vehicle and system associated with the software to be updated, and then proceeds to the processing in step S904.

[0099] Step S904: The control unit 146 uses the regulatory information obtained in step S902, the information related to the software to be updated obtained from the user, the vehicle and system information obtained in step S903, the individual department questions in the prompt set DB141, the individual department knowledge retrieval unit 144, and the department-specific knowledge DB132 in the business knowledge DB130 to collect information related to the components and software that are dependent on the software to be updated, and then proceeds to the processing in step S905.

[0100] Step S905: The control unit 146 generates the information required for visualization based on the information related to the software dependency obtained in step S905, displays it to the user using the output unit 148, and then proceeds to the processing in step S906.

[0101] Step S906: Control unit 146 ends processing.

[0102] Figure 10 This is a diagram showing an example (Table 1000) of the prompt set DB141.

[0103] Table 1000 contains information including Question Number 1001, Question Type 1002, Category 1003, Region 1004, and Question Example 1005. Question Number 1001 is an item used to manage prompts. Question Type 1002 is an item managing question types such as general questions, questions related to multiple departments within a company, questions related to individual departments, or questions related to combinations thereof. Category 1003 is an item indicating the classification of questions such as those related to regulations, vehicles, systems constituting vehicles, components constituting vehicles, software constituting vehicles, or combinations thereof. Region 1004 is an item used to specify countries where regulations are formulated at the time of the question, such as Japan, Europe, China, the United States, and other regions. Question Example 1005 is an item indicating a sample question used to generate prompts.

[0104] Figure 11 It means Figure 9 An example of a flowchart for general question processing (step S902). The control unit 146, based on the information stored in the prompt set DB141, Figure 10 The example question 1002 shown is a general question, and the user provides a prompt based on this by using the input unit 147. Other methods include using the general question unit 142, and using the AI ​​generation service provided via the communication unit 149 as an internet service, to collect information related to regulations required by the user, as well as various publicly available information. Figure 11 The actions in the flowchart are as follows.

[0105] Step S1101: The control unit 146 starts processing and proceeds to step S1102.

[0106] Step S1102: Control unit 146 retrieves all or part of the combinations of categories 1003 contained in prompts with question type 1002 being "general question" from prompt set DB141, as described below. Figure 12 The output is used in the form of Example 1201, and the output is processed in step S1103.

[0107] Step S1103: The control unit 146 receives the user selection from the input unit 147 based on the output result of step S1102, and then... (The rest of the text is missing). Figure 12 The result of the input in the form of Example 1202 is processed in step S1104.

[0108] Step S1104: Based on the results obtained in step S1103, control unit 146 selects from prompt set DB141 all or part of the combinations of regions 1004 included in prompts with question type 1002 "general question" and classification 1003 suitable for the results obtained in step S1103, as described below. Figure 12 The output is used in the form of Example 1203, and the output is processed in step S1105.

[0109] Step S1105: The control unit 146 receives the user selection from the input unit 147 based on the output result of step S1104, and then... (The rest of the text is missing). Figure 12 The result of the input in the form of Example 1204 is processed in step S1106.

[0110] Step S1106: The control unit 146 obtains the categories and regions that meet the "general question" criteria obtained in steps S1103 and S1105 from the prompt set DB141, and performs the processing in step S1107.

[0111] Step S1107: Control unit 146 uses output unit 148, as described later. Figure 12 The prompt obtained in step S1106 is output in the form of Example 1205, and the processing in step S1108 is performed.

[0112] Step S1108: Control unit 146 accepts the user's correction of the prompt. The user copies the output to output unit 148, for example, as described later. Figure 12 The prompt to be used in Example 1205 is overridden internally, delegated to control unit 146 to perform processing, and the processing of step S1109 is executed.

[0113] Step S1109: The control unit 146 uses the general questioning unit 142, via the communication unit 149, to use the API provided by the AI ​​generation service on the Internet to delegate the processing of the prompt entered in step S1108, and performs the processing of step S1110.

[0114] Step S1110: The control unit 146 obtains the return value of the processing entrusted by the general inquiry unit 142 in step S1109 via the communication unit 149, and performs the processing in step S1111.

[0115] Step S1111: Control unit 146 uses output unit 148, as described later. Figure 12 The general questioning section 142 outputs the processing result obtained in step S1110 in the form of Example 1207, and performs the processing in step S1112.

[0116] Step S1112: The control unit 146 uses the input unit 147 and the output unit 148 to receive an instruction from the user whether to transfer the processing to the inter-departmental common knowledge retrieval unit 143 or continue the query. If the processing is transferred to the inter-departmental common knowledge retrieval unit 143, the control unit 146 performs the processing in step S1114; if the query still exists, the control unit 146 performs the processing in step S1113.

[0117] Step S1113: The control unit 146 uses the input unit 147 and the output unit 148 to accept the user's choice: whether to ask a question using the prompt set DB141 or to allow the user to input freely. If the prompt set DB141 is used, the control unit 146 returns to step S1106; if the user is allowed to input freely, it returns to step S1108.

[0118] Step S1114: Control unit 146 ends general inquiry processing.

[0119] Based on the general query processing, by using the prompt set DB141, it is possible to filter publicly available information for regulations related to the recall, or for regulations that have been added or modified.

[0120] Figure 12 It means in Figure 9 The diagram shows an example of the interaction between a user and the dependency visualization device 100 using the input unit 147 and the output unit 148 in the general query processing (step S902).

[0121] Example 1201 indicates that in Figure 11 Example 1202 shows an example of prompting the user with a category in step S1102. Example 1202 shows an example of receiving a category from the user in step S1103. Example 1203 shows an example of prompting the user with a region in step S1104. Example 1204 shows an example of receiving a region from the user in step S1105. Example 1205 shows an example of prompting the user with a suggestion in step S1107. Example 1206 shows an example of the user correcting the suggestion in step S1108. Example 1207 shows an example of prompting the user with the answer obtained from the generated AI service in step S1111.

[0122] Figure 13 It means Figure 9This is an example of a flowchart for interdepartmental shared knowledge retrieval processing (step S903). Control unit 146, based on information related to the software the user wants to update, information related to regulations obtained by the user in the general query processing (step S902), and information stored in the prompt set DB141... Figure 10 The prompt shown, type 1002, pertains to content shared between departments. Based on this, the user has modified the prompt using input unit 147. The interdepartmental shared knowledge retrieval unit 143, using vector retrieval techniques, collects vehicle and system-related information needed by the user from the information stored in interdepartmental shared knowledge DB131 within business knowledge DB130. Figure 13 The actions in the flowchart are as follows.

[0123] Step S1301: The control unit 146 begins processing and proceeds to step S1302.

[0124] Step S1302: Control unit 146 retrieves all or part of the combinations of categories 1003 contained in the prompt set DB141 where the prompt type 1002 is "inter-departmental common", as described below. Figure 14 The output is used in the form of Example 1401, and the output is processed in step S1303.

[0125] Step S1303: Based on the output result of step S1302, the control unit 146 receives the user selection from the input unit 147 and then... (The rest of the text is missing). Figure 14 The result of the input in the form of Example 1402 is processed in step S1304.

[0126] Step S1304: Based on the results obtained in step S1303, control unit 146 uses output unit 148 to communicate with the following... Figure 14 Example 1403, in the same form, outputs all or part of the combination of regions 1004 included in the prompt set DB141 with the question type 1002 as “interdepartmental common”, the category 1003 being suitable for the result obtained in step S1303, and performs the processing of step S1305.

[0127] Step S1305: Based on the output result of step S1304, the control unit 146 receives the user selection from the input unit 147 and then... (The rest of the text is missing). Figure 14 The result of the input in the form of Example 1404 is processed in step S1306.

[0128] Step S1306: Control unit 146 obtains the prompt corresponding to "inter-department common" in the category and area obtained in steps S1303 and S1305 from prompt set DB141, and performs the processing of step S1307.

[0129] Step S1307: The control unit 146 will transfer the information obtained in step S1306 as described later. Figure 14 The output is used in the form of Example 1405, and the output is processed in step S1308.

[0130] Step S1308: Control unit 146 accepts the user's correction of the prompt. For example, the user's correction of the prompt from output to output unit 148 (described later). Figure 14 Copy the prompt to be used from the prompt of Example 1405, rewrite the inside of (), delegate the processing to the control unit 146, and execute the processing of step S1309.

[0131] Step S1309: The control unit 146 uses the interdepartmental shared knowledge retrieval unit 143, via the communication unit 149, to use the API provided by the AI ​​generation service on the Internet, the API provided by the vector retrieval application, etc., and uses the prompts entered in step S1308 to perform knowledge retrieval on the interdepartmental shared knowledge DB131 of the business knowledge DB130, and performs the processing of step S1310.

[0132] For example, if the prompt is "We wish to extract the type that conforms to the baseline (UN-R157) for automated driving devices," the interdepartmental shared knowledge retrieval unit 143 uses the contents (system configuration table) of storage area 500-2 stored in the interdepartmental shared knowledge DB 131 to retrieve the type name "V001" that conforms to the associated regulatory name "UN-R157." In this case, multiple type names can be searched. Alternatively, if the prompt is "We wish to extract systems that conflict with the baseline (UN-R157) for automated driving devices from the systems constituting type (V001)," the interdepartmental shared knowledge retrieval unit 143 uses the system configuration table stored in the interdepartmental shared knowledge DB 131 to retrieve the system name "Automated Driving System" that conforms to both the type name "V001" and the associated regulatory name "UN-R157," and then retrieves the function names of the functions included in the automated driving system, such as "Lane Keeping Function," "Reversing Assist Function," and "Pre-Collision Braking Function." In this case, multiple system names may also be searched.

[0133] Furthermore, knowledge retrieval is not limited to the above. For example, the control unit 146 may also refer to the information in the inter-departmental shared knowledge DB131 (the relevant chapter of the system design document) which stores the contents of storage area 700 and storage area 800, and retrieve the structure corresponding to the system name "Autonomous Driving System" established with the relevant regulation name "UN-R157".

[0134] Step S1310: The control unit 146 obtains the return value of the processing entrusted by the inter-departmental common knowledge retrieval unit 143 in step S1309, and performs the processing in step S1311.

[0135] Step S1311: Control unit 146 uses output unit 148, as described later. Figure 14 The interdepartmental common knowledge retrieval unit 143 outputs the processing results obtained in step S1310 in the form of Example 1407, and performs the processing in step S1312.

[0136] Step S1312: The control unit 146 uses the input unit 147 and the output unit 148 to determine whether to transfer the processing of the user receiving the instruction to the individual department knowledge retrieval unit 144 or to continue asking questions. If the processing is transferred to the individual department knowledge retrieval unit 144, the control unit 146 performs the processing of step S1314; if questions still exist, the control unit 146 performs the processing of step S1313.

[0137] Step S1313: The control unit 146 uses the input unit 147 and the output unit 148 to accept the user's choice: whether to ask a question using the prompt set DB141 or to allow the user to input freely. If the prompt set DB141 is used, the control unit 146 returns to step S1306; if the user is allowed to input freely, it returns to step S1308.

[0138] Step S1314: Control Department 146 ends the inter-departmental joint knowledge retrieval process.

[0139] Based on interdepartmental shared knowledge retrieval processing, by using the prompt set DB141, it is possible to filter vehicles (types) associated with a regulation from information related to the regulation, or to filter systems that conflict with the regulation from the systems that constitute the vehicle. For example, when information related to recall regulations or regulations that have been added or amended is extracted, it is easy to identify common interdepartmental elements (vehicles, systems, etc.) that are dependent on the regulation.

[0140] Figure 14 It means in Figure 9 The diagram illustrates an example of the interaction between the user and the dependency visualization device 100, which uses the input unit 147 and the output unit 148, in the interdepartmental shared knowledge retrieval process (step S903).

[0141] Example 1401 indicates that in Figure 13Example 1402 shows an example of prompting the user with a category in step S1302. Example 1402 shows an example of receiving a category from the user in step S1303. Example 1403 shows an example of prompting the user with a region in step S1304. Example 1404 shows an example of receiving a region from the user in step S1305. Example 1405 shows an example of prompting the user with a suggestion in step S1307. Example 1406 shows an example of the user correcting the suggestion in step S1308. Example 1407 shows an example of prompting the user with the answer obtained from the generated AI service or business knowledge DB130 in step S1311.

[0142] Figure 15 It means Figure 9 An example of a flowchart for individual departmental knowledge retrieval processing (step S904). Control unit 146 retrieves information related to the software the user wants to update, information related to regulations obtained by the user in the general inquiry unit 142, information related to vehicles and systems obtained by the user in the inter-departmental joint knowledge retrieval unit 143, and information stored in the prompt set DB141. Figure 10 The prompt shown, type 1002, pertains to content specific to a particular department and is a prompt that has been modified based on the user's input unit 147. Targeting the individual department knowledge retrieval unit 144, vector retrieval techniques are used to collect information related to the components and software required by the user from the departmental inherent knowledge DB132 stored in the business knowledge DB130. Figure 15 The actions in the flowchart are as follows.

[0143] Step S1501: The control unit 146 begins processing and proceeds to step S1502.

[0144] Step S1502: Control unit 146 retrieves all or part of the combinations of categories 1003 contained in the prompt set DB141 for the prompt type 1002 "individual department", as described later. Figure 16 The output is used in the form of Example 1601, and the output is processed in step S1503.

[0145] Step S1503: Based on the output result of step S1502, the control unit 146 receives the user selection from the input unit 147 and then... (The rest of the text is missing). Figure 16 The result of the input in the form of Example 1602 is processed in step S1504.

[0146] Step S1504: Based on the results obtained in step S1503, the control unit 146 uses the output unit 148 (described later) Figure 16In the form of Example 1603, the prompt set DB141 outputs all or part of the combination of the prompt type 1002 "individual department", the category 1003 and the region 1004 included in the prompt that matches the result obtained in step S1503, and performs the processing of step S1505.

[0147] Step S1505: The control unit 146 receives the user selection from the input unit 147 based on the output result of step S1504, and then... (The rest of the text is missing). Figure 16 The result of the input in the form of Example 1604 is processed in step S1506.

[0148] Step S1506: Control unit 146 obtains the prompts that match "individual department" in the categories and regions obtained in steps S1503 and S1505 from prompt set DB141, and performs the processing of step S1507.

[0149] Step S1507: The control unit 146 will transfer the information obtained in step S1506 as described later. Figure 16 The output is used in the form of Example 1605, and the output is processed in step S1508.

[0150] Step S1508: Control unit 146 accepts the user's correction of the prompt. The user copies the output to output unit 148, for example, as described later. Figure 16 The prompt to be used in Example 1605 is overridden internally, delegated to control unit 146 to perform processing, and the processing of step S1509 is executed.

[0151] Step S1509: The control unit 146 uses the interdepartmental shared knowledge retrieval unit 143, via the communication unit 149, to use the API provided by the AI ​​generation service on the Internet, the API provided by the vector retrieval application, etc., and uses the prompts entered in step S1508 to perform knowledge retrieval on the interdepartmental shared knowledge DB131 of the business knowledge DB130, and performs the processing of step S1510.

[0152] Here, although the illustration is omitted, the content extracted from the vehicle configuration management system 112 (which establishes corresponding component configuration tables for systems, components, and software) is stored in the department-specific knowledge DB132 for each department, similar to the content in storage area 500-2. For example, when prompted with "Please extract information about the ECU associated with the system (autonomous driving system) from the information of department (department A)," the inter-departmental shared knowledge retrieval unit 143 uses the content of the component configuration table of department A stored in the department-specific knowledge DB132 to retrieve the component name "AD-ECU" that matches the system name "autonomous driving system." At this time, multiple component names may be retrieved. In addition, for example, when prompted with "Please extract the software names contained in the ECU (AD-ECU) installed in the system (autonomous driving system) from the information of department (department A)," the inter-departmental shared knowledge retrieval unit 143 uses the content of the component configuration table of department A stored in the department-specific knowledge DB132 to retrieve the software names "image recognition software," "cruise control judgment software," "acceleration control software," "brake control software," and "instrument display software" that match the system name "autonomous driving system" and the component name "AD-ECU."

[0153] Additionally, although the illustration is omitted, similar to the content in storage area 500-2, the content extracted from the vehicle configuration management system 112 (ALM (Application Lifecycle Management), SBOM (Software Bill of Materials), etc.) is stored as a software management table (a table corresponding to the software call relationships) in the department's proprietary knowledge DB132. For example, if the prompt is "Please check from the ALM / SBOM whether there is a call relationship between the software to be updated (cruise control judgment software) and other software (image recognition software, acceleration control software, braking control software, instrument display software)," the inter-departmental shared knowledge retrieval unit 143 uses the content of the software management table stored in the department's proprietary knowledge DB132 to search for other software names matching the software name "cruise control judgment software," such as "instrument display software."

[0154] Furthermore, knowledge retrieval is not limited to the above. For example, it may also be possible to retrieve the structure of the component name "AD-ECU" that matches the system name "Autopilot System" by using information (e.g., descriptions of diagrams) from the department-specific knowledge DB132 containing the contents of storage area 400. Additionally, for example, the control unit 146 may also retrieve the structure of the software name "Instrument Display Software" that is in a calling relationship by referring to the basic design or external design section of the software design document for the software to be updated (cruise control judgment software) in the information from the department-specific knowledge DB132 containing the contents of storage areas 700 and 800.

[0155] Step S1510: The control unit 146 obtains the return value of the processing entrusted by the inter-departmental common knowledge retrieval unit 143 in step S1509, and performs the processing in step S1511.

[0156] Step S1511: Control unit 146 uses output unit 148, as described later. Figure 16 The interdepartmental common knowledge retrieval unit 143 outputs the processing results obtained in step S1510 in the form of Example 1607, and performs the processing in step S1512.

[0157] Step S1512: The control unit 146 uses the input unit 147 and the output unit 148 to receive a user instruction on whether to transfer the processing to the visualization unit 145 or continue asking questions. If the processing is transferred to the visualization unit 145, the control unit 146 performs the processing in step S1514; if the question still exists, the control unit 146 performs the processing in step S1513.

[0158] Step S1513: The control unit 146 uses the input unit 147 and the output unit 148 to accept the user's choice: whether to ask a question using the prompt set DB141 or to allow the user to input freely. If the prompt set DB141 is used, the control unit 146 returns to step S1506; if the user is allowed to input freely, it returns to step S1508.

[0159] Step S1514: Control unit 146 ends the individual department knowledge retrieval process.

[0160] Based on individual departmental knowledge retrieval processing, by using the prompt set DB141, it is possible to filter components (ECUs, etc.) related to the system or the software contained in those components based on information related to the system. For example, when information related to recall regulations or regulations that have been added or modified is extracted, after identifying vehicles and systems dependent on those regulations through inter-departmental joint knowledge retrieval processing, it is possible to identify department-specific elements (components, software, etc.) that depend on the system through individual departmental knowledge retrieval processing.

[0161] Figure 16 It means in Figure 9 The diagram illustrates an example of the interaction between the user and the dependency visualization device 100, which uses the input unit 147 and the output unit 148, in the individual department knowledge retrieval process (step S904).

[0162] Example 1601 indicates that in Figure 15 Example 1602 shows an example of prompting the user with a category in step S1502. Example 1602 shows an example of receiving a category from the user in step S1503. Example 1603 shows an example of prompting the user with a region in step S1504. Example 1604 shows an example of receiving a region from the user in step S1505. Example 1605 shows an example of prompting the user with a suggestion in step S1507. Example 1606 shows an example of the user modifying the suggestion in step S1508. Example 1607 shows an example of prompting the user with the answer obtained from the generated AI service or business knowledge DB130 in step S1511.

[0163] Figure 17 It means Figure 9 An example of a flowchart for visualization processing (step S905). Control unit 146, based on information related to the software the user wants to update, information related to regulations obtained by the user in the general inquiry unit 142, information related to the vehicle and system obtained by the user in the inter-departmental common knowledge retrieval unit 143, and information related to the components and software to be updated obtained in the individual departmental knowledge retrieval unit 144, uses visualization unit 145 to display the dependencies related to the software update on output unit 148. Figure 17 The actions in the flowchart are as follows.

[0164] Step S1701: Control unit 146 ensures the following (described later) Figure 18 The vehicle name storage area shown Figure 19 The system name storage area shown Figure 20 The component name storage area shown Figure 21 The software name storage area shown is used to generate drawing IDs. The drawing IDs are stored in the drawing ID areas 1802, 1902, 2002, and 2102 of each area. Processing begins, and step S1702 is performed.

[0165] Step S1702: The control unit 146 extracts the vehicle name from the inter-department shared knowledge DB131 by means of string retrieval and other means based on the vehicle name (type name) information obtained in the inter-department shared knowledge retrieval process (step S903), and performs the processing in step S1703.

[0166] Step S1703: Control unit 146 saves the vehicle name in Figure 18The area 1803 shown is processed in step S1704.

[0167] Step S1704: Control unit 146 extracts the names of the systems included in the vehicle and dependency information related to the visualization of current dependency relationships from the information obtained in the inter-departmental common knowledge retrieval process (step S903) through string retrieval, etc., and performs the processing in step S1705. For example, control unit 146 obtains the names of the systems corresponding to the system names from public information or business knowledge DB130, and extracts the systems retrieved in step S1309 as systems related to the visualization of current dependency relationships.

[0168] Step S1705: The control unit 146 assigns a number to each system name, saves the system number in area 1903, saves the system name in area 1904, saves the existence of dependency relationships in area 1905, and performs the processing of step S1706.

[0169] Step S1706: The control unit 146 extracts the names of the components constituting the system and dependency information related to the visualization of the current dependency relationship from the information obtained in the individual department knowledge retrieval process (step S904) through string retrieval, etc., and performs the processing in step S1707. For example, the control unit 146 obtains the names of the components corresponding to the component names from public information or business knowledge DB130, and extracts the components retrieved in step S1509 as components related to the visualization of the current dependency relationship.

[0170] Step S1707: The control unit 146 assigns a number to each component name, saves the system number containing the component in area 2003, saves the component number in area 2004, saves the component name in area 2005, saves the existence or absence of dependency relationship in area 2006, and performs the processing of step S1708.

[0171] Step S1708: Control unit 146 extracts the software name and dependency information related to the visualization of current dependency relationships from information obtained in individual departmental knowledge retrieval processing through string retrieval, etc., and then proceeds to step S1709. For example, control unit 146 obtains the name of the software corresponding to the software name from public information or business knowledge DB130, and extracts the software retrieved in step S1509 as software related to the visualization of current dependency relationships.

[0172] Step S1709: The control unit 146 assigns a number to each software name, saves the system number of the system containing the software in area 2103, saves the component number of the component carrying the software in area 2104, saves the name of the software in area 2106, saves the presence or absence of dependency relationships in area 2107, and performs the processing of step S1710.

[0173] Step S1710: Control unit 146 will Figure 18 , Figure 19 , Figure 20 , Figure 21 The memory is constructed in a hierarchical manner, as follows: Figure 22 That's how it's visualized. Each element is recorded, and visualization is achieved by connecting elements marked with 0 at their dependencies using lines.

[0174] Step S1711: Control unit 146 determines whether to perform analysis of other vehicles. If analysis of other vehicles is performed, control unit 146 returns to step S1702; otherwise, it proceeds to step S1712.

[0175] Step S1712: Control unit 146 ends visualization processing.

[0176] Figure 18 Is Figure 17 The illustration shows an example of how vehicle-related information is stored in memory transfer, specifically in step S1703 (storage area 1800). Storage area 1800 consists of a drawing ID area 1801 and a vehicle name area 1803. The drawing ID generated in step S1701 is recorded in area 1802.

[0177] Figure 19 Is Figure 17 The illustrated memory transfer, specifically the storage format for system-related information transferred in step S1705 (storage area 1900), is an example. Storage area 1900 consists of a drawing ID area 1901, a system number area 1903, a system name area 1904, and an area 1905 indicating whether there is a dependency relationship. The drawing ID generated in step S1701 is recorded in area 1902.

[0178] Figure 20 Is Figure 17 The illustrated memory transfer, specifically the storage format for transferring component-related information in step S1707 (storage area 2000), is an example. Storage area 2000 consists of a drawing ID area 2001, a system number area 2003, a component number area 2004, a component name area 2005, and an area 2006 indicating whether there is a dependency relationship. The drawing ID generated in step S1701 is recorded in area 2002.

[0179] Figure 21 Is Figure 17The illustrated memory transfer, specifically the storage format for transferring software-related information in step S1709 (storage area 2100), is an example. Storage area 2100 consists of a drawing ID area 2101, a system number area 2103, a component number area 2104, a software ID area 2105, a software name area 2106, and an area 2107 representing dependencies. The drawing ID generated in step S1701 is recorded in area 2102.

[0180] Figure 22 This is an example of the software dependencies that are output to the output unit 148 through visualization processing (step S905) (display example 2200).

[0181] Display example 2200 shows the systems, components, and software with dependencies for each vehicle (type), with the software dependencies visualized.

[0182] Figure 23 This is an example (Display Example 2300) of the software dependencies output to the output unit 148 through visualization processing (step S905). In the case of Display Example 2300, for example, the control unit 146, instead of step S1704, extracts the regulatory name that matches the vehicle and the dependency information related to the visualization of the current dependency relationship from the information obtained in the general query processing (step S902) by string retrieval or the like. Then, instead of step S1705, the control unit 146 assigns a number to each regulatory name, saves the regulatory number, regulatory name, and the presence or absence of the dependency relationship, and performs the processing in step S1706.

[0183] In Example 2300, for each vehicle (type), the software dependencies are visualized by showing what regulatory requirements it complies with, by each component constituting that regulation, and by the software contained therein.

[0184] Here, the regulations section shows UN regulations such as "UN-R," but it could also be Japanese automotive-related laws, EU regulations, North American regulations, Chinese regulations, and other national laws. Furthermore, not only... Figure 22 The content related to autonomous driving shown is as follows: Figure 23 As shown, other components and the software that makes up the components can also be shown.

[0185] (II) Notes

[0186] In the above-described embodiments, for example, the following content may be included.

[0187] The above embodiments describe the application of the present invention to a dependency visualization device, but the present invention is not limited thereto and can be widely applied to various other systems, devices, methods, and programs.

[0188] A feature of this invention is the use of RAG (Retrieval-Augmented Generation). The use of business knowledge DB130 and dependency resolution unit 140 are examples of RAG. This invention can also be applied to industrial sectors other than the automotive industry.

[0189] Furthermore, while the above embodiments describe the dependency visualization device 100 filtering regulations, vehicles, systems, components, etc., the present invention is not limited thereto. For example, filtering can also be based on user subscriptions. For instance, if the dependency visualization device 100 has subscribed to an autonomous driving subscription that provides the latest features, the current update can also filter by subscribed users.

[0190] Furthermore, while the above embodiments describe the dependency visualization device 100 displaying software dependencies in a hierarchical structure, the present invention is not limited thereto. For example, the dependency visualization device 100 may also list and display software related to an update object.

[0191] Furthermore, in the above embodiments, part or all of the program can also be installed from the program source onto a device such as a computer that implements the dependency visualization device. The program source can be, for example, a program distribution server connected via a network or a computer-readable recording medium (e.g., a non-transitory recording medium). Additionally, in the above description, two or more programs can be implemented as one program, or one program can be implemented as two or more programs.

[0192] Furthermore, in the above implementation, the structure of each table is an example. A table can be divided into two or more tables, and all or part of two or more tables can also be a single table.

[0193] Furthermore, in the above embodiments, for ease of explanation, tables are used to illustrate information related to the dependency visualization device, but the data structure is not limited to tables. Information related to the dependency visualization device can be represented by data structures other than tables, such as XML (Extensible Markup Language), YAML (YAML Ain't a Markup Language), hash tables, and tree structures.

[0194] Furthermore, in the above embodiments, the illustrated and explained screens are just examples; as long as the information received is the same, the design can be arbitrary.

[0195] Furthermore, in the above embodiments, the illustrated and explanatory screens are just examples; as long as the information displayed is the same, the design can be arbitrary.

[0196] Furthermore, in the above embodiments, the output of information is not limited to display on a monitor. The output of information may be sound output based on a speaker, output to a document, printing on paper media or the like based on a printing device, projection onto a screen or the like based on a projector, or other methods.

[0197] In addition, as described above, the programs, tables, files, and other information that implement each function can be placed on storage devices such as memory, hard disk, SSD (Solid State Drive), or recording media such as IC card, SD card, and DVD.

[0198] The above-described embodiments have, for example, the following characteristic structures. (1)

[0200] A dependency visualization device (e.g., dependency visualization device 100) visualizes the dependencies of software. The dependency visualization device includes: a filtering unit (e.g., dependency resolution unit 140, control unit 146) that interacts with the user using knowledge information (e.g., business knowledge DB 130) containing information about software-related elements (e.g., regulations, vehicles, systems, components, software) to periodically filter elements related to the update object (e.g., recalls, legal amendments, etc.); and an output unit (e.g., dependency resolution unit 140, output unit 148) that outputs the software dependencies related to the update object based on the elements filtered by the filtering unit.

[0201] In the above structure, elements related to the updated object are filtered in stages, so that, for example, users can easily communicate with the dependency visualization device and easily grasp the software dependencies related to the updated object. (2)

[0203] The system comprises: an acquisition unit (e.g., business knowledge extraction unit 120, knowledge database generation unit 121, step S202) that acquires descriptive text 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 database generation unit 121, step S203) that replaces the images in the document with the descriptive text acquired by the acquisition unit, and extracts the generation date and time of the replaced document, the file name of the document, and data of keywords contained in the document; and a storage unit (e.g., business knowledge extraction unit 120, knowledge database generation unit 121, step S204) that stores the data extracted by the extraction unit as knowledge information.

[0204] Based on the above structure, the images contained in the existing documents are stored as explanatory text in the knowledge information, so the existing documents can be effectively utilized, for example, in the visualization of dependencies using RAG software. (3)

[0206] The screening unit comprises: a first screening unit (e.g., a general inquiry unit 142) that receives information about an update target and obtains information about regulations associated with the received update target from publicly available information; a second screening unit (e.g., an interdepartmental common knowledge retrieval unit 143) that, based on the knowledge information and dialogue with the user, determines vehicles associated with the regulations obtained by the first screening unit and determines systems that conflict with the regulations from the systems constituting the determined vehicles; and a third screening unit (e.g., an individual departmental knowledge retrieval unit 144) that determines components related to the systems determined by the second screening unit and determines the software contained in the determined components.

[0207] In the above structure, for example, it is possible to identify the regulations associated with the object being updated, the vehicle associated with those regulations, the systems within the vehicle that conflict with those regulations, the components associated with those systems, and the software contained within those components. According to this structure, for example, a user can establish corresponding software dependencies with the vehicle, the system, and the components. (4)

[0209] For the vehicles, systems, components, and software determined by the filtering unit, the output unit links and outputs the elements with dependencies (e.g., refer to...). Figure 22 Furthermore, the output unit can also link and output dependent elements for the vehicles, regulations, components, and software determined by the filtering unit.

[0210] In the above structure, elements with dependencies are linked and output, so that, for example, users can easily grasp the software's dependencies. (5)

[0212] The dependency visualization device includes a storage unit (e.g., a prompt set DB141, a table 1000) that stores examples of prompts for determining regulations, examples of prompts for determining types related to regulations, examples of prompts for determining systems that conflict with regulations, examples of prompts for determining components related to systems, and examples of prompts for determining software included in components.

[0213] In the above structure, for example, examples of prompts are provided in the dialogue with the user, thus reducing the workload for the user generating the prompts. Furthermore, for example, by using examples of prompts, the likelihood of making responses that the user does not expect is reduced, thus allowing for efficient use of computer resources.

[0214] Furthermore, the above-described structure may be appropriately modified, reorganized, combined, or omitted without departing from the spirit of this invention.

[0215] It should be understood that items included in the list in the form of "at least one of A, B, and C" can refer to (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). Similarly, items listed in the form of "at least one of A, B, and C" can refer to (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0216] Symbol Explanation

[0217] 100···Dependency Relationship Visualization Device, 120···Business Knowledge Extraction Department, 130···Business Knowledge Database, 140···Dependency Relationship Resolution Department.

Claims

1. A dependency visualization device that visualizes the dependency relationships of software, characterized in that, The dependency visualization device includes: The screening department uses knowledge information containing elements related to the software to engage in dialogue with users, and periodically filters and updates elements related to the object from the software-related elements. as well as The output section, based on the elements filtered by the filtering section, outputs the software dependencies related to the updated object.

2. The dependency visualization device according to claim 1, characterized in that, The dependency visualization device includes: The acquisition department obtains explanatory text for images contained in documents managed by existing business systems through a generative AI service; The extraction unit replaces the image of the document with the explanatory text obtained by the acquisition unit, and extracts the generation date and time of the replaced document, the file name of the document, and the data of the keywords contained in the document; as well as The storage unit stores the data extracted by the extraction unit as knowledge information.

3. The dependency visualization device according to claim 1, characterized in that, The screening unit includes: The first screening department receives information about the updated targets and obtains information about the regulations associated with the received updated targets from publicly available information. The second screening unit, based on the knowledge information and dialogue with the user, determines vehicles associated with regulations obtained by the first screening unit, and identifies systems that conflict with the regulations from the systems constituting the determined vehicles. as well as The third screening unit determines the components related to the system determined by the second screening unit, and determines the software contained in the determined components.

4. The dependency visualization device according to claim 3, characterized in that, For the vehicles, systems, components, and software determined by the filtering unit, the output unit links and outputs the elements that have dependencies.

5. The dependency visualization device according to claim 3, characterized in that, The dependency visualization device includes: a storage unit that stores examples of prompts for determining regulations, examples of prompts for determining the type of regulation, examples of prompts for determining a system that conflicts with regulations, examples of prompts for determining components related to the system, and examples of prompts for determining software included in the components.

6. A dependency visualization method, which visualizes the dependency relationships of software, characterized in that, The dependency visualization method includes the following steps: The screening department uses knowledge information containing elements related to the software to engage in dialogue with users, and periodically filters and updates elements related to the object from the software-related elements. as well as The output unit outputs the software dependencies related to the updated object based on the elements filtered by the filtering unit.

Images