Design support system, design support program, and recording medium with design support program recorded

Abstract

To make a meta model as a use destination meta model to be easily used by various systems with the meta model designed by certain system development as a reference source meta model.SOLUTION: A design support system updates a use destination data structure while making a reference source data structure unupdated when a use destination meta model uses a reference source meta model. Since the reference source data structure is made unupdated, the reference source meta model is maintained without changing a content even though the reference source meta model is used. Meanwhile, since the use destination data structure is updated, the use destination meta model can be created again with an updated content. For example, when the reference source meta model is upgraded, the updated use destination data structure can be applied to an upgraded reference source meta model.SELECTED DRAWING: Figure 18

Description

[Technical Field]

[0001] The present disclosure relates to a design support system that can be used in the design of multiple systems, such as an automobile driving support system, a cockpit module system, and an engine control system, and also to a design support program for causing a computer to realize the design support, and a recording medium having recorded thereon the design support program for causing a computer to realize the design support. [Background technology]

[0002] Patent Document 1 describes a development support system that defines a metamodel using metaclasses, allowing the definition of the metamodel and the metaclasses that make up the metamodel to be freely changed without being bound by predetermined rules. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6847381 Summary of the Invention [Problem to be solved by the invention]

[0004] The design support system described in Patent Document 1 can be used for the development of large-scale systems, but is premised on the development of a single system. For example, in the development of an automobile driving assistance system, multiple metamodels used in the driving assistance system can be used. Even if an inconsistency occurs in the metamodels used, the use itself is permitted, and the occurrence of the inconsistency is simply displayed.

[0005] By viewing the display of inconsistencies, designers developing driver assistance systems can easily find metamodels that need to be corrected. By correcting these inconsistencies, automated driving system development can be easily achieved. In this way, the technology described in Patent Document 1 facilitates system development, and is premised on correcting inconsistencies when they are found.

[0006] The design support system described in Patent Document 1 is effective for developing a single system such as a driving assistance system. However, in recent years, there has been an increasing number of cases in which multiple systems are interrelated in the development of automobiles, for example. Rather than being completed within the driving assistance system, the design results and metamodels used in the driving assistance system are often used in the development of other systems, such as engine control systems and cockpit module systems that control meters and switches.

[0007] Thus, when using a metamodel designed in one system development in another system development, simply correcting inconsistencies when they are found is insufficient. This is because the metamodel designed in a specific system development often does not have inconsistencies in that system development, and further functional improvements are often made. Therefore, simply correcting the metamodel inconsistencies in the other system development makes it difficult to use subsequent functional improvements made in the original system development in the other system development.

[0008] The present disclosure has been made in consideration of the above points, and aims to make it easier to use a metamodel designed in the development of an original system as a reference metamodel and to use that metamodel as a destination metamodel in various systems. [Means for solving the problem]

[0009] The present disclosure relates to a design support system that supports design. The design support system defines a reference metamodel by one or more reference metaclasses, and the reference metamodel has a reference data structure. The reference data structure includes reference name information indicating the name of the reference metamodel, reference version information indicating the version of the reference metamodel, and reference metaclass information indicating the contents of the reference metaclass.

[0010] The design support system of the present disclosure defines a user metamodel using one or more user metaclasses, and the user metamodel can use a reference metamodel, and the user metamodel has a user data structure. The user data structure includes user name information indicating the name of the user metamodel, user version information indicating the version of the user metamodel, user metaclass information indicating the relationship between the user metaclass and the reference metaclass, and change point information indicating the change points between the user metaclass and the reference metaclass.

[0011] In the design support system of the present disclosure, when a user metamodel uses a referencing metamodel, the user data structure is updated while the referencing data structure remains unchanged. In the design support system of the present disclosure, the referencing data structure remains unchanged, so there is no impact on the referencing metamodel. In other words, even when the referencing metamodel is used, the referencing metamodel's contents are maintained as they are. On the other hand, in the design support system of the present disclosure, the user data structure is updated, so the user metamodel can be created again with the updated contents. For example, if the referencing metamodel is upgraded, the user data structure can be applied to the upgraded referencing metamodel.

[0012] The present disclosure also includes a design support program for causing a computer to realize the above design support, and a computer-readable recording medium having recorded thereon the design support program for causing a computer to realize the above design support. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is an explanatory diagram showing the development procedure for system development. [Figure 2] FIG. 2 is an explanatory diagram showing a metamodel. [Figure 3] FIG. 3 is an explanatory diagram showing an example of system development. [Figure 4] FIG. 4 is an explanatory diagram showing another example of system development. [Figure 5] FIG. 5 is an explanatory diagram showing a referencing metamodel. [Figure 6] FIG. 6 is an explanatory diagram showing a user metamodel. [Figure 7] FIG. 7 is an explanatory diagram showing the structure of the destination data. [Figure 8] FIG. 8 is an explanatory diagram showing the referencing metamodel after the version change. [Figure 9] FIG. 9 is an explanatory diagram showing a comparative example of a reference source metamodel after a version change. [Figure 10] FIG. 10 is an explanatory diagram showing the referencing data structure. [Figure 11] FIG. 11 is an explanatory diagram showing an example of system development. [Figure 12] FIG. 12 is an explanatory diagram showing the system development shown in FIG. 11 in the form of a table. [Figure 13] FIG. 13 is an explanatory diagram showing a metamodel of an ADAS system. [Figure 14] FIG. 14 is an explanatory diagram showing the metamodel of the cockpit module. [Figure 15] FIG. 15 is an explanatory diagram showing a metamodel of an ADAS system in which the metaclass of the cockpit module shown in FIG. 14 is incorporated into the metamodel of the ADAS system shown in FIG. [Figure 16] FIG. 16 is an explanatory diagram of a metamodel showing a version change of the ADAS system shown in FIG. [Figure 17]FIG. 17 is an explanatory diagram showing a metamodel in which the version change shown in FIG. 16 is incorporated into the ADAS system shown in FIG. [Figure 18] FIG. 18 is an explanatory diagram showing a referencing metamodel, a using metamodel, and a using data structure. [Figure 19A] FIG. 19A is an explanatory diagram showing how a destination metaclass of a destination data structure is structured. [Figure 19B] FIG. 19B is an explanatory diagram showing change point information of the destination data structure. [Figure 20A] FIG. 20A is an explanatory diagram showing an example of a view. [Figure 20B] FIG. 20B is an explanatory diagram showing another example of a view. [Figure 20C] FIG. 20C is an explanatory diagram showing another example of a view. [Figure 20D] FIG. 20D is an explanatory diagram showing another example of a view. DETAILED DESCRIPTION OF THE INVENTION

[0014] The design support system 1 in this specification may also be referred to as an electronic control unit (ECU). The control unit or the design support system 1 is provided by (a) an algorithm in the form of multiple logics called an if-then-else format, or (b) an algorithm in the form of a trained model tuned by machine learning, for example, a neural network.

[0015] The control device or design support system 1 is provided by a control system including at least one computer. The control system may include multiple computers linked by data communication devices. The computer includes at least one processor that is hardware (a hardware processor). The hardware processor can be provided by the following (i), (ii), or (iii):

[0016] (i) A hardware processor may be at least one processor core that executes a program stored in at least one memory. In this case, a computer is provided with at least one memory and at least one processor core. The processor core is called a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a RISC-CPU, etc. Memory is also called a storage medium. Memory is a non-transitory, tangible storage medium that non-temporarily stores "programs and / or data" that can be read by a processor. Storage media are provided by semiconductor memory, magnetic disks, optical disks, etc. Programs may be distributed independently or as storage media on which the programs are stored.

