JP2006343858A - Model formation support system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To shorten a development period or improve business efficiency by enhancing the reusability of accumulated information related to parts or the like in development of an automobile. <P>SOLUTION: The system comprises storage devices storing parameters used for formation of model, tools used for formation of model and model templates for a plurality of parts constituting a system, respectively. A model of each part is formed by reading, according to an instruction content inputted by a user, templates of the plurality of parts and parameters, and assigning the parameters to the model templates of the plurality of parts, and the models of the plurality of parts are combined by reading and executing the tools, whereby a model of the system is formed. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a technique that is effective when applied to an apparatus, a system, or the like for creating a model used for a simulation performed when developing an automobile part or system.

2. Description of the Related Art Conventionally, there has been proposed a technique for improving business efficiency by accumulating information that can be repeatedly used in a database and reusing the accumulated information as necessary. For example, in the development of business application systems, a technique for improving the efficiency of development by standardizing and storing various general processes necessary for the operation of the system has been proposed (see Patent Document 1). In this technology, a user selects a desired functional element while referring to a functional model representing a typical functional configuration, and customizes the selected functional element, thereby enabling individual business application systems to be designed. Can be developed. In addition, it is determined whether the material property parameter of the material selected according to the use of the product to be manufactured satisfies the required material property, and by storing the determination result, the optimum material and structure can be easily and efficiently Has been proposed (see Patent Document 2).
JP 2003-91416 A JP 2004-227295 A

  However, in the case of application design or the like as in the above-described prior art (particularly, Patent Document 1), information stored and reused is a program or data itself incorporated in an application to be designed. For this reason, when they are reused, there is almost no need for a different design environment or design tool for each information to be used, and the information can be easily reused.

  On the other hand, in a design using physical elements such as automobile development, the accumulated information is naturally not the part itself (engine, brake, etc.) incorporated in the automobile to be designed. In such a design using physical elements, information regarding these physical elements is accumulated instead of such components themselves. When reusing these pieces of information, different environments and tools depending on the design of each physical element are often required. For this reason, it has been difficult to apply the above-described conventional technology as it is to automobile development support. However, even in such a case, it is required to design in a short time in order to increase the effect of shortening the development period and improving the quality.

  Accordingly, an object of the present invention is to provide a system and method that can shorten the development period and improve business efficiency by improving the reusability of information related to parts accumulated in the development of automobiles. .

In order to solve the above problems, the present invention is configured as follows. A first aspect of the present invention is a model creation support system for creating model data of a system used when simulating a system used in an automobile, and includes a data storage device, a tool storage device, and a model storage device And a terminal device. The data storage device stores parameters used for creating the model. The tool storage device stores a tool used for creating a model. The model storage device stores model templates for a plurality of parts constituting the system.

  The terminal device includes communication means, input means, creation means, and output means. The communication means reads data from each storage device (data storage device, tool storage device, model storage device). The input means receives input from the user. The creation unit first reads out model templates of a plurality of parts from the model storage device in accordance with the instruction content input from the user via the input unit. Next, the creation means reads the parameter from the data storage device. At this time, the creation means reads out the parameter according to the instruction content input by the user. Next, the creating means creates a model of each part by assigning a parameter to the model template of the plurality of parts. Then, the creation unit reads out and executes the tool from the tool storage device, thereby creating a model of one system by combining a plurality of component models. The output means outputs the model data created by the creating means.

  In the model creation support system of the present invention configured as described above, parameters, model templates, tools, and the like used in simulations in the past system design are accumulated in each storage device. When creating a new system model, the user can easily use the data stored in each storage device by using the terminal device. Therefore, the user can shorten the development period and improve the work efficiency by reusing these accumulated data.

  The model storage device of the model creation support system in the present invention may be configured to further store a ready-made model created in the past. In this case, when the application of the ready model is instructed by the user, the terminal device reads the corresponding ready model from the model storage device, and creates a system model using the ready model.

  In the model creation support system of the present invention configured as described above, a model of a new system can be created by further reusing an existing model created in the past. When such a pre-built model is used, the user uses the part model (ie, the pre-made model) without performing a process of creating a new part model by selecting an appropriate parameter for the model template. System model. For this reason, the development period can be further shortened and the work efficiency can be further improved.

  The model storage device of the model creation support system in the present invention may be configured to store a plurality of model templates with different accuracy for each part. In the model creation support system of the present invention configured as described above, the user can select an appropriate model template for each component according to the accuracy required in the simulation to be executed.

  The model creation support system according to the present invention may be configured to further include a project storage device that stores detailed data related to past projects and projects currently in progress. In this case, the terminal device further includes display means for performing screen display. When the user is instructed to read out information about a past project or a project that is currently in progress, the terminal device responds. The information of the project to be read may be read and displayed on the display means.

