Simulation device, simulation method and program

Abstract

Reduce the impact on the overall development process of rework caused by inconsistent specifications between ECUs. [Solution] A simulation device that verifies the specifications of a computer system through simulation, comprising: a simulation condition receiving unit that receives input of simulation conditions including at least one of the simulation's target scope, purpose, and viewpoint; a specification information extraction unit that extracts information related to the simulation conditions from specification data using an AI agent; a model generation unit that generates a model for simulation based on the extracted information; and a simulation execution unit that performs verification by simulation using the generated model.

Description

[Technical Field]

[0001] The present invention relates to a simulation device, a simulation method, and a program. [Background technology]

[0002] Automobiles are equipped with multiple ECUs (Electronic Control Units) to control various functions such as the engine, brakes, transmission, etc. Before shipping a product, it is necessary to conduct tests to check for specification inconsistencies between the ECUs.

[0003] Conventionally, as described in Patent Document 1, for example, an operation check test has been carried out using an implemented ECU. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2018 / 138816 Summary of the Invention [Problem to be solved by the invention]

[0005] However, if an inconsistency is detected during testing using the implemented ECU, rework is required, which has a significant impact on the progress of the overall vehicle development.

[0006] Therefore, an object of the present invention is to reduce the impact on the entire development process caused by rework due to inconsistencies in specifications between ECUs. [Means for solving the problem]

[0007] A simulation device according to one embodiment of the present invention is a simulation device that verifies the specifications of a computer system through simulation, and includes a simulation condition receiving unit that receives input of simulation conditions including at least one of the scope, purpose, and viewpoint of the simulation, a specification information extraction unit that extracts information related to the simulation conditions from specification data using an AI agent, a model generation unit that generates a model for simulation based on the extracted information, and a simulation execution unit that performs verification by simulation using the generated model.

[0008] A simulation method according to one embodiment of the present invention includes a simulation condition receiving step in which a computer that verifies the specifications of a computer system through simulation receives input of simulation conditions including at least one of the scope, purpose, and viewpoint of the simulation; a specification information extraction step in which an AI agent extracts information related to the simulation conditions from specification data; a model generation step in which a model for simulation is generated based on the extracted information; and a simulation execution step in which verification by simulation is performed using the generated model.

[0009] A program according to one embodiment of the present invention causes a computer that verifies the specifications of a computer system through simulation to function as a simulation condition receiving unit that receives input of simulation conditions including at least one of the scope, purpose, and viewpoint of the simulation, a specification information extraction unit that uses an AI agent to extract information related to the simulation conditions from specification data, a model generation unit that generates a model for simulation based on the extracted information, and a simulation execution unit that performs verification through simulation using the generated model. [Effects of the Invention]

[0010] According to the present invention, it is possible to reduce the impact on the entire development process caused by rework due to inconsistencies in specifications between ECUs. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a diagram showing the configuration of a simulation system 1 according to the present embodiment. [Figure 2] 1 is a block diagram showing the configuration of a simulation device 10 according to the present embodiment. [Figure 3] FIG. 2 is a block diagram showing the configuration of a user terminal 20 according to the present embodiment. [Figure 4] 1 is a block diagram showing functional modules of a program executed by a processor 11 of a simulation device 10 according to the present embodiment. [Figure 5] 1 is a flowchart showing an outline of a simulation performed by the simulation system 1 according to the present embodiment. [Figure 6] 3 is a flowchart specifically showing processing in each step by the simulation system 1 according to the present embodiment. [Figure 7] 3 is a flowchart specifically showing processing in each step by the simulation system 1 according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] Next, embodiments of the present invention will be described in detail with reference to the drawings. 1 is a diagram illustrating the configuration of a simulation system 1 including a simulation device 10 according to an embodiment of the present invention. The simulation system 1 is a system for executing a simulation of the operation of a computer system in accordance with its specifications and detecting defects in the specifications. In this embodiment, as an example, the simulation system 1 detects inconsistencies between the specifications of multiple ECUs installed in an automobile.

[0013] 1, the simulation system 1 includes a simulation device 10 that executes a simulation, and a user terminal 20 that allows a user to input instructions and the like into the simulation device 10 and check the simulation results. The simulation device 10 is connected to the user terminal 20 via a communication network N such as the Internet.