[0017] (ii) A hardware processor may be a hardware logic circuit. In this case, a computer is provided by a digital circuit including a large number of programmed logic units (gate circuits). The digital circuit is also called a logic circuit array, for example, ASIC: Application-Specific Integrated Circuit, FPGA: Field Programmable Gate Array, SoC: System on a Chip, PGA: Programmable Gate Array, CPLD: Complex Programmable Logic Device, etc. The digital circuit may include a memory that stores programs and / or data. A computer may be provided by an analog circuit. A computer may be provided by a combination of digital and analog circuits.

[0018] (iii) The hardware processor may be a combination of (i) and (ii) above. (i) and (ii) may be located on different chips or on a common chip. In these cases, the part (ii) is also called an accelerator.

[0019] First, the flow of system development supported by the design support system 1 of the present disclosure will be described. A general system development flow will be described using the example of an ADAS system that provides driving support for automobiles. The main steps are as follows: first, system development 100 is performed, and then software development 200 adapted to that system is performed.

[0020] As shown in Figure 1, system development 100 begins with requirements definition 110. Requirements definition 110 sets development goals, such as determining that an ADAS system will be designed to assist driving through lane keeping and following driving. Next comes logical design 120, which defines functions and determines inputs and outputs. In an ADAS system, inputs include driver requests, vehicle driving status, and road conditions, including whether there is traffic congestion. Outputs include control items that determine what control will be performed, such as the degree of acceleration, braking, and steering.

[0021] System development 100 then proceeds to control design 130. Control design 130 is circuit design, which determines what calculation formulas will be used for each control. For example, how vehicle speed and obstacle detection will be performed will be determined. Obstacle detection can be performed using signals from laser sensors, or by obtaining information from traffic infrastructure or car navigation systems. After that, physical design 140 is performed. Physical design 140 is literally a design that determines which ECU will physically allocate control. For example, the role of vehicle speed detection can be divided between whether it will be calculated by the sensor ECU or the engine control ECU.

[0022] Software development 200 is the development that translates the outline defined in system development 100 into concrete software. First, software specification definition 210 is defined. If the vehicle speed detection function is assumed to be handled by the engine control ECU in physical design 140, more specific details of the engine control ECU are defined in software specification definition 210. Next, software basic design 220 is performed. In software basic design 220, each function defined in system development 100 is divided into multiple layers, and the inputs and outputs for each function are defined. It is also determined how to check for any problems between the inputs and outputs. This is followed by software detailed design 230. Software detailed design summarizes the specific calculation methods in flowcharts or the like, allowing them to be written in a programming language. This software detailed design 230 determines the program source code.

[0023] In both system development 100 and software development 200, if the design content is expressed from a different perspective, a logical formula 10 is determined, layout design 20 is performed to determine how it will be physically arranged, and then the implementation process 30 of specifically implementing it on the ECU is repeated.

[0024] The above explanation describes the design procedure of top-down development, in which the details are gradually refined from the top-level process of requirements definition 110 to the lower-level processes. However, this design procedure allows for a consistent design from the top down, as the design content is subdivided as the process progresses. However, this requires a complete understanding of the entire system, which makes it extremely difficult for large-scale, complex systems. In other words, system development cannot proceed unless it has progressed to a certain level of detail.

[0025] Contrary to the explanation above, there is also a bottom-up development design method in which each individual part that makes up the system is first designed in detail, and then those parts are combined to develop the system. This is suitable for using existing parts that have already been developed, or for developing each part in parallel. However, there is a possibility that inconsistencies may arise with higher-level processes when combining the parts, or even between the parts themselves. Furthermore, while bottom-up development may result in the development of optimal parts, it may result in partial optimization rather than overall optimization.

[0026] The design support system 1 of this example can be applied to both top-down and bottom-up development due to its flexibility, which will be described later. However, whether top-down or bottom-up development is used, there are many definitions involved, from the requirements definition 110 that determines what kind of system to create to the software detailed design 230 that defines detailed control and creates specific flowcharts, etc., and these definitions must always be passed on without contradiction.

[0027] The design support system 1 of this example can handle the entire series of development design steps from the requirements definition 110 of the system development 100 to the software detailed design 230 of the software development 200. However, the design support tool of this example does not necessarily have to be used for all processes. Depending on the content of the development, it can be used, for example, only for the system development 100, or only for the process of the requirements definition 110 of the system development 100, or only for the process of the requirements definition 110 of the system development 100 and the software specification definition 210 of the software development 200.

[0028] The configuration adopted by the design support system 1 of this example is such that, in the development from the requirements definition 110 of the system development 100 to the software detailed design 230 of the software development 200 described above, the items to be designed are first represented as a metamodel 300, and the design is carried out based on the metamodel 300. Therefore, each process (requirements definition 110, logical design 120, control design 130, physical design 140, software specification definition 210, software basic design 220, and software detailed design 230) involves the formulation of a metamodel 300 that determines the direction of development, and the production of a design result based on the metamodel 300.

[0029] As shown in Figure 2, metamodel 300 specifies the relationship between metaclasses 330, which are elements that make up metamodel 300, by connecting them with lines. In the example of Figure 2, the line with a black square at the end connecting first metaclass 3301 and second metaclass 3302 represents possession 301, which specifies a hierarchical relationship, and indicates that second metaclass 3302, which is lower, is an element of first metaclass 3301, which is higher.

[0030] In the example of Figure 2, the arrow connecting the second metaclass 3302 and the third metaclass 3303 represents a reference 302, indicating that the content defined in the second metaclass 3302, such as a field, operates by referencing a field defined in the third metaclass. The reference 302 indicates that there is some kind of relationship between the data exchanged between the two metaclasses. For example, if the second metaclass 3302 is an input port, the input port of the second metaclass 3302 will have a reference 302 relationship to the data of the control logic element of the third metaclass 3303. The relationship between the second metaclass 3302 and the third metaclass 3303 does not need to be hierarchical, nor does it need to be in the same process. The input port of the second metaclass 3302 can also reference 302 the content of a control logic element designed in another process.

[0031] 2, the line with a white triangle at the end connecting third metaclass 3303 and fourth metaclass 3304 represents inheritance 303, and indicates that fourth metaclass 3304 is at the same level as third metaclass 3303, in other words, fourth metaclass 3304 is a type of third metaclass 3303. For example, if third metaclass 3303 is a control logic element and fourth metaclass 3304 is a waveform, this indicates that waveforms can be cited as a type of control logic element.

[0032] 2, the dashed lines represent derivations 304, which indicate relationships with other processes. For example, in each process of system development and software development 200, if a metaclass 330 of one process is connected to a metaclass 330 of another process by a derivation 304 relationship, this indicates that the metaclass 330 of the other process is defined based on the contents of the metaclass 330 of the one process. This derivation 304 is used as trace information, and by identifying the relationship of derivation 304 between the request source and the request destination, it becomes possible to trace design information across processes.

[0033] The design result is the concrete content of the metaclass 330. For example, if the metaclass 330 is an input port, the design result specifies the specific content of the input port by using three input ports, namely, the first input port, the second input port, and the third input port, and so on. Therefore, the design result based on one metaclass may have multiple components. The relationships between the components include owned 301 and referenced 302.

[0034] As described above, the design support system 1 of this embodiment is suitable for designing various types of system development. As shown in Fig. 3, the design support system 1 of the present disclosure can be widely used in an ADAS system 41 that supports automobile driving with lane keeping, following driving, etc., a cockpit module system 42 that controls various meters and operating devices of an automobile, an electronics system 43 that controls the engine and driving motor, etc. In the example of Fig. 3, the design support tool of this embodiment is used for the logical design 120 of the ADAS system 41. The design support tool is used for the requirements definition 110 of the cockpit module system 42, and for the logical design 120 and basic software design 220 of the electronics system 43.