The model creation support system according to the present invention may be configured to further include a document storage device that stores a document related to each model. In this case, the terminal device further includes display means for performing screen display. When the user instructs to read a document related to each model stored in the model device, the terminal device relates to the corresponding model from the document storage device. The document may be read and displayed on the display means.

  The model creation support system according to the present invention may be configured to further include a parts storage device that stores a list of parts and engines that are actually created and stored in a warehouse. In this case, the terminal device further includes display means for performing screen display, and search means for searching for a desired part from a list stored in the parts storage device when a search for the desired part is instructed by the user, When the search result is obtained, the search result may be displayed on the display means.

  The present invention may be an ordering support system including a plurality of the model creation support systems described above. In this case, a part or all of the data storage device, the tool storage device, and the model storage device may be shared by different model creation support systems.

  In the order support system of the present invention configured as described above, the above-described model creation support system is installed at the order source and the order destination. A part or all of the data storage device, the tool storage device, and the model storage means are shared and can be accessed from the terminal devices at the ordering source and the ordering destination. For this reason, since it is possible to perform a simulation using data common to the ordering party or the ordering party, it is possible to perform a simulation of a product to be ordered in the same environment. For this reason, the accuracy and efficiency of simulation can be improved. Further, even when the contents of each storage device are changed, it is not necessary for both sides to exchange data for the data in the shared storage device. For this reason, work efficiency can be further improved.

  The configurations described above can be combined as much as possible. The present invention may also be realized by executing a program by an information processing apparatus. That is, the present invention can specify the processing executed by each means described above as a program for causing the information processing apparatus to execute, or a recording medium on which the program is recorded. Further, the present invention may be specified by a method in which the information processing apparatus executes the processing executed by each of the above-described means.

  ADVANTAGE OF THE INVENTION According to this invention, it becomes possible to shorten a development period and to improve work efficiency by improving the reusability of the information regarding the components etc. which were accumulate | stored in vehicle development.

[System configuration]
The model creation support system 1 according to the present invention creates model data to be used for simulations performed when developing parts and systems for automobiles. Hereinafter, a configuration example of the model creation support system 1 according to the present invention will be described. FIG. 1 is a diagram showing an example of a system configuration of a model creation support system 1 according to the present invention. The model creation support system 1 includes a data repository 10, a project repository 20, a document repository 30, a tool repository 40, a model repository 50, and a parts repository ( Parts Repository) 60 and terminal device 70. Each of the repositories 10 to 60 is configured using a nonvolatile storage device such as a hard disk, and stores the contents of each database (Database: DB). Moreover, each repository 10-60 is connected so that communication with the terminal device 70 is possible. The user can refer to the data stored in the repositories 10 to 60 by operating the terminal device 70. Hereinafter, each component included in the model creation support system 1 will be described. In FIG. 1, the diagram showing each database describes the contents of data stored in the database.

[Data repository]
The data repository 10 manages data necessary for model creation and input data necessary for model verification. The data repository 10 includes a parts parameter database (Parts / Parameters DB) 11, a unit data type database (Units / Data Types DB) 12, and a signal trajectory database (Signal Trajectories DB) 13.

  The parts parameter database 11 stores a combination of parameters required for each part used in the automobile. For example, when accumulating parameters for a plurality of types of engines, the parts parameter database 11 stores a plurality of parameters such as bore, stroke, and number of cylinders as parameters unique to each engine.

  The unit data type database 12 stores unit systems used in each model, physical constants (for example, the molecular weight of air), and their sources. If the unit system and the physical constant are defined differently for each user, problems occur in the quality of the product and the accuracy of the simulation. Further, the unit data type database 12 stores evaluation results (for example, temperature, pressure, gas flow rate, etc. of each part of the engine) for each component measured in various states (steady state, transient state, etc.).

  The signal trajectory database 13 stores model input data (input signal: for example, throttle operation pattern) used when verifying the accuracy of the model or comparing the phenomenon with the actual machine. By using the input data registered in this way at the time of verification or the like, the verification result for each component can be obtained in the same environment, and the accuracy of verification can be improved.

[Project Repository]
The project repository 20 manages detailed data related to past projects and projects currently in progress. The project repository 20 includes a project database (Projects DB) 21, a user / user group database (Users / User Groups DB) 22, and a project view database (Projects Views DB) 23.

  The project database 21 stores the schedule of each project plan, the department in charge, the company in charge, the person in charge, etc. as detailed data. The user can use the contents of the project database 21 as a reference when planning a new project.

  The user / user group database 22 stores, as detailed data, what model each responsible department, each responsible company, and each person in charge stored in the project database 21 uses.

  The project view database 23 stores, as detailed data, the actual progress results of past projects, the progress status of projects currently in progress, and the like. When a user plans a new project, the user compares the past plan accumulated in the project database 21 with the actual progress result accumulated in the project view database 23, so that the user can more easily match the current situation. It is possible to make no plans. For example, if the number of days set in the plan for a certain process deviates from the number of days actually required, it is possible to consider the setting of the number of days when planning a new project and set the optimal number of days. Become.