[0014] 2 is a block diagram showing the configuration of the simulation device 10. The simulation device 10 may be a general-purpose computer, and may be configured as a single computer, or may be configured as multiple computers distributed over a communication network N. The simulation device 10 may be installed in a management center of a company or the like, or may be built on the cloud. Furthermore, the functions of the simulation device 10 may be implemented in a user terminal 20.

[0015] 2, the simulation device 10 includes a processor 11, a main memory 12, an input / output interface 13, a communication interface 14, and a storage device 15. The storage device 15 is a computer-readable recording medium such as a semiconductor memory (e.g., a volatile memory or a non-volatile memory) or a disk medium (e.g., a magnetic recording medium or a magneto-optical recording medium). The storage device 15 stores programs to be executed by the processor 11, various data, and the like. The programs are read from the storage device 15 into the main memory 12, and are interpreted and executed by the processor 11 to perform various functions.

[0016] 3 is a block diagram showing the configuration of the user terminal 20. The user terminal 20 may be any terminal device capable of transmitting and receiving data to and from the simulation device 10 via the communication network N, such as a personal computer (PC), a notebook PC, a tablet terminal, or a smartphone.

[0017] 3, the user terminal 20 includes a processor 21, an input device 22 such as a keyboard, a mouse, various operation buttons, or a touch panel, a display device 23 such as a liquid crystal display, a communication interface 24 for connecting to the communication network N, and a storage device 25 such as a disk drive or semiconductor memory (ROM, RAM, etc.). The storage device 25 may store various programs executed by the processor 21 and various data. The user terminal 20 may be equipped with an application that provides a user interface, etc. for using the simulation system 1.

[0018] 4 is a block diagram showing functional modules of a program executed by the processor 11 of the simulation device 10. As shown in Fig. 4, the functional modules executed by the processor 11 of the simulation device 10 include a specification input receiving unit 101, a specification conversion unit 102, a specification confirmation unit 103, a simulation condition receiving unit 104, a specification information extraction unit 105, a model generation unit 106, a review support unit 107, a simulation execution unit 108, and a simulation result output unit 109. Note that the functions of the simulation device 10 in this embodiment may be implemented in the user terminal 20.

[0019] Next, the general flow of a simulation by the simulation system 1 will be described with reference to the flowchart in FIG. 5. First, specification data of an ECU to be verified is input to the simulation device 10, and the specification input receiving unit 101 receives the input (step ST1). The specification data can be input by a user specifying a storage location (such as a database) of the specification data via the user terminal 20, or by uploading specification data acquired from the storage location. The specification data may include text data, tabular data, image data, etc. The specification data may also be written in a natural language.

[0020] Next, the specification conversion unit 102 converts the input specification data written in natural language into a format such as a predetermined modeling language (step ST2). In this embodiment, the data is converted into SysML (registered trademark) as an example, but other artificial languages ​​may be used as long as they can visually and clearly express the specifications of the system or software. The conversion into the modeling language may be performed by a dedicated trained AI. The specification conversion unit 102 converts the specification data into a requirement diagram, sequence diagram, data flow diagram, etc. in SysML format, and the conversion result can be treated as a structured model.

[0021] Next, the specification confirmation unit 103 checks the specifications converted into SysML format (step ST3). The specification check may be performed by a dedicated, trained AI agent. The AI ​​agent checks for omissions and consistency for each type of drawing. If there are any missing items, candidates for completion may be presented.

[0022] Next, the simulation condition receiving unit 104 receives input of simulation conditions including at least one of the target range, purpose, and viewpoint of the simulation (step ST4). The user can input the simulation conditions via the user terminal 20. Specifically, the user specifies the purpose of the simulation (e.g., verification of communication timing), the target range of the simulation (e.g., powertrain ECU), and the verification viewpoint (e.g., state transition, error handling). The conditions may be specified by selecting from presented options, or by entering free words. For example, when a purpose is specified, a list of target ranges related to that purpose may be displayed, and when a target range is selected, a list of related verification viewpoints may be displayed. When free words are entered, the AI ​​may interpret the content.