[0035] In the design support system 1 of this embodiment, in the example of Fig. 3, when improvements are made to the cockpit module system 42, the cockpit module system 42 can be used as a base to create a cockpit A system. As the cockpit A system, for example, software to be used in the cockpit module system 42 can be developed. Similarly, the cockpit module system 42 can also be used as a base to create a cockpit B system. As the cockpit B system, for example, the logical design of the cockpit module system 42 can be easily improved.

[0036] However, in recent years, there has been an increasing need to abstract designs developed separately for multiple systems into components that can be used in other systems, as shown in Figure 4. For example, a requirements definition 110 designed in a cockpit module system 42 can be generalized as a requirements definition component A51. Similarly, a logical design 120 designed in an ADAS system 41 can be generalized as a logical design component A52, and a software basic design 220 designed in an electronics system 43 can be generalized as a software basic design component A53.

[0037] In addition, there is an increasing need to design and utilize cross-domains A61 and B62 that can be used for multiple systems in advance, as shown in Fig. 4. In the example of Fig. 4, cross-domain A61 is used for an ADAS system 41 and a cockpit module system 42. Another cross-domain B62 is used for the ADAS system 41 and an electronic system 43.

[0038] If components such as requirements definition components A51, logical design components A52, and software basic design 220, as well as cross domains such as cross domains A61 and cross domains B62, are stored as design assets in the core server, the designers of each system can use them to design their systems.The designers of each system can extract the necessary reference metamodel 300A from the core server and use the reference metamodel 300A as is as the usage metamodel 300B, or can make changes, additions, or deletions (customizations) to the reference metamodel 300A and use it as the usage metamodel 300B.

[0039] This concept of design assets will be explained using Figures 5 to 7. Figure 5 shows a referencing metamodel 300A. In this example, the referencing metamodel in metamodel 300 is labeled 300A, and the referencing metaclass in metaclass 330 is labeled 330A. In the example of Figure 5, the referencing metamodel 300A includes a referencing metaclass A 330A1, a referencing metaclass B 330A2, and a referencing metaclass C 330A3. The user metamodel 300B shown in Figure 6 uses this referencing metamodel 300A. In comparison with the referencing metamodel 300A, the user metamodel in metamodel 300 is labeled 300B, and the user metaclass in metaclass 330 is labeled 330B. The user metamodel 300B includes a user metaclass A 330B1, a user metaclass B 330B2, and a user metaclass D 330B4.

[0040] The user metamodel 300B uses the referenced metaclass A330A1 as is. This referenced metaclass 330B is the user metaclass A330B1. The user metamodel 300B also modifies the referenced metaclass B330A2 to create the referenced metaclass B330B2. The modification is an improvement to field b2. Note that a field is an element included in the metaclass 330. For example, if the metaclass is a user usage scenario US, the default setting condition PC, which is an example of that scenario, becomes a field. The user metamodel 300B deletes the referenced metaclass C330A3 from the referencing metamodel 300A and does not use it. Conversely, the user metamodel 300B adds a metaclass 330 that was not present in the referencing metamodel 300A, and uses a new user metaclass D330B4.

[0041] Figure 7 shows the user data structure 500 of this user metamodel 300B. The user data structure 500 includes user name information 501 and user version information 502 of the user metamodel 300B so that it can be identified as the data structure of the user metamodel 300B. The user metamodel 300B does not make any changes to the referencing data structure 550 (shown in Figure 10) of the referencing metamodel 300A.

[0042] Instead, the user data structure 500 of the user metamodel 300B includes user metaclass information 510. The user metaclass information 510 includes referencing metaclass presence / absence information 503 indicating whether the metaclass 330 of the referencing metamodel 300A is being used. The user metaclass information 510 also includes invalidation information 504 indicating whether the available referencing metaclass 330A is valid or invalid.

[0043] In the examples of Figures 5 and 6, the presence / absence information 503 of the use meta class A330B1 for the referencing meta class A330A1 is "Yes" and the invalidity information 504 is "F." When the presence / absence information 503 is "Yes," the referencing meta class 330A is identified using its ID, as will be described in detail later using Figure 19A. Furthermore, the invalidity information 504 being "F" indicates that the use meta class A330B1 has not invalidated the referencing meta class A330A1, i.e., it is using it. Similarly, the presence / absence information 503 of the use meta class B330B2 is "Yes," identifying the referencing meta class B330A2. Furthermore, the invalidity information 504 being "F" indicates that the use meta class B330B2 uses the referencing meta class B330A2.

[0044] On the other hand, for use meta class C330B3, the presence / absence information 503 for referencing meta class C330A3 is "Yes", but the invalidity information 504 is "T". This indicates that use of referencing meta class C330A3 is invalid for use meta class C330B3, i.e., the use meta class C330B3 does not use referencing meta class C330A3. Furthermore, for use meta class D330B4, the presence / absence information for referencing meta class 330A is "No". This indicates that use meta class D330B4 does not reference referencing meta class 330A and was created in use meta model 300B. Note that because use meta class D330B4 does not reference referencing meta class 330A, there is no need to set invalidity information 504 to "T", and it is set to "F".

[0045] As shown in FIG. 7, the user data structure 500 of the user metamodel 300B includes not only user metaclass information 510 but also change point information 520. The change point information 520 indicates the changes made to the user metaclass 330B relative to the referencing metaclass 330A. In the examples of FIGS. 5 and 6, the changes are that field b2 of the user metaclass B 330B2 has been revised and that the referencing metaclass C 330A3 has been deleted. Therefore, the changes are included in the change point information 520 as change information 505 and deletion information 506. Note that in the examples of FIGS. 5 and 6, the addition of the user metaclass D 330B4 is also a change, but the addition of this user metaclass D 330B4 is not included in the change point information 520. This is because there is a one-to-one relationship between the use metaclass D330B4 setting the presence / absence information 503 of the reference metaclass 330A to "absent" in the use metaclass information 510 and "adding" the use metaclass D330B4, so unnecessary information is not added.

[0046] In this way, in this disclosure, the user's designer can independently configure the user data structure 500 of the user metamodel 300B. This allows the user to add information specific to the design site of the user. Furthermore, even when customizing the referencing metamodel 300A by changing, adding, or deleting to design the user metamodel 300B, the user can design the user metamodel 300B using exactly the same operations by using the above-mentioned ownership 301, reference 302, inheritance 303, and derivation 304.

[0047] Therefore, it is easy to change the name of the metaclass 330 to suit the site where it is used, and unnecessary information can be deleted from the user metamodel 300B. Furthermore, the changes made to the user metamodel 300B can be checked at any time. This makes it possible to clarify the differences between the referencing metaclass 330A and the user metaclass 330B, showing where and how changes were made. Of course, it is also easy to undo changes made to the user metamodel 300B.

[0048] After the user metamodel 300B is created, the referencing metamodel 300A may be modified and upgraded. The referencing metamodel 300A in Figure 8 shows an example of such an upgrade. The referencing metamodel 300A shown in Figure 8 has been modified from the referencing metamodel 300A shown in Figure 5 in that field b1 of the referencing metaclass B 330A2 has been improved and a referencing metaclass E 330A5 has been added.

[0049] As shown in Figure 9 as a reference example, information in the using metamodel 300B is not reflected in the referencing metamodel 300A. This unreflected information is indicated by dashed lines in Figure 9. That is, using metaclass D330B4 added in the using metamodel 300B is not included in the modified referencing metamodel 300A. Similarly, referencing metaclass C330A3 deleted in the using metamodel 300B remains in the modified referencing metamodel 300A, and the change to field b2 of using metaclass B330B2 in the using metamodel 300B is not reflected either.