[Document Repository]
The document repository 30 manages documents regarding each model. The document repository 30 includes a document database (Documents DB) 31, an experiment database (Experiments DB) 32, and a script database (Scripts DB) 33.

  The document database 31 stores a manual for each model registered in the model repository 50. This manual is created by the creator (registrant) of each model and includes physical formulas included in each model, application examples of each model, and the like.

  The experiment database 32 stores knowledge and experience obtained when each model registered in the model repository 50 is used in the past, such as a result of comparing and examining the accuracy of the model with the actual machine. These knowledge and experience are registered not only by the creator of each model but also by those who use each model.

  The script database 33 stores a script for creating a new model by combining data accumulated in the model repository 50. When this script is executed by the user, it searches for necessary data from the model repository 50 based on the part model specified by the user, its parameters, and the like. Then, this script creates a new model desired by the user by combining the retrieved data.

[Tool repository]
The tool repository 40 manages various tools such as a modeling tool, an analysis tool, and an optimization tool. Since each tool is often designed according to the type of model, a tool that normally operates for a certain model does not always operate normally for another model. For this reason, a plurality of tools adapted to each of a plurality of types of models are required. Therefore, a plurality of tools corresponding to the model are managed in the tool repository even if the tools aim at the same operation.

  The tool repository 40 includes a calibration / identification tools database (Calibration / Identification Tools DB) 41, an analysis tools database (Analysis Tools DB) 42, a modeling tools database (Modeling Tools DB) 43, and a design optimization database. (Design / Optimization Tools DB) 44 is included.

  The calibration and identification tool database 41 stores a system identification tool. The system identification tool is a tool for performing system identification. That is, the system identification tool creates a mathematical model of a dynamic system based on input data to the system and output data from the system by being executed by the user.

  The analysis tool database 42 stores tools for analyzing experimental results and simulation results. Specific examples of tools stored in the analysis tool database 42 include a tool for displaying the numerical values obtained as experimental results and simulation results as a graph, and a tool for evaluating the difference between the actual machine and the model. .

The modeling tool database 43 stores modeling tools. The modeling tool is a tool for performing the same processing as the script stored in the script database 33. That is, the modeling tool searches for each data registered in the model repository 50 when a model or parameter is designated by the user, and creates a new system model by combining them.

  The design optimization database 44 stores optimization tools. This optimization tool is an optimization tool for matching undefined parameters in a model from actual machine data.

[Model repository]
The model repository 50 stores each model. The model repository 50 includes a model database (Models DB) 51, a model template database (Models DB) 52, a connector database (Connectors DB) 53, and a connector template database (Connector Templates DB) 54.

  FIG. 2 is a diagram illustrating an example of the model 51a, the model template 52a, and the connector 53a stored in the model repository. First, the model template 52a will be described. The model template 52a is data defining only input / output among the definitions required for the model. The user can define a plurality of specific models 51a, 51b, 51c and the like by combining specific physical formulas (formulas) and maps with the model template 52a. The models 51a, 51b, and 51c are data defined by combining specific mathematical formulas and maps with the model template 52a described above. In this way, different models can be created according to the mathematical formulas and map contents incorporated in each model. Therefore, it is possible to create models of various levels such as models incorporating mathematical expressions and maps having detailed contents closer to actual machines, and simple models incorporating only rough mathematical expressions.

  The connector 53a is data defining what kind of signal the model having this connector exchanges with what other model. For example, the connector 53a can be defined by determining the signal type and other models. One connector 53a can exchange a plurality of types of signals. The connector template indicates data of a connector in which only basic signals are defined. The user can easily define a specific connector 53a by giving the connector template a signal that is specifically required or another model that is a partner with which the signal is exchanged.

  In FIG. 2, a specific model 51a is defined by giving Formula 1 to a model template 52a (FIG. 2A) having four connectors 53a (FIG. 2B). Further, specific models 51b and 51c are respectively defined by giving Formulas 2 and 3 to such a model 51a (FIGS. 2C and 2D).

  Next, each database included in the model repository 50 will be described. The model database 51 stores a plurality of hierarchical models for various parts (throttle, air cleaner, intake manifold, etc.). In practice, it is possible to create a necessary model at any time by using a model template stored in the model template database 52. However, by accumulating specific model data used in the past in the model database 51, the user can bother to recreate the past model without the trouble of creating a model from the model template. It becomes possible to improve the efficiency of business.