[0023] Next, in the specification information extraction unit 105, the trained AI agent extracts information related to the specified simulation conditions from the specification data converted to SysML (step ST5). The AI ​​agent may analyze the original natural language specification in units corresponding to chapters and extract the target chapters. Furthermore, even if they are not directly targeted, structurally related chapters may also be extracted as needed.

[0024] Next, in the model generation unit 106, the trained AI agent generates a model for simulation based on the extracted information (step ST6). The AI ​​agent models the extracted chapters based on SysML. The modeled chapters are then aggregated to generate a virtual ECU (hereinafter referred to as vECU) with the minimum configuration required for the purpose. This prevents the model from becoming too large and improves the speed of model generation and simulation.

[0025] Next, the review support unit 107 presents the generated model and the corresponding specification data information so that the user can compare them (step ST7). This is a support function for complying with ISO26262 (functional safety standard for E / E systems (electrical / electronic systems) installed in automobiles), and allows the user to check the correspondence between the original specification and the generated model.

[0026] Next, the simulation execution unit 108 performs verification by simulation using the generated model (step ST8). The results of the simulation are output in the form of log data, graphs, or reports.

[0027] Finally, the simulation result output unit 109 outputs the simulation result (step ST9). Based on the simulation result, the specifications may be modified, and steps ST1 to ST9 may be repeated using the modified specification data.

[0028] Next, the processing in each step will be described in more detail with reference to the flowcharts of FIGS. <Step ST1: Input specifications> As shown in Figure 6, the specification is a file in a format such as Word (registered trademark), Excel (registered trademark), or PDF (registered trademark), and data written in natural language is input. Multiple pieces of data may be input. The AI ​​agent that analyzes the specification creates a natural language output in LLM based on the analysis results and presents it to the user as a check result. The user modifies the specification based on the check results and re-enters the modified specification. This process is repeated until no further modification of the specification is required, and finally the modified specification data is supplied to the next process.

[0029] <Step ST2: Conversion to SysML> Next, the AI ​​agent converts the revised specifications into SysML format, and generates requirement models such as requirement diagrams, structural models such as block definition diagrams, and behavioral models such as data flow diagrams, sequence diagrams, and traceability information based on the specifications.

[0030] <Step ST3: Specification check> Next, the AI ​​agent that checks the specifications analyzes each model generated in ST2 and checks the specifications. The check results are output in natural language. If there are any oversights or omissions in the specifications, candidates for completing them may be presented. When the user instructs the system to complete a model, the target model is completed and the completed diagrams are output.

[0031] Addressing any oversights or omissions in the specifications at this stage is important in order to prevent increases in ECU development costs and time. Specifications are often incomplete in the early stages of development, and if work continues with incomplete specifications, the following problems are likely to occur: - vECU cannot be generated due to missing or ambiguous descriptions. Simulation using vECU is not possible, and specifications cannot be verified. This results in rework and defects in later processes, increasing development costs and time.

[0032] For these reasons, it is important to check the quality of specifications in advance, and to introduce a system to detect and correct any omissions or insufficient considerations at an early stage.However, checking specifications generally presents the following technical challenges. Specifications written in natural language have an ambiguous structure and are difficult to analyze mechanically. Manual review takes time and effort and is highly dependent on the individual. -As a prerequisite for creating a vECU, it is necessary to ensure the completeness and consistency of specifications.

[0033] In order to solve the above technical problems, in this embodiment, specifications are checked using the following mechanisms 1 to 4. 1. Natural language analysis by AI agents An AI agent analyzes specifications and automatically detects omissions and insufficient considerations.

[0034] 2.Structuring by converting to SysML The specifications are first converted into SysML. SysML uses the following drawing notation, which is suitable for structuring specifications. Structuring allows for more accurate checking. Requirement diagram Sequence diagram Data flow diagram Block definition diagram

[0035] 3. Checking each drawing by a specialized AI agent Each SysML diagram is checked by an AI agent that has undergone specialized machine learning.

[0036] 4. Improving accuracy through division of roles AI agents are divided and designed according to their purpose, and clarifying their roles improves the accuracy of analysis. For example, there are AI agents specialized in checking requirement diagrams and AI agents specialized in checking interface consistency.