[0050] 10 shows the referencing data structure 550 of the referencing metamodel 300A. The referencing data structure 550 includes name information 551 and version information 552 of the referencing metamodel 300A so that it can be identified as the data structure of the referencing metamodel 300A. The referencing data structure 550 also includes referenced metaclass information 560 indicating that the referencing metamodel 300A includes information on the referencing metaclasses A330A1 through D330A4.

[0051] 5, the referencing metamodel 300A shown in FIG. 8 has an improvement to field b1 of the referencing metaclass B330A2 and an addition of the referencing metaclass E330A25, but the referencing data structure 550 does not have any special change point information. This is because the referencing data structure 550 has version information 552, and the changes can be identified by using the version information 552. For example, if the referencing metamodel 300A in FIG. 5 is version 1.1 and the referencing metamodel 300A in FIG. 8 is version 1.3, comparing version 1.1 and version 1.3 makes it possible to identify the improvement to field b1 of the referencing metaclass B330A2 and the addition of the referencing metaclass E330A5.

[0052] In this way, when a new version of the referenced metamodel 300A, which is a design asset, is released, the contents of the update can be confirmed by looking at the referenced data structure 550 of the referenced metamodel 300A. This allows the user designer to decide whether to incorporate the updated changes. In other words, if the referenced metamodel 300A is updated after the user metamodel 300B is created, the updated contents of the referenced metamodel 300A, which is a new design asset, can be incorporated while retaining the contents customized in the user metamodel 300B.

[0053] Specifically, the updated contents are incorporated by combining the referencing data structure 550 shown in Fig. 10 with the user data structure 500 shown in Fig. 7. In the above example, in the referencing metamodel 300A, field b1 of the referencing metaclass B330A2 is improved and the referencing metaclass E330A5 is added, and field b2 of the user metaclass B330B2 is improved and the referencing metaclass C330A3 is deleted.

[0054] The changes can be easily understood not only by the designers of the referencing metamodel 300A and the user metamodel 300B, but also by other designers. As mentioned above, the details of updates to the referencing metamodel 300A, which is a design asset, can be understood by checking the referencing data structure 550. Similarly, the customizations made to the user metamodel 300B can be understood by checking the user data structure 500.

[0055] The relationship between the referencing metamodel 300A and the user metamodel 300B has been conceptually explained above using FIGS. 3 to 10. While some overlap occurs, a more detailed explanation will be provided below based on specific examples. First, the relationship between metamodels 300 in system development will be explained. While FIGS. 3 and 4 provide a general overview of the system development relationships, the relationship between components 51 and cross-domains 61 will be explained more specifically. In FIG. 11, a profile is used as a concept that adds a view definition to the metamodel 300. The view definition, which will be described later using FIGS. 20A to 20D, defines the display format of the view 307, such as a diagram. However, since the view definition is not used in this example, the profile in the following explanation is the same concept as the metamodel 300. In FIG. 11, the ADAS system 41 includes a cruise control system development profile 530, an automotive standard development profile 531, a software requirements profile 532, and a software design profile 533.

[0056] The relationships between profiles are also important when developing a system. In Figures 4 and 11, the Cruise Control System Development Profile 530 corresponds to the Cross Domain 61. The Automotive Standard Development Profile 531 corresponds to system development, and the Software Requirements Profile 532 and Software Design Profile 533 correspond to the parts 51. In this relationship, the relationship between the Cruise Control System Development Profile 530 and the Automotive Standard Development Profile 531 is such that the Automotive Standard Development Profile 531 is referenced in order to create the Cruise Control System Development Profile 530. Similarly, the Software Requirements Profile 532 and Software Design Profile 533 are referenced in order to create the Automotive Standard Development Profile 531.

[0057] Therefore, in this example, the relationships between the profiles are specified. That is, the relationship between the Cruise Control System Development Profile 530 and the Automotive Standard Development Profile 531 is defined as Automotive Standard 534. The relationship between the Automotive Standard Development Profile 531 and the Software Requirements Profile 532 is defined as Software Requirements 535, and the relationship between the Automotive Standard Development Profile 531 and the Software Design Profile 533 is defined as Software Design 536. In the example of FIG. 11, the version of the Cruise Control System Development Profile 530 is 1.0.0. The version of the Automotive Standard Development Profile 531 is 1.5.0. The versions of the Software Requirements Profile 532 and the Software Design Profile 533 are 2.1.0 and 1.2.2, respectively.

[0058] The relationships shown in Fig. 11 are summarized in a table in Fig. 12. List 540 at the top of Fig. 12 is a list of profile part versions. From left to right, this list 540 is arranged in a column for profile ID 541, a column for name 542, and a column for version information 543. List 540 has four rows, with cruise control system development profile 530, automobile standard development profile 531, software requirements profile 532, and software design profile 533 arranged from the top.

[0059] A reference relationship table 545 at the bottom of Fig. 12 shows the profile-part reference relationships. From the left, this reference relationship table 545 has a column for profile ID 546, a column for dependent profile ID 547, and a column for interrelationship 548. In this reference relationship table 545, each row describes the relationship between the above-mentioned profiles. From the top, an automobile standard 534, a software requirement 535, and a software design 536 are arranged.

[0060] 12, Automotive Standard 534 lists the ID of Cruise Control System Development Profile 530 in Profile ID 546. And it lists the ID of Automotive Standard Development Profile 531 in Dependent Profile ID. This shows that the relationship of Automotive Standard 534 refers to Automotive Standard Development Profile 531 in order to create Cruise Control System Development Profile 530.

[0061] As explained above, in this example, the relationships between profiles (metamodels 300) are clearly defined. In Figure 11, the relationships between profiles are visually represented by a diagram using arrows. In Figure 12, the relationships between profiles are defined in more detail using a table. In this way, by specifying the relationships between profiles, it becomes easier for the designer to understand which profile is desirable to use as the reference metamodel 300A. Similarly, the selection of the utilization metamodel 300B can be performed accurately by understanding the relationships between profiles.

[0062] Next, referring to Figure 13 and subsequent figures, we will explain in more detail the design work of designing the user metamodel 300B using the referencing metamodel 300A. Figure 13 shows the metamodel 300 of the ADAS system 41. The requirements definition 110 is a system requirement 1101. The metaclasses 330 of the system specification layer 1102, which define what to do, have an ownership relationship with the metaclasses 330 of the system requirement 1103, which defines the specific implementation of the system, and the metaclasses 330 of the use case 1104, which defines which device does what. Hereinafter, we will omit ownership and other relationships and only list the names of the metaclasses 330. The metaclasses 330 included in the system requirement 1101 include a system requirement 1105, a functional requirement 1106, a non-functional requirement 1107, an actor 1108, and a use case 1109. Although the same name may be used due to the relationship between the systems, the metaclasses 330 are distinguished by reference symbols.

[0063] 13, a package frame 111 is further used in the metamodel 300 of the requirements definition 110. The package frame 111 is used to group related metaclasses 330 together for easier visual recognition. Therefore, although it is not essential for creating the metamodel 300, surrounding it with a package frame 113 can improve the design work of the designer. The metamodel 300 of the system requirement 1101 shows the package frame 111 of the system requirement 1110 and the package frame 111 of the use case 1111.

[0064] 13 uses a metamodel 300 of a system function 121 corresponding to the logic design 120 and the control design 130. This metamodel 300 is referred to as a system function structure 1201. In the system function structure 1201, a metaclass 330 of a system 1202 owns the metaclasses 330 of a system input port, a system output port 1204, and a subsystem 1205. The system 1202 and a system component 1206 are in an inheritance relationship, and the system function structure 1207 owns the system 1202.