The model template database 52 stores model template data of various parts. The connector database 53 stores connector data used in the past. As for the connector, as in the case of the model, it is possible to create the required connector at any time by using the connector template, but the past efficient connectors are accumulated to improve the efficiency of business. Therefore, in the model creation support system 1, the connector database 53 is provided in this way, and connector data is accumulated.

[Parts repository]
The parts repository 60 manages a list of parts and engines that are actually created and stored in a warehouse. In the warehouse, actually created engines and various parts are stored. The parts repository 60 stores management information (eg, management location, lending destination, creation date of each part, creation department / creation company / creator of each part) stored in the warehouse. When the user desires an experiment based on an actual part, the user can search the inventory of the desired part from the parts repository 60, and can easily obtain the desired part.

[Terminal device]
The terminal device 70 includes a CPU (central processing unit), a main storage device (RAM), an auxiliary storage device, and the like connected via a bus in terms of hardware. The auxiliary storage device is configured using a nonvolatile storage device. That is, the terminal device 70 is configured using an information processing device such as a PDA (Personal Digital Assistant), a personal computer, or a workstation. The terminal device 70 has a communication interface and is communicably connected to the repositories 10 to 60. When the terminal device 70 is input by a user using an input device (a keyboard, a pointing device, or the like) provided in the terminal device 70, each of the repositories 10 to 60 via the above-described communication according to the user input. To read, execute, and write necessary data.

[Operation example]
FIG. 3 is a flowchart showing an operation example when the user uses the model creation support system 1. The user first summarizes the specifications of the system to be developed. Next, the user uses the terminal device 70 to search the project repository 20 for a search for a project in which a similar system has been developed in the past. When a similar project can be searched, the user can read detailed data of the project from the project repository 20 and use the past detailed data as a reference when planning the current project. Then, the user determines a model necessary for the system to be developed (S01). Even when determining the model, the user examines and determines a necessary model (that is, a necessary part or model hierarchy) with reference to the contents stored in the user / user group database 22. be able to. Thereafter, the user registers project plan information (including project schedule information and system performance requirements) including information on the determined model in the project repository 20.

  Next, the user determines a part model necessary for creating the model determined in S01. The user reads out the model data of each determined part from the model repository 50. At this time, when the data of the desired model is not stored in the model database 51, the user reads out the model template from the model template database 52 and gives a physical formula or a map to the model template. A new model may be created (S02). At this time, the user can read out the contents of the manual managed in the document repository 30 by the management device 70 for reference when determining the required physical formula or map.

  Next, the user obtains a tool adapted to each created model from the tool repository 40. Then, a model of the system is assembled using the model and tools (particularly modeling tools) (S03).

FIG. 4 is a diagram schematically showing the processes in S02 and S03. User is S02
In this processing, each model managed at a plurality of levels for a plurality of parts is selected from the model database 51. Then, in the process of S03, the user reads out and executes a modeling tool corresponding to each selected model from the modeling tool database 43, thereby creating one system model composed of a plurality of selected part models. To do. The user can verify the operation of the system model created in this way.

  Next, the user sets parameters such as specifications for each part model incorporated in the created system model (S04). At this time, the user can make settings using parameters managed in the part parameter database 11 of the data repository 10. Then, by using a tool such as an optimization tool managed by the tool repository 40, the user adjusts each parameter so that the system model shows the same behavior as the actual machine (S05). At this time, in the case of a completely new system model, there may be no actual data. Even in such a case, the user performs adjustment of each parameter using analysis results such as CAE (Computer Aided Engineering) and CFD (Computational Fluid Dynamics), and data of a real machine having a relatively close structure. be able to. When the parameter of each part model is changed, the user registers the changed point in the model repository 50, and registers the document indicating the changed content in the document repository 30 (S06).

  The user expands the system model thus completed to the person in charge (S07). At this time, the user or the person in charge registers the person who uses the model in the project repository 20. By performing such registration, it is possible to easily specify a partner to be contacted when the system model is changed in the future. Then, the user stores the parts used for modeling in the warehouse, and updates the management information about the stored parts in the parts repository 60 (S07).

[Action / Effect]
According to the model creation support system 1 configured in this way, the user can easily reuse a past model, so that the model can be created efficiently and the development period can be shortened. be able to. For example, since it is possible to use the data of a specific model in the past managed in the model repository 50, the user does not need to newly create model data from scratch each time. For this reason, work efficiency can be improved and the development period can be shortened.

  Further, for example, by using each data managed in the document repository 30, the user can easily obtain the explanation about the data of each model and the past knowledge and experience. For this reason, the past model can be reused smoothly, and the same failure or the like made in the past can be effectively prevented.