[0037] The above mechanism is expected to have the following effects: - Specifications can be automatically evaluated and completed before creating a vECU. - It reduces the amount of work required for manual review and eliminates dependency on individuals. - Structuring the specifications makes it possible to improve the efficiency of subsequent processes (model generation and simulation execution). As a result, defects can be prevented in the early stages of development and rework can be reduced.

[0038] As mentioned above, by combining the analysis of specifications (natural language) by an AI agent with conversion to SysML, it is possible to perform more accurate and efficient checking than manual natural language-based specification checking.

[0039] <Step ST4: Input simulation conditions> Next, the user inputs the simulation conditions (scope, purpose, viewpoint, etc.). <Step ST5: Extraction and modeling of target chapters> Next, as shown in Figure 7, the AI ​​agent extracts the components necessary for generating a vECU model from the specifications converted to SysML based on the simulation conditions entered in step ST4. Specifically, the AI ​​agent determines the SysML drawing type, search keywords, and confirmation viewpoint based on the entered conditions. It then extracts the target scope and required additional elements from each completed diagram output in step ST3. It then re-creates the model in SysML format, excluding specifications outside the target scope. This outputs each diagram (requirement diagram, block definition diagram, data flow diagram, sequence diagram, and traceability information) reconstructed based on the extracted target scope. Furthermore, a test scenario for performing the simulation is generated based on the entered simulation conditions.

[0040] <Step ST6: Optimization and generation of vECU configuration> Next, based on the SysML model reconstructed in step ST6, the AI ​​agent generates a vECU optimized for the purpose of the simulation. The AI ​​agent outputs traceability information along with the generated vECU.

[0041] (Generating vECUs according to the scope of the simulation) As shown in steps ST4 to ST6, in this embodiment, after specifying the simulation conditions, a vECU optimized for the purpose of the simulation is generated. In specification verification using a vECU, the level of detail of a model based on the specification has a significant effect on the verification accuracy and the execution speed of the simulation. The higher the level of detail of the model, the higher the verification accuracy, but at the cost of this, the following problems arise. Slower execution speed: Detailed models are computationally intensive and take longer to simulate. Increased information content in specifications: Detailed models require a lot of design information, which increases the amount of work required to complete specifications. - Modeling is difficult in the early stages of development due to the lack of detailed information.

[0042] That is, simulation using vECU has the following issues: - The criteria for determining how detailed a model is needed for the purpose of the simulation are unclear. If the scope of the model is too broad, unnecessary processing increases in the simulation, reducing efficiency.

[0043] In order to solve the above problem, the present embodiment employs the following mechanism. 1. Input of simulation conditions (Step ST4) The user can enter the following conditions: Simulation scope - Points to check (e.g., communication timing, state transition, error handling, etc.)

[0044] 2. Divide the specification into chapters and judge them (Step ST5) The specification is divided into chapters (functional units), and the following items are judged for each chapter. -Whether or not to use vECU based on input conditions -Additional determination of the chapter required for the structure of vECU

[0045] 3. Modeling and aggregation using AI agents The AI ​​agent models the chapters determined to be relevant using SysML (step ST5). The generated models are aggregated to generate a vECU (step ST6). This allows for the generation of a vECU with the optimal level of detail using the minimum necessary configuration.

[0046] The above mechanism is expected to have the following effects: - The optimal level of detail for the model can be automatically determined depending on the purpose of the simulation. - Avoid modeling unnecessary chapters (functions) and ensure a balance between simulation speed and verification accuracy. - The work required to complete specifications is minimized, allowing verification to be performed even in the early stages of development. As described above, it is possible to flexibly configure a model according to the purpose of the simulation, and practical simulations become possible.

[0047] (Centralized management of specifications and generation of vECUs according to purpose) Furthermore, according to this embodiment, the relationship between the specification and the vECU can be managed flexibly and efficiently. The required functions and fairness of a simulation using a vECU vary depending on the purpose. However, when the purpose of the simulation is diverse, the model becomes bloated, resulting in the following problems. - Simulation speed decreases as the model size increases. - The model structure becomes more complex, reducing maintainability and reusability. The specification must be divided according to the model, making it difficult to maintain consistency and ensure readability. In other words, dividing the specification can lead to problems such as duplication of information, lack of consistency, and difficulty in reviewing. For the above reasons, in this embodiment, the specifications are not divided but are managed centrally, and only the vECU is generated by optimizing it according to the purpose. Specifically, the following mechanism is used to automatically extract the configuration for generating the minimum necessary vECU according to the simulation purpose.