[0065] The ADAS system 41 also has a metamodel 300 of the physical design 140. This metamodel 300 of the physical design 140 is a system physical structure 1402. A metaclass 330 of a component 1402 owns other metaclasses 330 of a system component input port 1403, a system component output port 1404, and a component allocation 1405. The component 1402 and the ECU are in an inheritance relationship, and the metaclass 330 of the system physical structure 1407 owns the component 1402.

[0066] The ADAS system 41 also performs software development 200. Fig. 13 shows two metamodels 300 for the software development 200. One is a metamodel 300 for the software specification definition 210, and the other is a metamodel 300 corresponding to the software basic design 220 and the software detailed design 230. The metamodels 300 for the software basic design 220 and the software detailed design 230 include various metaclasses 330 as the software structure 221.

[0067] In this example, only the names of the metaclasses 330 are listed below. Included in the metamodel 300 of the software specification 2101 are metaclasses 330 of the software specification 2102, the software specification group 2103, the software requirements 2104, the software functional requirements 2105, and the software non-functional requirements 2106. Included in the metamodel 300 of the software structure 2201 are metaclasses 330 of the software structure 2202, the software configuration element 2203, the layer 2204, the software component 2205, the function 2206, the data 2207, the software input port 2208, and the software output port 2209.

[0068] FIG. 14 shows a metamodel 300 of the software development 200 of the cockpit module system 42. The software specification definition 210 is a metamodel 300 of software requirements 2110, and this metamodel 300 includes the following metaclasses 330: metaclasses 330 for software requirements definition 2111, software requirement elements 2112, software requirements 2113, functional requirements 2114, and non-functional requirements 2115. The metamodel 300 of the software structure 2210 of the software basic design 220 includes the following metaclasses 330: metaclasses 330 for software components 2211, functions 2212, subfunctions 2213, data types 2214, parameters 2215, and data 2216. The metamodel 300 of the software behavior 2310 of the software detailed design 230 also includes multiple metaclasses 330: metaclasses 330 for behavior 2311, control sequence 2312, and state transition 2313.

[0069] The software development 200 of the cockpit module system 42 also includes a metamodel 300 for the testing process 240. The metamodel 300 for the software test 2401 of this testing process 240 includes the following metaclasses 330: software test 2402, test specification 2403, test category 2404, test case 2405, test set 2406, and test plan 2407. These metaclasses 330 are used to run the software actually designed in the software detailed design 230. This allows confirmation of whether the behavior defined in the software specification definition 210 is achieved.

[0070] Figure 15 shows an ADAS system 41, which uses the metamodel 300 for system development described in Figure 13. That is, the metamodel 300 for the requirements definition 110 (system requirements 1101), the metamodel 300 for the logical design 120 and control design 130 (system functional structure 1201), and the metamodel 300 for the physical design 140 (system physical structure 1401) are used. Therefore, between the ADAS system 41 shown in Figure 15 and the ADAS system 41 shown in Figure 13, the requirements definition 110 (system requirements 1101), the logical design 120 and control design 130 (system functional structure 1201), and the physical design 140 (system physical structure 1401) of the ADAS system 41 shown in Figure 13 become the reference metamodel 300A. The requirements definition 110 (system requirements 1101), logical design 120 and control design 130 (system functional structure 1201), and physical design 140 (system physical structure 1401) of the ADAS system 41 shown in FIG. 15 become the user metamodel 300B.

[0071] However, the ADAS system 41 shown in Fig. 15 does not use the metamodel 300 of the software specification definition 210 (software specification 2101), which is the metamodel 300 of the software development 200 described in Fig. 13, or the metamodel 300 of the software basic design 220 and the software detailed design 230 (software structure 2201). Instead, the ADAS system 41 shown in Fig. 15 uses the metamodel 300 of the software development 200 of the cockpit module system 42 described in Fig. 14. Therefore, the ADAS system 41 shown in Fig. 15 and the cockpit module system 42 shown in Fig. 14 have the software specification definition 210 (software requirements 2110), software basic design 220 (software structure 2210), software detailed design 230 (software behavior 2310), and test process 240 (software test 2401) of the cockpit module system 42 shown in Fig. 14 as the reference metamodel 300A. The software specification definition 210 (software requirements 2110), software basic design 220 (software structure 2210), software detailed design 230 (software behavior 2310), and test process 240 (software test 2401) of the ADAS system 41 shown in Figure 15 become the user metamodel 300B.

[0072] When using the user metamodel 300B, some metaclasses 330 are derived 304 to other metaclasses 330. For example, the metaclass 330 of the software requirement 2113 in the metamodel 300 of the software specification definition 210 (software requirement 2110) and the metaclass 330 of the system requirement 1105 in the metamodel 300 of the requirements definition 110 (system requirement 1101) are connected by a derivation 304 relationship. This allows the contents of the software requirements 212 to be reflected in the system delivery. It also makes it possible to trace design information across configurations.

[0073] In addition, the metaclass 330 of the software component 2211 in the metamodel 300 of the software basic design 220 (software structure 2210) is connected to the metaclass 330 of the system configuration element 1206 in the metamodel 300 of the logical design 120 and control design 130 (system functional structure 1201) and the metaclass 330 of the component 1402 in the metamodel 300 of the physical design 140 (system physical structure 1401) by a derivation 304 relationship. In this way, by connecting them by a derivation 304 relationship, the metamodel 300 of system development and the metamodel 300 of software development 200 can be related.

[0074] In the ADAS system 41 shown in Fig. 15, the names of the metaclasses 330 in the metamodel 300 have been changed to match the terminology of the development project. In the metamodel 300 of the physical design 140 (system physical structure 1401) of the ADAS system 41 described in Fig. 13, the names "system component input port 1403" and "system component output port 1404" were used for the metaclasses 330. In contrast, in the metamodel 300 of the physical design 140 of the ADAS system 41 shown in Fig. 15, the names of the metaclasses 330 are simply "component input port 1403" and "component output port 1404."

[0075] In the ADAS system 41 shown in Fig. 15, unnecessary metaclasses 330 are deleted in accordance with the development project. In the example of Fig. 15, the metaclass 330 of the subfunction 2213 of the metamodel 300 of the software basic design 220 (software structure 2210) is deleted. This is because the development project does not require refinement down to the subfunction. With the deletion of the metaclass 330 of this subfunction 2213, the reference 302 related to this metaclass 330 is automatically invalidated. The reference 302 that is automatically invalidated is indicated by reference symbol 3021 in Fig. 15.

[0076] Conversely, in the ADAS system 41 shown in Fig. 15, metaclasses 330 are also added in accordance with the development project. In the example of Fig. 15, in the metamodel 300 of the test process 240 (software test 2401), a unique metaclass 330 that defines the test environment is added to the metaclass 330 of the software test 2402.

[0077] This allows the metamodel 300 of the software development 200, which was originally designed for the cockpit module system 42, to be tested in an environment corresponding to the ADAS system 41. Specifically, the metaclass 330 of the test environment definition 2408 and the metaclass 330 of the test environment element 2409 are connected by a relationship of ownership 301. Furthermore, the metaclass 330 of the test environment element 2409 is connected by a relationship of inheritance 303 to the metaclasses 330 of the hardware 2410 and software 2411.