[Application example]
The model creation support system 1 according to the present invention can be used as a stand-alone system by a developing user, so that reusability of information related to parts and the like accumulated in the development of an automobile can be improved, and the development period can be shortened. Efficiency can be improved. However, the model creation support system 1 according to the present invention is installed in both the automobile company (OEM) and the supplier, and all or part of the repository is shared, thereby further shortening the development period and improving the work efficiency. It becomes possible to plan. FIG. 5 is a diagram illustrating a system configuration example in a case where a part or all of the repository of the model creation support system 1 is shared between the OEM 80 and a plurality of suppliers 90 (90a, 90b, 90c). The model creation support system 1 installed in the OEM 80 and the supplier 90 is configured to be able to communicate with each other. The data stored in each repository is shared via the network. For example, the repository data of the model creation support system 1 installed in the supplier 90 can be read by the terminal device 70 of the model creation support system 1 installed in the OEM 80.

  Hereinafter, application examples of the model creation support system 1 will be described. The following model creation support system 1 will be described as a configuration that does not include the parts repository 60.

[First application example]
FIG. 6 is a conceptual diagram when the model creation support system 1 is installed in both the OEM 80 and the supplier 90 without sharing any repository. On the other hand, FIG. 7 is a conceptual diagram when the model creation support system 1 is installed in both the OEM 80 and the supplier 90 so as to share the data repository 10. In this case, model development is performed independently by the OEM 80 and the supplier 90, but data necessary for model creation and input data necessary for model verification are shared. For this reason, it is possible to prevent the OEM 80 and the supplier 90 from overlapping each other and perform measurement on the same data, thereby improving work efficiency.

  In general, the supplier 90 can use the data of the entire shared system as a boundary condition for the simulation even when the company 90 simulates its own product.

[Second application example]
FIG. 8 is a conceptual diagram when the model creation support system 1 is installed in both the OEM 80 and the supplier 90 so as to share the project repository 20. In this case, when proceeding with a certain project, it is possible to share the required performance and schedule in that project. It may be configured such that the role assignment assigned to both can be referred to by both terminal devices 70.

  By applying the model creation support system 1 in this way, the OEM 80 and the supplier 90 can easily perform development in cooperation. Specifically, for example, it is possible to accurately grasp the progress status of both parties, and it is possible to improve work efficiency. Moreover, the same effect can be produced by clarifying both roles.

[Third application example]
FIG. 9 is a conceptual diagram when the model creation support system 1 is installed in both the OEM 80 and the supplier 90 so as to share the document repository 30. In this case, a document created by the OEM 80 and a document created by the supplier 90 (such as a model manual) are shared.

  Normally, if the execution environment and the tools used are different in each company (OEM 80 and supplier 90), it is not possible to share the model immediately. However, by applying the model creation support system 1 in this way, it is possible to efficiently share a model by referring to a document shared by both parties.

[Fourth application example]
FIG. 10 is a conceptual diagram in the case where the model creation support system 1 is installed in both the OEM 80 and the supplier 90 so as to share the tool repository 40. In such an application example, when it is necessary to improve or enhance the functions of the shared tool, the OEM 80 and the supplier 90 can efficiently improve the shared tool by using it in both environments. Etc. can be performed. At that time, it is possible to efficiently perform processing even when setting priorities or determining requests from tool makers. In addition, when trying a new tool, it is possible to share benchmarks and evaluations between the OEM 80 and the supplier 90, thereby improving efficiency.

[Fifth application example]
FIG. 11 is a conceptual diagram in the case where the model creation support system 1 is installed in both the OEM 80 and the supplier 90 so as to share the model repository 50. In this case, the supplier 90 models an actuator or the like developed in-house, and registers the data of this model in the model repository 50. The OEM 80 creates a model of the entire system using the model registered by the supplier 90, and provides this model to the supplier 90. The supplier 90 can perform simulation of the entire system using the model of the entire system provided from the OEM 80. For this reason, compared with the case where the supplier 90 performs a simulation using only its own model, it is possible to improve the performance and improve the efficiency of business by performing the simulation of the entire system.

  Further, the OEM 80 provides a desired model to the supplier 90 via the shared model repository 50, thereby making clear and easy specific consultation such as "Can such an actuator be possible?" It becomes possible.

  Further, in any one of the OEM 80 and the supplier 90, when the model includes know-how that is not desired to be disclosed to the other, the mask 80 or the like may be concealed. For example, instead of being configured so that both models can access all models stored in the shared model repository 50, it is possible to conceal data such that access is restricted for certain models. May be. Such concealment may be performed by a password, an ID, or the like.

  In consideration of the convenience of using the shared model, it is desirable to use predetermined common input / output and basic templates for each model.

  By applying the model creation support system 1 in this way, it is possible to share the creation of a model between the OEM 80 and the supplier 90 and to be responsible for creating a model that each is good at. For this reason, it becomes possible to improve the efficiency of work. Further, by combining the models that the OEM 80 and the supplier 90 have, it is possible to construct a new model that could not be constructed so far. In addition, by enabling the supplier 90 to use the OEM 80 model without permission, a simulation using the OEM 80 model can be performed in advance before making a transaction with the OEM 80. As a result, it is possible to obtain a simulation result in the OEM 80 model before making a transaction with the OEM 80, and therefore, the supplier 90 can make a transaction only with a model that has obtained a good result or examine the model. Is possible.