[0048] 1. Simulation objective input (Step ST4) The user inputs the purpose of the simulation (e.g., verifying communication timing, checking error handling, etc.).

[0049] 2. Analysis and extraction by AI agents (Step ST5) Based on the objectives entered, the AI ​​agent will determine the following: SysML diagram type (e.g., requirement diagram, sequence diagram, etc.) Search keywords (e.g., CAN communication, state transition, etc.) - Check points (e.g., timing consistency, presence or absence of error handling, etc.)

[0050] 3. Extraction of the scope of the specification (Step ST5) Using the above search keywords, extract the chapters and descriptions necessary for the simulation from the specifications. In this case, the specifications themselves are not divided, and only the necessary information is extracted by searching.

[0051] 4. Linking to vECU generation (Step ST5) A model is reconstructed from the target scope of the extracted specifications and handed over to the vECU generation process (step ST6), which makes it possible to generate a lightweight, highly accurate vECU that meets the purpose.

[0052] As described above, the above mechanism is expected to have the following effects: - It is possible to generate a vECU optimized for the purpose of the simulation. · Maintain centralized management of specifications and prevent model bloat. The correspondence between the model and the specifications becomes clear, making review and maintenance easier. -Improved simulation speed and development efficiency are realized.

[0053] <Step ST7: Review of deliverables> Next, the user reviews the generated vECU. Specifically, the user compares it with the modified specifications using the traceability information created in step ST6 and outputs the review results.

[0054] In this embodiment, an AI agent is used to generate a vECU and perform simulations, thereby streamlining specification verification in the early stages of development. However, the development of automotive ECUs requires compliance with ISO 26262, a functional safety standard. ISO 26262 requires a "Tool Confidence Level (TCL)" evaluation of the tools used for development. However, using an AI agent makes TCL evaluation difficult for the following reasons: The AI's decision-making logic is a black box, making the basis for its output unclear. · Safety cannot be guaranteed if human inspection of automatically generated deliverables is omitted.

[0055] In this embodiment, the following mechanism is used to achieve both AI-based automation and the tool qualification requirements of ISO26262, thereby ensuring the reliability and traceability of automatically generated deliverables.

[0056] 1. Incorporating a deliverable review process In the vECU generation process (step ST6), by providing a step in which the user checks and approves the intermediate product output by the AI ​​agent, it is possible for a human to evaluate the output of the AI ​​agent.

[0057] 2. Ensuring traceability Maintain clear correspondence (traceability) between the original specification (natural language) and the deliverables produced by the AI ​​agent. Example: Record and display which part of the specification document each SysML diagram was generated based on.

[0058] 3. Introduction of review support function By utilizing traceability information, we provide a user interface and support tools that allow users to efficiently check the validity of the results produced by AI agents. Examples: diff display, evidence linking, change history visualization, etc.

[0059] As an example of a support tool, the generated vECU may be presented in a format one step below source code, such as Simulink (registered trademark), so that it can be compared with the description in the corresponding specification. By displaying the deliverables in a format that is more abstract and easier to understand than source code, it is easier for users to check the validity of the deliverables, and there is also the advantage that after the review, a vECU can be generated and a simulation can be performed immediately.

[0060] The above mechanism is expected to have the following effects: Lowering the hurdles for tool certification under ISO26262. - Achieve automation through AI agents while ensuring safety and reliability. -Ensuring traceability will improve the efficiency of reviews to ensure the quality of deliverables.

[0061] <Step ST8: Run simulation> Next, using the vECU generated in step ST6, a simulation is executed according to the test scenario generated in step ST5, and the simulation result is output.

[0062] <Step ST9: Check results and feedback> Finally, the user checks the output simulation results.