[0078] After the ADAS system 41 shown in FIG. 15 is designed, the ADAS system 41 described in FIG. 13 may be upgraded. The ADAS system 41 shown in FIG. 16 is basically the same as the ADAS system 41 described in FIG. 13. The metamodels 300 of the requirements definition 110 (system requirements 1101), the logical design 120 and control design 130 (system function structure 1201), the physical design 140 (system physical structure 1401), the software specification definition 210 (software specification 2101), the software basic design 220 and the software detailed design 230 (software structure 2201) are each set to version 1.0. In contrast, in the ADAS system 41 shown on the right side of FIG. 16, the metamodels 300 of the requirements definition 110, the system function 121, the software specification definition 210, and the software structure 221 remain at version 1.0, but the metamodel 300 of the physical design 140 has been upgraded to version 1.1.

[0079] In version 1.1 of the metamodel 300 of the physical design 140 (system physical structure 1401), the metaclass 330 of the component 1402 is related to the metaclass 330 of the device 1408 by inheritance 303. Furthermore, the metaclass 330 of the device 1408 is related to the metaclasses 330 of the sensor 1409 and the actuator 1410 by inheritance 303. This makes it clear that the component 1402 includes the device 1408, and more specifically, includes the sensor 1409 and the actuator 1410.

[0080] Additionally, fields 14031 and 14041 are added to the metaclasses 330 of the system component input port 1403 and the system component output port 1404, respectively, to clarify the "port type" and "maximum transfer rate" of the system component input port 1403 and the system component output port 1404. This makes it possible to identify the functions of the input and output ports of the added sensor 1409 and actuator 1410. The metamodel 300 of the physical design 140 (system physical structure 1401) is updated from version 1.0 to version 1.1 when, for example, the performance of the sensor is improved. The version is upgraded when it becomes possible to supply additional information due to an increase in the maximum transfer rate.

[0081] The upgraded ADAS system 41 described in Fig. 16 can also be used in an ADAS system 41 incorporating the metamodel 300 of the software development 200 of the cockpit module system 42 described in Fig. 15. Fig. 17 shows an example in which the metamodel 300 of the physical design 140 (system physical structure 1401) has been updated to version 1.1. The metamodel 300 of the physical design 140 (system physical structure 1401) of version 1.1 in Fig. 16 becomes the referencing metamodel 300A, and the metamodel 300 of the physical design 140 (system physical structure 1401) in Fig. 17 becomes the using metamodel 300B.

[0082] In the user metamodel 300B, the metaclasses 330 for the system component input port 1403 and the system component output port 1404 have been customized to have the names component input port 1403 and component output port input 1404, respectively. The functions of version 1.1 are also reflected in the user metamodel 300B, and metaclasses 330 for devices 1408, sensors 1409, and actuators 1410 have been added. In addition, fields 14031 and 14041 have been added to the metaclasses 330 for the component input port 1403 and the component output port 1404.

[0083] In the example of Figure 17, no inconsistency occurs when the metamodel 300 of the physical design 140 version 1.1 is used as the user metamodel 300B. However, depending on the customization of the user metamodel 300B and the content of the upgrade of the referenced metamodel 300A, an inconsistency may occur in the user metamodel 300B. In that case, the update of the referenced metamodel 300A is given priority, and the upgraded metamodel 300 is used as the user metamodel 300B. Furthermore, the occurrence of an inconsistency is displayed, allowing the designer to correct the inconsistency without feeling stressed.

[0084] For example, consider the case where an update is made in Figure 8 that deletes the referenced metaclass B330A2. In this case, an inconsistency occurs with the change information that improves field b2, as shown in Figure 9. However, this inconsistency with the change information is ignored, and the deletion of the referenced metaclass B330A2 takes priority. This is what is meant by the change on the updated side (deletion of the referenced metaclass B330A2) taking priority. If an inconsistency (conflict) occurs with the customization content during the update, the updated side is forcibly adopted and the user is notified of this. The user can view the notification and decide which metamodel 300 to adopt.

[0085] Next, the user data structure 500 of the user metamodel 300B will be described in more detail. Figure 18 shows the user data structure 500 of the user metamodel 300B. In the example of Figure 18, the referencing metamodel 300A has a referencing metaclass QR330A8 for quality requirements and a referencing metaclass US330A9 for user scenarios. The referencing metaclass US330A9 and the referencing metaclass QR metaclass 330A8 are in a reference 302 relationship in which the referencing metaclass US330A9 operates by referencing the referencing metaclass QR metaclass 330A8. The referencing metaclass US330A9 for user scenarios includes a field PC for existing situations.

[0086] 18, the user metamodel 300B modifies the referencing metaclass QR330A8 of the referencing metamodel 300A and uses it as the user metaclass NR330B8 for non-functional requirements. The user metamodel 300B also adds the user metaclass RER330B10 for resource efficiency requirements. Conversely, the referencing metaclass US330A9 of the referencing metamodel 300A has been deleted from the user metamodel 300B and is not used.

[0087] The above situation is defined in the usage metaclass information 510 of the usage data structure 500 as follows: The name of the usage metamodel 300B is entered in usage name information 501, and version 1.1 is entered in usage version information 502. In usage metaclass information 510, reference source presence information 503 for usage metaclass NR330B8 indicates that the referencing metaclass QR330A8 is referenced "Yes," and invalidity information 504 indicates the invalid flag is "F." This indicates that usage metaclass NR330B8 uses the referencing metaclass QR330A8. For usage metaclass RER330B10, the reference is "No" in presence information 503. This indicates that usage metaclass RER330B10 was added in usage metamodel 300B. For reference metaclass US330A9, the reference is "Yes" in presence information 503, and the invalidity flag is "T." This indicates that the usage metaclass US330B9 has been disabled (deleted) in the usage metamodel 300B. Similarly, the invalid flag for the field PC is also "T", which indicates that the field PC of the usage metaclass US330B9 in the usage metamodel 300B has also been deleted.

[0088] In the change point information 520 of the user data structure 500, the change information 505 indicates that the name of the referencing metaclass QR330A8 of the referencing metamodel 300A has been changed from "Quality Requirement" to "Non-Functional Requirement" in the user metaclass NR330B8 of the user metamodel 300B. In addition, the deletion information 506 indicates that the referencing metaclass US330A9 of the referencing metamodel 300A has been deleted from the user metamodel 300B.

[0089] The above explanation of Figure 18 is similar to the explanation of Figures 5 to 7. Next, the usage data structure 500 of Figure 18 will be explained in more detail using Figures 19A and 19B. Figure 19A shows the usage data structure 500 of the usage metamodel 300B in table format. The table of usage metaclass information 510 includes the element list shown on the left. That is, the element list is part of the usage metaclass information 510, and the five columns from the left are arranged in the following order: ID 511, Name 512, Type 513, Base ID 514, and Invalid Flag 515. The usage metaclass 330B has four rows, and from top to bottom, they are usage metaclass RER330B10, usage metaclass NR330B8, usage metaclass US330B9, and the field PC of usage metaclass US330B9. It is possible to know which metaclass 330 each use-destination metaclass 330B is by using the ID 511 and the name 512.

[0090] The type 513 of the destination meta class information 510 distinguishes between a meta class and a field. The fourth line is the field PC. The base ID 514 indicates the ID of the referencing meta class 330A of the referencing meta model 300A. Since the destination meta class RER330B10 does not have a referencing meta class 330A, the base ID 514 is blank. The invalid flag 515 indicates the invalid information 504; as mentioned above, if it is "F", it is used, and if it is "T", it is deleted. The field PC of the destination meta class US330B9 is automatically deleted when the parent element destination meta class US330B9 is invalidated.