[Sixth application example]
FIG. 12 is a conceptual diagram when the model creation support system 1 is installed in both the OEM 80 and the supplier 90 in a form in which the data repository 10, the project repository 20, the document repository 30, the tool repository 40, and the model repository 50 are shared. It is. In this case, all models, documents, etc. developed by each company (that is, each OEM 80 and each supplier 90) are basically shared. If necessary, the predetermined data may be configured so as to keep confidentiality and not be read from the other company. Also, when there are a plurality of suppliers 90, one supplier 90 can be used but other suppliers 90 can be used.
May be configured such that a usage restriction that cannot be used can be provided.

  In the model creation support system 1 of the present invention configured as described above, since the data repository 10 and the model repository 50 are shared, the OEM 80 is most suitable for a system in which the product of any supplier 90 is designed by the company. It is possible to easily evaluate whether there is any.

  Further, since the document repository 30, the tool repository 40, and the model repository 50 are shared, the supplier 90 can perform the simulation of the in-house model using the OEM 80 model, tool, or the like without requesting the OEM 80. For this reason, the supplier 90 can perform a simulation of its own model in the environment of the OEM 80 without requesting the OEM 80, and can manufacture a product that meets the requirements of the OEM 80. In addition, it is possible to obtain high quality from the beginning with respect to the quality of prototypes and products delivered to the OEM 80.

  In addition, since simulation using an OEM 80 model can be performed before evaluation using an actual machine, the supplier 90 can omit design, trial manufacture, and evaluation.

  Further, by sharing the project repository 20, the supplier 90 can grasp the progress of the project in the OEM 80 and develop a product by estimating what product the OEM 80 will request in the future. It becomes possible.

[Operation example in application example]
FIG. 13 is a flowchart showing an operation example when a user performs development using the model creation support system 1 (particularly in the case of the sixth application example) configured as shown in FIG. First, design requirements (performance and properties of the design target, etc.) are summarized, and a schedule for the design, a department in charge, a company in charge, and a person in charge are defined. At this time, the user can refer to the past project definition contents stored in the project repository 20 and define a new project with reference to these contents. At this time, the process of S01 in FIG. 3 is also performed. Then, the contents are registered in the project repository 20 (S11). A person in charge or a person in charge can grasp the progress of the entire project at any time by referring to the shared project repository 20.

  Next, the user performs an operation of specifically dropping the defined design requirements into the system, parts, and control contents necessary to achieve the requirements (S12). Then, the user registers the result of the drop in the data repository 10.

  Next, the user creates a part model or a system model using the part model based on the result obtained in S12, and prepares for simulation (S13). At this time, the user can create a new system model based on the models and model templates stored in the model repository 50. In addition, a unique parameter is required inside the model to match the behavior of the actual machine. Such parameters can be acquired from the data repository 10 or the like.

  Next, the operation and accuracy of the system model created in the process of S13 are verified (S14). At this time, an input signal for testing is required for the verification (particularly verification of the transient characteristics). Such an input signal can be acquired from the data repository 10. When a change occurs in the model as a result of such verification, the user reflects the content in the model repository 50.