[0063] As described above, according to this embodiment, the AI ​​agent extracts necessary information from specifications based on the conditions of a simulation using an ECU, and generates a vECU for the simulation from the extracted information. This makes it possible to generate a model that has the necessary configuration and accuracy according to the purpose of the simulation, while omitting unnecessary functions. This makes it possible to verify specifications from the early stages of development while reducing the cost and man-hours required for simulation. This prevents delays in the overall development process due to rework caused by specification inconsistencies.

[0064] In addition, the AI ​​agent converts specifications written in natural language into formats such as SysML, and checks for inconsistencies and completes missing information, allowing specifications to be efficiently revised before running a simulation.

[0065] In addition, a user interface is provided to check the correspondence between the output of the AI ​​agent and the original natural language specification, which enables compliance with standards such as ISO, which are essential in product development.

[0066] The above-described embodiments are intended to facilitate understanding of the present invention and are not intended to limit the present invention. The flowcharts, sequences, and specific examples of the elements included in the embodiments are not limited to those exemplified and can be modified as appropriate. Furthermore, configurations shown in different embodiments can be partially substituted or combined with each other. [Explanation of symbols]

[0067] 1...Simulation system, 10...Simulation device, 11...Processor, 12...Main memory, 13...Input / output interface, 14...Communication interface, 15...Storage device, 20...User terminal, 21...Processor, 22...Input device, 23...Display device, 24...Communication interface, 25...Storage device, 101...Specification input reception unit, 102...Specification conversion unit, 103...Specification confirmation unit, 104...Simulation condition reception unit, 105...Specification information extraction unit, 106...Model generation unit, 107...Review support unit, 108...Simulation execution unit, 109...Simulation result output unit

Claims

1. A simulation device that verifies specifications of a computer system by simulation, comprising: a simulation condition receiving unit that receives input of simulation conditions including at least one of a target range, a purpose, and a viewpoint of the simulation; a specification information extraction unit that extracts information related to the simulation conditions from the specification data by an AI agent; and a model generation unit that generates a model for simulation based on the extracted information.

2. 2. The simulation device according to claim 1, further comprising a specification confirmation unit that uses an AI agent to check for omissions and / or consistency in the specification data as a preliminary step of extracting information related to the simulation conditions from the specification data.

3. 3. The simulation device according to claim 1, further comprising a review support unit that presents a product generated by the AI ​​agent and information on the corresponding specification data so that a user can compare them.

4. a specification conversion unit that converts a specification written in natural language into specification data in a format that expresses the specification using multiple types of drawings; The specification confirmation unit 3. The simulation device according to claim 2, wherein a check for omissions and / or consistency is carried out according to the type of drawing.

5. The specification conversion unit 5. The simulation device according to claim 4, wherein a specification written in natural language is converted into a SysML format by an AI agent.

6. The specification information extraction unit 3. The simulation device according to claim 1, wherein the specification data is divided into functional units, and whether modeling is required for each function is determined based on the simulation conditions.

7. The specification information extraction unit 3. The simulation device according to claim 1, further comprising: determining a search keyword for identifying information to be extracted from the specification data based on the simulation conditions.

8. The review support unit The simulation device according to claim 3 , further comprising information for ensuring traceability between the deliverables and the specification data.

9. The review support unit 9. The simulation device according to claim 8, further comprising a user interface that enables the user to check whether the deliverable complies with a standard based on the information for ensuring traceability.

10. The simulation device according to claim 1 , further comprising a simulation execution unit that performs verification by simulation using the generated model.

11. A computer that verifies the specifications of a computer system through simulation a simulation condition receiving step of receiving an input of simulation conditions including at least one of a target range, a purpose, and a viewpoint of the simulation; a specification information extraction step of extracting information related to the simulation conditions from the specification data by an AI agent; a model generation step of generating a model for simulation based on the extracted information; a simulation execution step of performing verification by simulation using the generated model.

12. A computer that verifies the specifications of a computer system through simulation is called a simulation condition receiving unit that receives input of simulation conditions including at least one of a target range, a purpose, and a viewpoint of the simulation; a specification information extraction unit that extracts information related to the simulation conditions from the specification data by an AI agent; a model generation unit that generates a model for simulation based on the extracted information; A program that functions as a simulation execution unit that performs verification by simulation using the generated model.

Images