[0091] The change point information 520 of the user data structure 500 shown in Figure 19B has the following five columns. The leftmost column is a change / deletion distinction 521, followed by a target ID 522, change details 523, pre-change information 524, and post-change information 525. The distinction 521 identifies whether it is a change or deletion. In the case of a deletion, the metaclass to be deleted is displayed in the deletion information 506. The target ID 522 is used to display that metaclass. Therefore, the target ID 522 is the ID of the metaclass to be changed or deleted. The second line in Figure 19B is the user metaclass US330B9, which is deleted. What is particularly noteworthy about the change point information 520 is that the target ID 522 is retained even after deletion. This makes it easy to restore a deleted user metaclass US330B9.

[0092] If the type of change is a change, the metaclass to be changed is identified by target ID 522, and change information 505 is specified by change content 523, before-change information 524, and after-change information 525. In the example of Figure 19B, the first line of target ID 522 is the user metaclass NR330B8, which is changed. Change content 523 of this user metaclass NR330B8 is a change in name. The name of before-change information 524 for user metaclass NR330B8 is "quality requirement," and the name of after-change information 525 is "non-functional requirement."

[0093] Returning to Figure 19A, the usage metaclass information 510 of the usage data structure 500 also includes a table listing the attributes of the elements shown on the right. The right side of the table in Figure 19A includes a column for ID 516, a column for additional information 517, and a column for additional content 518. The column for ID 561 is the same as the column for ID 511 on the left side of the table. The top two rows are usage metaclass RER330B10, and the next two rows are usage metaclass NR330B8. Next are two rows for usage metaclass US330B9, and the bottom three rows are field PCs for usage metaclass US330B9.

[0094] For user metaclass 330B, additional information 517 includes a name and a determination as to whether it is an abstract concept. The name of user metaclass RER330B10 is entered as "resource efficiency requirement" in additional content 518, and the determination as to whether it is an abstract concept is marked "F," indicating that it is not an abstract concept. The name of additional information 517 for user metaclass NR330B8 is entered as "non-functional requirement" in additional content 518, and the abstract concept is marked "T" in additional content 518, indicating that it is an abstract concept. Here, the name "non-functional requirement" is the name that was changed in after-change information 525 of change point information 520, and so the change is reflected in additional content 518.

[0095] In the user metaclass US330B9, the name of the additional information 517 is "user scenario" in the additional content 518, which is the same as in the referencing metaclass 330A. Also, the determination of whether it is an abstract concept is marked "F" in the additional content 518. In the field PC, the name of the additional information 517 is marked "existing situation" in the additional content 518. In the field PC, the lower limit and upper limit are included in the additional information 517, and are marked "1" in the additional content 518. This is also the same as in the referencing metaclass 330A.

[0096] The design support system of this example can display design results in multiple formats, as shown in Figures 20A to 20D. In other words, the design support system of this example allows design information to be entered through multiple screens. It can also be represented as a tree diagram 3071, as shown in Figure 20B, or a tree grid 3073, as shown in Figure 20D. Designers can select the view 307 that is most convenient for their design needs. The ER diagram 3070 shown in Figure 20A is desirable for overviewing the overall structure, while the tabular document form 3072 shown in Figure 20C is desirable for defining the details of each item. While the four types of views 307 shown in Figures 20A to 20D are all examples that are easy to use in design, the views 307 used in this example's design support tool are not limited to these four types. Conversely, the number of types of views 307 can be reduced to fewer than four.

[0097] As described above, the design support tool of this example allows for inconsistencies to occur when incorporating an upgrade of the reference source metamodel 300A. By allowing for these inconsistencies, the design support system is given flexibility, allowing the designer to continue designing without stress.

[0098] The design support tool in this example tolerates inconsistencies and prioritizes the updated side even if an inconsistency occurs, but instead notifies the user that an inconsistency has occurred.The tool detects inconsistencies and notifies the designer, allowing the designer to easily correct the inconsistency to create a consistent destination metamodel 300B.Inconsistencies are detected when a file is opened or when the metamodel 300 is changed by deleting, editing, or merging.

[0099] While the above example is a desirable use of the design support system of this example, the design support system of this example can be modified in various ways within the scope of the claims. In the above example, the reference source metamodel 300A of the ADAS system 41 uses the metamodel 300 of another system, such as the cockpit module system 42. This usage method is in line with recent trends. However, it is of course acceptable to use the metamodel 300 of the same system as the reference source metamodel 300A depending on the situation.

[0100] Upgrading the referencing metamodel 300A is desirable in order to promote the use of the present disclosure. However, the present disclosure does not require that the referencing metamodel 300A be upgraded. It is possible to use a metamodel 300 that is required to have the same content as the referencing metamodel 300A.

[0101] In addition, customization of the metaclass 330 in the user metamodel 300B by changing, adding, or deleting it is a desirable use case for enhancing the usefulness of the design support system of the present disclosure. However, the design support system of the present disclosure only requires customization, and this customization is not required for use. It is possible for the user metamodel 300B to adopt a metamodel 300 with the same content as the reference metamodel 300A.

[0102] The development of systems used in automobiles, such as an ADAS system 41 and a cockpit module system 42, is one example of an application of the design support system of the present disclosure. Of course, the system can be used for the development of other systems, and can also be used for non-automotive applications.

[0103] The design aspects of system development 100 are generally defined as requirements definition 110, logical design 120, control design 130, and physical design 140, while the design aspects of software development 200 are generally defined as software specification definition 210, software basic design 220, and software detailed design 230, although other definition methods may also be used. This example also shows an example in which a testing process 240 is added to software development 200.

[0104] It is desirable that the relationships between metaclasses 330 in the metamodel 300 include all of ownership 301, reference 302, inheritance 303, and derivation 304, but depending on the usage pattern, some relationships may be deleted. Conversely, additional relationships may be added. What the design support system of this example needs is the contents contained in the referencing data structure 550 and the contents contained in the user data structure 500.

[0105] As mentioned above, the design support system 1 in this specification may also be referred to as an electronic control device. The control device or design support system 1 is provided by an algorithm. The program may be distributed alone or as a storage medium on which the program is stored. Therefore, the present disclosure is the design support system 1, and also includes a design support program for causing a computer to realize the design support. It also includes a computer-readable storage medium on which a design support program for causing a computer to realize the design support is recorded.

[0106] (Disclosure of technical ideas) This specification discloses multiple technical ideas described in the following multiple clauses. Some clauses may be written in a multiple dependent form, with the subsequent clause referring to the preceding clause as an alternative. Furthermore, some clauses may be written in a multiple dependent form, referring to another multiple dependent clause. These multiple dependent clauses define multiple technical ideas.

[0107] (Technical thought 1) A design support tool for supporting design, defining a referencing metamodel by one or more referencing metaclasses, said referencing metamodel having a referencing data structure; The reference source data structure includes reference source name information indicating the name of the reference source metamodel, reference source version information indicating the version of the reference source metamodel, and reference source metaclass information indicating the contents of the reference source metaclass, defining a consumer metamodel by one or more consumer metaclasses, the consumer metamodel being able to use the referencing metamodel, the consumer metamodel having a consumer data structure; The user data structure includes user name information indicating the name of the user metamodel, user version information indicating the version of the user metamodel, user metaclass information indicating the relationship between the user metaclass and the reference source metaclass, and change point information indicating the change points between the user metaclass and the reference source metaclass, When the user metamodel uses the referencing metamodel, the user data structure is updated while the referencing data structure is left unchanged. Design support system.

[0108] (Technical thought 2) The destination metaclass information of the destination data structure includes presence / absence information indicating whether the destination metaclass references the reference source metaclass, and invalidity information indicating whether the reference source metaclass is valid or invalid. The presence / absence information includes ID information for identifying the referencing meta class if the referencing meta class exists. A design support system according to technical concept 1.