Hereinafter, the flow of hardware design (S15) and the flow of control logic design (S16) will be described. When these processes are performed by simulation using a model, both processes can be performed in parallel.

  First, hardware design will be described. FIG. 14 is a flowchart showing the flow of hardware design processing. First, the user estimates whether or not the hardware performance can be achieved as required by performing a simulation using the created system model (S21). If there is no estimate that the request can be achieved (S22-NO), the user creates a new system model by performing the processing after S12 again. At this time, the user may register the contents of the failed system model and the verification result thereof in the model repository 50 or the document repository 30.

  On the other hand, when an estimate that the request can be achieved is obtained (S22-YES), a hardware prototype is executed (S23). At this time, when the user requests the supplier to make a prototype of the hardware, the result of the simulation so far, the data of the system model, and the like are also given to the supplier. At this time, since the model repository 50, the document repository 30, and the like are shared, such data exchange is easily realized between the supplier and the user (for example, OEM).

  The supplier further verifies the operation of the system using the prototyped parts (unit evaluation: S24). At this time, the supplier can obtain the contents of the system model that has already been verified as hardware that can already be realized on the OEM side. Therefore, it is verified whether or not the actual prototype manufactured satisfies the requirements of the OEM. Can be easily implemented.

  When it is concluded that it is better to correct the model in the single evaluation of the prototype (S25-YES), the newly created model is registered in the model repository 50 (S26). Further, since the OEM can immediately consult with the supplier about the correction point using the data of the shared repository, the efficiency of the work can be improved. On the other hand, when the conclusion that the model review is unnecessary is obtained (S25-NO), the hardware design is finished.

  Next, control logic design will be described. FIG. 15 is a flowchart of control logic design. First, in a terminal device 70 used by a person in charge of developing control logic, a simulation tool necessary for operating a system model is read from the tool repository 40. Similarly, in the terminal device 70, the system model created in S14 is read from the model repository 50. Through such processing, the terminal device 70 prepares an environment for evaluating the system model (S31).

  Next, the user performs logic development using the environment created in S31 (S32). This work is conventionally performed with a control logic for an actual machine. On the other hand, when the development support system 1 according to the present invention is used, the work is performed by simulation in the terminal device 70. Next, the user evaluates whether or not the required performance can be achieved for the control logic thus created (S33). When it is difficult to achieve the required performance (S33-NO), the user creates a new system model by performing the processing after S12 again.

Next, when it is evaluated in S33 that the required performance can be achieved (S33-YES), the ECU is mounted (S34). This operation is usually performed at the supplier. That is, the specifications required for such mounting are delivered to the supplier. At this time, it is desirable that the model used in the simulation, the input conditions, the result, and the like are passed to the supplier via each shared repository. Thus, each data is handed over to the supplier, and it is possible to specifically request the supplier to deliver an ECU that has obtained the same result as the evaluation result obtained in the simulation. At this time, it is possible to request the supplier to deliver the evaluation result executed by the supplier together with the ECU. In this case, the supplier can avoid in advance a situation in which the required performance cannot be obtained because the ECU is evaluated again at the delivery destination (for example, OEM) after delivery.

  Then, the user who is the delivery destination of the ECU debugs whether the operation is correct or not by using HILS (Hardware In the Loop Simulation) etc. for the delivered ECU (S35). At this time, the user can efficiently debug using each tool managed in the tool repository 40.

  Returning to the description with reference to FIG. When the hardware design (S15) and the control logic design (S16) are completed, the user performs system evaluation combining hardware and control in the actual machine (S17). This evaluation result is accumulated in the data repository 10 and the document repository 30. These accumulated evaluation results will be used effectively in future project planning.

[Modification]
When the user of the model creation support system 1 is a person who is familiar with each model stored in the model repository 50, the document stored in the document repository 30 is often unnecessary for such a user. Therefore, when such a user is assumed, the model creation support system 1 according to the present invention may be configured not to include the document repository 30.

  In addition, when the user of the model creation support system 1 is a person who is familiar with each component and automobile development project, the information stored in the project repository 20 is often unnecessary for such a user. Therefore, when such a user is assumed, the model creation support system 1 according to the present invention may be configured not to include the project repository 20.

  For the reason described above, the model creation support system 1 may be configured using the data repository 10, the tool repository 40, the model repository 50, and the terminal device 70 as a minimum configuration. However, in this case, it is desirable that the user of the model creation support system 1 is familiar with each model stored in the model repository 50 and is familiar with each part and vehicle development project. .

  In each application example, when there is a subcontractor 100 (100a, 100b, 100c) for the supplier 90, the supplier 90 and the subcontractor 100 have the same relationship as the relationship between the OEM 80 and the supplier 90 described above. A model creation support system 1 that shares part or all of the above may be constructed.