[0109] (Technical Thought 3) The change point information of the destination data structure includes change information between the reference source metaclass and the destination metaclass, and deletion information indicating the reference source metaclass that is not used in the destination metamodel. A design support system according to technical concept 2.

[0110] (Technical Thought 4) When the destination metamodel uses the referenced metamodel, the referenced metaclass is changed to the destination metaclass, The destination meta class information of the destination data structure includes ID information that identifies the referencing source meta class by identifying the referencing source meta class, and validates the referencing source meta class; The change point information of the destination data structure records the change content between the reference source meta class and the destination meta class in the change information. A design support system as described in Technical Concept 3.

[0111] (Technical Thought 5) When the using metamodel uses the referencing metamodel, if an addition is made to the referencing metaclass to become the using metaclass, The destination metaclass information of the destination data structure nullifies the reference source metaclass that the destination metaclass references, The change point information of the destination data structure is unchanged. A design support system according to Technical Idea 3 or Technical Idea 4.

[0112] (Technical Thought 6) When the using metamodel uses the referencing metamodel, the referencing metaclass is deleted, The destination meta class information of the destination data structure includes ID information that identifies the referencing source meta class, assuming that the referencing source meta class referenced by the destination meta class exists, and invalidates the referencing source meta class; The change point information of the destination data structure records the deleted reference source metaclass in the deletion information. A design support system according to any one of Technical Ideas 3 to 5.

[0113] (Technical Thought 7) When the version of the referencing metamodel is changed after the using metamodel uses the referencing metamodel, the referencing data structure is updated; Based on the updated reference data structure and the updated destination data structure, incorporating changes to the version of the referencing metamodel into the consuming metamodel; A design support system according to any one of technical ideas 1 to 6.

[0114] (Technical Thought 8) A design support program for enabling a computer to realize design support, This design support program defines a reference metamodel by one or more reference metaclasses, and the reference metamodel has a reference data structure, The reference source data structure includes reference source name information indicating the name of the reference source metamodel, reference source version information indicating the version of the reference source metamodel, and reference source metaclass information indicating the contents of the reference source metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the referencing metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating the name of the user metamodel, user version information indicating the version of the user metamodel, user metaclass information indicating the relationship between the user metaclass and the reference source metaclass, and change point information indicating the change points between the user metaclass and the reference source metaclass, When the destination metamodel uses the referenced metamodel, the design support program updates the destination data structure while leaving the referenced data structure unchanged. Design support program.

[0115] (Technical Thought 9) A computer-readable recording medium having recorded thereon a design support program for causing a computer to realize design support, the design support program defines a reference metamodel by one or more reference metaclasses, and the reference metamodel has a reference data structure; The reference source data structure includes reference source name information indicating the name of the reference source metamodel, reference source version information indicating the version of the reference source metamodel, and reference source metaclass information indicating the contents of the reference source metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the referencing metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating the name of the user metamodel, user version information indicating the version of the user metamodel, user metaclass information indicating the relationship between the user metaclass and the reference source metaclass, and change point information indicating the change points between the user metaclass and the reference source metaclass, When the destination metamodel uses the referenced metamodel, the design support program updates the destination data structure while leaving the referenced data structure unchanged. A computer-readable recording medium on which the design support program for causing a computer to realize the design support is recorded. [Explanation of symbols]

[0116] 1 Design support system 300 Metamodel 300A Reference Metamodel 300B Usage Metamodel 500 User Data Structure 550 Reference Data Structure

Claims

1. A design support system (1) for supporting design, A referencing metamodel (300A) is defined by one or more referencing metaclasses (330A), and the referencing metamodel has a referencing data structure (550); This reference source data structure includes reference source name information (551) indicating the name of the reference source metamodel, reference source version information (552) indicating the version of the reference source metamodel, and reference source metaclass information (560) indicating the contents of the reference source metaclass, A consumer metamodel (300B) is defined by one or more consumer metaclasses (330B), and the consumer metamodel can use the referencing metamodel, and the consumer metamodel has a consumer data structure (500); This user data structure includes user name information (501) indicating the name of the user metamodel, user version information (502) indicating the version of the user metamodel, user metaclass information (510) indicating the relationship between the user metaclass and the referencing metaclass, and change point information (520) indicating the change points between the user metaclass and the referencing metaclass, When the user metamodel uses the referencing metamodel, the user data structure is updated while the referencing data structure is left unchanged. Design support system.

2. The destination metaclass information of the destination data structure includes presence / absence information (503) indicating whether the destination metaclass references the referenced metaclass, and invalidity information (504) indicating whether the referenced metaclass is valid or invalid. The presence / absence information includes ID information for identifying the referencing meta class if the referencing meta class exists. The design support system according to claim 1 .

3. The change point information of the destination data structure includes change information (505) between the reference source metaclass and the destination metaclass, and deletion information (506) indicating the reference source metaclass that is not used in the destination metamodel. The design support system according to claim 2 .

4. When the destination metamodel uses the referenced metamodel, the referenced metaclass is changed to the destination metaclass, The destination meta class information of the destination data structure includes ID information that identifies the referencing source meta class by identifying the referencing source meta class, and validates the referencing source meta class; The change point information of the destination data structure records the change content between the reference source meta class and the destination meta class in the change information. The design support system according to claim 3 .

5. When the using metamodel uses the referencing metamodel, if an addition is made to the referencing metaclass to become the using metaclass, The destination metaclass information of the destination data structure nullifies the reference source metaclass that the destination metaclass references, The change point information of the destination data structure is unchanged. The design support system according to claim 3 .

6. When the using metamodel uses the referencing metamodel, the referencing metaclass is deleted, The destination meta class information of the destination data structure includes ID information that identifies the referencing source meta class by identifying the referencing source meta class, and invalidates the referencing source meta class; The change point information of the destination data structure records the deleted reference source metaclass in the deletion information. The design support system according to claim 3 .

7. When the version of the referencing metamodel is changed after the using metamodel uses the referencing metamodel, the referencing data structure is updated; Based on the updated reference data structure and the updated destination data structure, incorporating changes to the version of the referencing metamodel into the consuming metamodel; 7. The design support system according to claim 1.

8. A design support program for enabling a computer to realize design support, This design support program defines a reference metamodel by one or more reference metaclasses, and the reference metamodel has a reference data structure, The reference source data structure includes reference source name information indicating the name of the reference source metamodel, reference source version information indicating the version of the reference source metamodel, and reference source metaclass information indicating the contents of the reference source metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the referencing metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating the name of the user metamodel, user version information indicating the version of the user metamodel, user metaclass information indicating the relationship between the user metaclass and the reference source metaclass, and change point information indicating the change points between the user metaclass and the reference source metaclass, When the destination metamodel uses the referenced metamodel, the design support program updates the destination data structure while leaving the referenced data structure unchanged. Design support program.

9. A computer-readable recording medium having recorded thereon a design support program for causing a computer to realize design support, the design support program defines a reference metamodel by one or more reference metaclasses, and the reference metamodel has a reference data structure; The reference source data structure includes reference source name information indicating the name of the reference source metamodel, reference source version information indicating the version of the reference source metamodel, and reference source metaclass information indicating the contents of the reference source metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the referencing metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating the name of the user metamodel, user version information indicating the version of the user metamodel, user metaclass information indicating the relationship between the user metaclass and the reference source metaclass, and change point information indicating the change points between the user metaclass and the reference source metaclass, When the destination metamodel uses the referenced metamodel, the design support program updates the destination data structure while leaving the referenced data structure unchanged. A computer-readable recording medium on which the design support program for causing a computer to realize the design support is recorded.

Images