It is a figure which shows the example of the system configuration | structure of a model creation assistance system. It is a figure which shows the example of the model memorize | stored in a model repository, a model template, and a connector. It is a flowchart which shows the operation example at the time of a user using a model creation assistance system. It is a figure which shows typically the process which selects the model of components, and the process which produces a system model. It is a figure which shows the system configuration example in the case of sharing some repositories in a model creation assistance system. It is a conceptual diagram of the model creation assistance system when not sharing a repository at all. It is a conceptual diagram of the model creation assistance system in the case of sharing a data repository. It is a conceptual diagram of the model creation assistance system in the case of sharing a project repository. It is a conceptual diagram of the model creation assistance system in the case of sharing a document repository. It is a conceptual diagram of the model creation assistance system in the case of sharing a tool repository. It is a conceptual diagram of the model creation assistance system in the case of sharing a model repository. It is a conceptual diagram of a model creation support system when sharing a data repository, a project repository, a document repository, a tool repository, and a model repository. It is a flowchart which shows the operation example at the time of a user developing using a model creation assistance system. It is a flowchart which shows the example of the flow of a process of hardware design. It is a flowchart which shows the example of the flow of a process of control logic design.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Development system 10 Data repository 11 Parts parameter database 12 Unit data type database 13 Signal trajectory database 20 Project repository 21 Project database 22 User and user group database 23 Project view database 30 Document repository 31 Document database 32 Experiment database 33 Script database 40 Tool repository 41 Calibration and identification tool database 42 Analysis tool database 43 Modeling tool database 44 Design optimization database 50 Model repository 51 Connector template database 52 Connector database 53 Model database 54 Model template database 60 Parts repository 70 Terminal device 80 OEM
90 Supplier 100 Subcontractor

Claims (8)

A model creation support system for creating model data of the system used when simulating a system used in an automobile,
A data storage device for storing parameters used to create the model;
A tool storage device for storing a tool used to create the model;
A model storage device for storing model templates for a plurality of parts constituting the system;
A communication unit that reads data from each storage device, an input unit that receives an input from a user, and a model template of a plurality of parts from the model storage device according to the content of an instruction input from the user via the input unit By reading a parameter from the data storage device, creating a model of each part by assigning a parameter to the model template of the plurality of parts, and reading and executing a tool from the tool storage device. A terminal device including: a creating unit that creates a model of one system by combining models of parts; and an output unit that outputs data of the model created by the creating unit;
Model creation support system including The model storage device further stores a pre-made model created in the past,
The terminal device according to claim 1, wherein when the application of the ready model is instructed by a user, the terminal device reads a corresponding ready model from the model storage device and creates a model of the system using the ready model. Model creation support system.   The model creation support system according to claim 1, wherein the model storage device stores a plurality of model templates with different accuracy for each part. A project storage device for storing detailed data on past projects and projects currently in progress is further provided.
The terminal device further includes display means for performing screen display,
The terminal device reads out information on a corresponding project from the project storage device and displays the information on a display unit when an instruction is given to read out information about a past project or a project currently in progress by the user. Item 4. The model creation support system according to any one of Items 1 to 3. A document storage device for storing a document related to each model;
The terminal device further includes display means for performing screen display,
2. The terminal device reads out a document related to a corresponding model from the document storage device and displays it on a display unit when an instruction is given to read out a document related to each model stored in the model device by a user. The model creation support system according to any one of? A part storage device that stores a list of parts and engines actually created and stored in the warehouse is further provided.
The terminal device further includes display means for displaying a screen, and search means for searching for a desired part from a list stored in the parts storage device when a search for a desired part is instructed by a user,
The model creation support system according to claim 1, wherein the terminal device displays the search result on the display unit when the search result is obtained. A model creation support system for creating model data of the system used when simulating a system used in an automobile,
A data storage device for storing parameters used to create the model;
A tool storage device for storing a tool used to create the model;
A model storage device for storing model templates for a plurality of parts constituting the system;
A project storage device that stores detailed data about past projects and projects currently in progress;
A document storage device for storing documents relating to each model;
A parts storage device that stores a list of parts and engines that are actually created and stored in the warehouse;
The model storage according to the communication means for reading data from each storage device, the input means for accepting input from the user, the display means for performing screen display, and the instruction content input from the user via the input means A model template of a plurality of parts is read from the device, a parameter is read from the data storage device, a model of each component is created by assigning a parameter to the model template of the plurality of components, and a tool is read from the tool storage device To create a model of one system by combining the models of the plurality of parts, an output means for outputting the model data created by the creating means, and a user of a desired part When a search is instructed, a desired list is stored in the parts storage device. Includes search means for searching for goods, and a terminal device including,
When the terminal device is instructed to read information about a past project or a project currently in progress by the user, the corresponding project information is read from the project storage device and displayed on the display means.
When the terminal is instructed by the user to read out the document related to each model stored in the model device, the terminal device reads out the document related to the corresponding model from the document storage device and displays it on the display means.
The terminal device is a model creation support system for displaying a search result on the display means when the search result is obtained. An ordering support system including a plurality of model creation support systems according to any one of claims 1 to 7,
An ordering support system in which some or all of the data storage device, tool storage device, and model storage device are shared by different model creation support systems.

Images