Design support system, design support program, and recording medium on which the design support program is recorded

Abstract

A metamodel designed in the development of a certain system is used as a reference metamodel, and this metamodel is made easy to use in various systems as a user metamodel. [Solution] When a destination metamodel uses a referencing metamodel, the destination data structure is updated while the referencing data structure is left unupdated. Because the referencing data structure is left unupdated, the referencing metamodel is maintained with its original contents even when the referencing metamodel is used. Meanwhile, because the destination data structure is updated, the destination metamodel can be created again with the updated contents. For example, when the referencing metamodel is upgraded, the updated destination data structure can be applied to the upgraded referencing metamodel.

Description

[Technical field]

[0001] The present disclosure relates to a design support system that can be used in the design of a plurality of systems, such as an automobile driving support system, a cockpit module system, an engine control system, etc. The present disclosure also relates 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 and allows 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 a driving support system for an automobile, multiple metamodels used in the driving support 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] A designer developing a driving assistance system can easily find metamodels that need to be modified by viewing the display of inconsistencies. Then, by modifying them, the development of an autonomous driving system can be easily achieved. In this way, the technology described in Patent Document 1 makes system development easy, and is premised on the fact that if an inconsistency is found, it will be modified.

[0006] The design support system described in Patent Document 1 is effective for the development of a single system such as a driving support system. However, in recent years, for example, there are more and more cases in which multiple systems are involved in the development of automobiles. Rather than being completed with the driving support system, the design results and metamodels used in the driving support 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] In this way, when a metamodel designed in one system development is used in another system development, it is not enough to simply correct the inconsistency when it is found. This is because the metamodel designed in a specific system development does not have inconsistencies in that system development, and further functional improvements are often made. Therefore, simply correcting the inconsistencies in the metamodel 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 easy 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 for supporting 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 destination metamodel by one or more destination metaclasses, and the destination metamodel can use a reference metamodel, and the destination metamodel has a destination data structure. The destination data structure includes destination name information indicating the name of the destination metamodel, destination version information indicating the version of the destination metamodel, destination metaclass information indicating the relationship between the destination metaclass and the reference metaclass, and change point information indicating the change points between the destination metaclass and the reference metaclass.

[0011] In the design support system of the present disclosure, when a destination metamodel uses a referenced metamodel, the destination data structure is updated while the referenced data structure is not updated. In the design support system of the present disclosure, since the referenced data structure is not updated, there is no effect on the referenced metamodel. In other words, even if the referenced metamodel is used, the referenced metamodel is maintained with its original contents. On the other hand, in the design support system of the present disclosure, since the destination data structure is updated, the destination metamodel can be created again with the updated contents. For example, if the referenced metamodel is upgraded, the destination data structure can be applied to the upgraded referenced metamodel.

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

[0013] [Figure 1] FIG. 1 is an explanatory diagram showing the development procedure of a system. [Diagram 2] FIG. 2 is an explanatory diagram showing a metamodel. [Diagram 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. [Diagram 5] FIG. 5 is an explanatory diagram illustrating a referencing metamodel. [Figure 6] FIG. 6 is an explanatory diagram showing a utilization meta-model. [Figure 7] FIG. 7 is an explanatory diagram showing a utilization destination data structure. [Figure 8] FIG. 8 is an explanatory diagram showing the reference 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 referral source 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 in a table the system development shown in FIG. [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 used. [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 the view. [Figure 20C] FIG. 20C is an explanatory diagram showing another example of the view. [Figure 20D] FIG. 20D is an explanatory diagram showing another example of the view. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] The design support system 1 in this specification may also be called an electronic control unit (ECU). The control unit, or the design support system 1, is provided by (a) an algorithm as a plurality of logics called an if-then-else format, or (b) an algorithm as 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 (hardware processor). The hardware processor can be provided by the following (i), (ii), or (iii).

[0016] (i) The hardware processor may be at least one processor core that executes a program stored in at least one memory. In this case, the 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. The memory is also called a storage medium. The memory is a non-transitive and tangible storage medium that non-temporarily stores "programs and / or data" that can be read by the processor. The storage medium is provided by a semiconductor memory, a magnetic disk, an optical disk, or the like. The program may be distributed alone or as a storage medium on which the program is stored.

[0017] (ii) The hardware processor may be a hardware logic circuit. In this case, the 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. The computer may be provided by an analog circuit. The 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 (ii) part may also be called an accelerator.

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

[0020] As shown in FIG. 1, system development 100 begins with requirement definition 110. Requirement definition 110 sets development goals, such as determining that an ADAS system that supports driving through lane keeping and following driving will be designed. Next comes logical design 120, which determines function definitions and inputs and outputs. In an ADAS system, inputs include driver requests, the vehicle's driving status, and road conditions, including the presence or absence of traffic jams. Outputs include control items for determining what type of control will be performed, such as the degree of acceleration, braking, and steering operation.

[0021] System development 100 then performs control design 130. Control design 130 is circuit design, and determines what calculation formula will be used for each control. For example, how to detect vehicle speed and obstacles, etc. Obstacle detection can be performed by using signals from laser sensors, obtaining information from traffic infrastructure, or obtaining information from a car navigation system. After that, physical design 140 is performed. Physical design 140 is literally a design of which ECU to physically allocate control to. For example, there is a division of roles, such as whether to calculate vehicle speed detection by the sensor ECU or the engine control ECU.

[0022] Software development 200 is a development in which the outline defined in the above system development 100 is concretely implemented into software. First, a software specification definition 210 is defined. When the vehicle speed detection function is assumed to be handled by the engine control ECU in the above physical design 140, more specific details of the engine control ECU are defined in this software specification definition 210. Next, software basic design 220 is performed. In this software basic design 220, each function defined in the system development 100 is divided into multiple layers, and it is determined what input is obtained and how it is output for each function. Then, it is determined how to check if there is a problem between the input and output. After that, software detailed design 230 is performed. In software detailed design, a specific calculation method is summarized in a flow chart or the like so that it can be written in a program language. The source code of the program is determined by this software detailed design 230.

[0023] Whether it is system development 100 or software development 200, if the design content is expressed from a different perspective, a logical formula 10 is defined, layout design 20 is performed on how to physically arrange it, and 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, the requirements definition 110, to the lower processes. However, this design procedure allows for a consistent design from the top down, since the design content is subdivided as the process progresses. However, this requires a complete understanding of the entire system, and is extremely difficult for large-scale, complex systems. In other words, system development cannot proceed unless it progresses to a certain level of detail.

[0025] Contrary to the above explanation, there is also a bottom-up development design method in which each part that makes up the system is first designed in detail, and then the system is developed by combining those parts. This is suitable for using 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 can develop optimal parts, it may result in partial optimization and not 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 performed, there are many definitions 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 flow charts, etc., and these definitions must always be inherited without contradiction.

[0027] The design support system 1 of this example is capable of handling the entire series of development design 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 is possible to use it 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 above-mentioned system development 100 to the software detailed design 230 of the software development 200, 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 the metamodel 300 that determines the direction of development, and the design result that is produced based on the metamodel 300.

[0029] As shown in Fig. 2, metamodel 300 specifies the relationship between metaclasses 330, which are elements constituting metamodel 300, by connecting them with lines. In the example of Fig. 2, the line with a black square at the end connecting first metaclass 3301 and second metaclass 3302 represents possession 301 that specifies the 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 FIG. 2, the arrow connecting the second metaclass 3302 and the third metaclass 3303 represents a reference 302, and indicates that the contents defined in the second metaclass 3302, such as a field, operate by referring to a field defined in the third metaclass. The reference 302 indicates that there is some 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 has 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 a hierarchical relationship, and does not need to be in the same process. It is also possible for the input port of the second metaclass 3302 to reference 302 the contents 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 metaclass 330 of one process is linked to metaclass 330 of another process by a derivation 304 relationship, this indicates that metaclass 330 of the other process is defined based on the contents of 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 concrete content by the name and size of the input port, such as using three input ports, the first input port, the second input port, and the third input port. Therefore, the design result based on one metaclass may have multiple components. The relationships between the components include ownership 301 and reference 302.

[0034] In this way, 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 and following driving, a cockpit module system 42 that controls various meters and operating devices of an automobile, an electronic system 43 that controls an engine and a driving motor, and the like. In the example of Fig. 3, the design support tool of this embodiment is used for the logical design 120 in the ADAS system 41. In the cockpit module system 42, the design support tool is used for the requirements definition 110, and in the electronic system 43, the design support tool is used for the logical design 120 and the software basic design 220.

[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, a cockpit A system can be created using the cockpit module system 42 as a base. As the cockpit A system, for example, software to be used in the cockpit module system 42 can be developed. Similarly, a cockpit B system can be created using the cockpit module system 42 as a base. 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 in multiple systems into components so that they can be used in other systems, as shown in Fig. 4. For example, a requirements definition 110 designed in a cockpit module system 42 may be generalized as a requirements definition component A51. Similarly, a logical design 120 designed in an ADAS system 41 may be generalized as a logical design component A52, and a software basic design 220 designed in an electronics system 43 may be generalized as a software basic design component A53.

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

[0038] If components such as the requirements definition components A51, logical design components A52, and software basic design 220, as well as cross domains such as cross domain A61 and cross domain B62, are stored in the core server as design assets as reference metamodels 300A, the designers of each system can use them to design a system. The designers of each system can extract the necessary reference metamodels 300A from the core server and use the reference metamodels 300A as is as the usage metamodels 300B, or can modify, add, or delete (customize) the reference metamodels 300A and use them as the usage metamodels 300B.

[0039] The concept of this design asset will be explained with reference to Fig. 5 to Fig. 7. Fig. 5 shows a reference metamodel 300A. In this example, the reference metamodel in the metamodel 300 is marked with the reference symbol 300A, and the reference metaclass in the metaclass 330 is marked with the reference symbol 330A. In the example of Fig. 5, the reference metamodel 300A includes a reference metaclass A 330A1, a reference metaclass B 330A2, and a reference metaclass C 330A3. The reference metamodel 300A is used by the utilization metamodel 300B shown in Fig. 6. In comparison with the reference metamodel 300A, the utilization metamodel in the metamodel 300 is marked with the reference symbol 300B, and the utilization metaclass in the metaclass 330 is marked with the reference symbol 330B. The user metamodel 300B includes a user metaclass A 330B1, a user metaclass B 330B2, and a user metaclass D 330B4.

[0040] In the usage metamodel 300B, the referenced metaclass A330A1 is used as is. This usage metaclass 330B is the usage metaclass A330B1. In the usage metamodel 300B, the referenced metaclass B330A2 is modified to become the usage metaclass B330B2. The modification is an improvement to the field b2. Note that a field is an element included in the metaclass 330. For example, when the metaclass is a user usage scenario US, the default setting condition PC, which is an example of the scenario, becomes a field. In the usage metamodel 300B, the referenced metaclass C330A3 of the referenced metamodel 300A is deleted and not used. Conversely, in the usage metamodel 300B, a metaclass 330 that was not present in the referenced metamodel 300A is added, and a new usage metaclass D330B4 is used.

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

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

[0043] In the examples of Figs. 5 and 6, the use meta class A330B1 has the presence / absence information 503 of the referencing meta class A330A1 set to "Present" and the invalidity information 504 set to "F". When the presence / absence information 503 is "Present", the referencing meta class 330A is identified using its ID, as will be described later in detail with reference to Fig. 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 use meta class B330B2 has the presence / absence information 503 set to "Present" to identify 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 the use meta class C330B3, the presence / absence information 503 for the referencing meta class C330A3 is "Present", but the invalidity information 504 is "T". This indicates that the use of the referencing meta class C330A3 is invalid for the use meta class C330B3, i.e., the use meta class C330B3 does not use the referencing meta class C330A3. Furthermore, for the use meta class D330B4, the presence / absence information for the referencing meta class 330A is set to "Absent". This indicates that the use meta class D330B4 does not reference the referencing meta class 330A, and was created in the use meta model 300B. Note that, because the use meta class D330B4 does not reference the referencing meta class 330A, there is no need to set the invalidity information 504 to "T", and it is set to "F".

[0045] As shown in Fig. 7, the use data structure 500 of the use metamodel 300B has change point information 520 in addition to use metaclass information 510. The change point information 520 indicates the changes made to the use metaclass 330B with respect to the reference metaclass 330A. In the examples of Figs. 5 and 6, the changes are that the field b2 of the use metaclass B 330B2 has been revised and that the reference metaclass C 330A3 has been deleted. Therefore, the changes are described in the change information 520 as modification information 505 and deletion information 506. Note that, in the examples of Figs. 5 and 6, the addition of the use metaclass D 330B4 is also a change, but the addition of the use metaclass D 330B4 is not included in the change point information 520. This is to avoid adding unnecessary information, since there is a one-to-one relationship between the use meta class D330B4 setting the presence / absence information 503 of the reference meta class 330A to "absent" in the use meta class information 510 and the "addition" of the use meta class D330B4.

[0046] In this manner, in the present disclosure, the user's designer can independently set 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, when designing the user metamodel 300B by customizing the reference metamodel 300A by modifying, adding, or deleting, the user can design the user metamodel 300B in exactly the same manner 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 use metamodel 300B. Furthermore, the changes made to the use metamodel 300B can be checked at any time. Therefore, it is possible to clarify the differences between the reference metaclass 330A and the use metaclass 330B, in terms of where and how the changes were made. Of course, it is also easy to undo the changes made to the use metamodel 300B.

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

[0049] As a reference example, Fig. 9 shows that the information in the using metamodel 300B is not reflected in the referencing metamodel 300A. This unreflected information is indicated by a dashed line in Fig. 9. That is, the using metaclass D330B4 added in the using metamodel 300B is not included in the changed referring metamodel 300A. Similarly, the referencing metaclass C330A3 deleted in the using metamodel 300B remains in the changed referring metamodel 300A, and the change to field b2 of the using metaclass B330B2 in the using metamodel 300B is not reflected.

[0050] 10 shows a 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 referencing metaclass information 560 indicating that the referencing metamodel 300A includes information on the referencing metaclasses A330A1 through D330A4.

[0051] In comparison with the reference metamodel 300A shown in Fig. 5, the reference metamodel 300A shown in Fig. 8 has an improvement to the field b1 of the reference metaclass B330A2 and an addition of the reference metaclass E330A25, but the reference data structure 550 does not have any special change point information. This is because the reference data structure 550 has the version information 552, and the change points can be grasped by using the version information 552. For example, if the reference metamodel 300A in Fig. 5 is version 1.1 and the reference metamodel 300A in Fig. 8 is version 1.3, the improvement to the field b1 of the reference metaclass B330A2 and the addition of the reference metaclass E330A5 can be grasped by comparing the version 1.1 and the version 1.3.

[0052] In this way, when a new version of the referenced metamodel 300A, which is a design asset, is released, it is possible to check the contents of the update 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, when 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 leaving the contents customized in the user metamodel 300B intact.

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

[0054] The changes can be easily understood not only by the designer of the referencing metamodel 300A and the designer of the user metamodel 300B, but also by other designers. As described above, the 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 reference metamodel 300A and the use metamodel 300B has been conceptually explained above using FIG. 3 to FIG. 10. Although there is some overlap, a more detailed explanation will be given below based on a concrete example. First, the relationship between the metamodels 300 in system development will be explained. In FIG. 3 and FIG. 4, the relationship in system development has been roughly explained, but the relationship between the parts 51 and the cross domain 61 will be explained more specifically. In FIG. 11, a profile is used as a concept in which a view definition is added to the metamodel 300. The view definition is a definition of the display format of the view 307 such as a diagram, which will be described later using FIG. 20A to FIG. 20D. However, since the view definition is not used in this example, the profile in the following explanation has the same concept as the metamodel 300. In FIG. 11, the ADAS system 41 has a cruise control system development profile 530, an automobile standard development profile 531, a software requirements profile 532, and a software design profile 533.

[0056] In system development, the relationship between the profiles is also important. In Fig. 4 and Fig. 11, the cruise control system development profile 530 corresponds to the cross domain 61. The automobile standard development profile 531 corresponds to the system development, and the software requirements profile 532 and the software design profile 533 correspond to the parts 51. In this relationship, the relationship between the cruise control system development profile 530 and the automobile standard development profile 531 is such that the automobile standard development profile 531 is referenced in order to create the cruise control system development profile 530. Similarly, the software requirements profile 532 and the software design profile 533 are referenced in order to create the automobile standard development profile 531.

[0057] Therefore, in this example, the relationship between the profiles is specified. That is, the relationship between the cruise control system development profile 530 and the automobile standard development profile 531 is specified as automobile standard 534. Also, the relationship between the automobile standard development profile 531 and the software requirements profile 532 is specified as software requirements 535, and the relationship between the automobile standard development profile 531 and the software design profile 533 is specified as software design 536. In the example of FIG. 11, the version of the cruise control system development profile 530 is 1.0.0. Also, the version of the automobile standard development profile 531 is 1.5.0. And 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 the left, this list 540 is arranged in a column of profile ID 541, a column of name 542, and a column of 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 profile-part reference relationships. In this reference relationship table 545, from the left, a column of profile ID 546, a column of dependent profile ID 547, and a column of interrelationship 548 are arranged. In this reference relationship table 545, the relationships between the above-mentioned profiles are written in each row. From the top, automobile standards 534, software requirements 535, and software designs 536 are arranged.

[0060] 12, automotive standard 534 lists the ID of cruise control system development profile 530 in profile ID 546. And, 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 described above, in this example, the relationships between profiles (metamodels 300) are clearly defined. In FIG. 11, the relationships between profiles are visually represented by a diagram using arrows. Also, in FIG. 12, the relationships between profiles are defined in more detail using a table. In this way, by identifying 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, the design work of designing the destination metamodel 300B using the reference metamodel 300A will be described in more detail with reference to FIG. 13 and subsequent figures. FIG. 13 shows the metamodel 300 of the ADAS system 41. The requirement definition 110 is the system requirement 1101. The metaclass 330 of the system specification layer 1102, which defines what to do, has an ownership relationship with the metaclass 330 of the system requirement 1103, which defines the specific implementation of the system, and the metaclass 330 of the use case 1104, which defines which device does what. Hereinafter, the ownership relationship and other relationships will be omitted, and only the names of the metaclasses 330 will be described. The metaclasses 330 included in the system requirement 1101 include the system requirement 1105, the functional requirement 1106, the non-functional requirement 1107, the actor 1108, and the use case 1109. Although the same name may be used due to the relationship between the systems, the metaclasses 330 are distinguished by using 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 collectively organize related metaclasses 330 for easy 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. In the metamodel 300 of the system requirement 1101, the package frame 111 of the system requirement 1110 and the package frame 111 of the use case 1111 are shown.

[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 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. And, 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 the software requirement 2110, and this metamodel 300 includes the following metaclasses 330: metaclasses 330 of the software requirement definition 2111, the software requirement element 2112, the software requirement 2113, the functional requirement 2114, and the non-functional requirement 2115. The metamodel 300 of the software structure 2210 of the software basic design 220 includes the following metaclasses 330: metaclasses 330 of the software component 2211, the function 2212, the subfunction 2213, the data type 2214, the parameter 2215, and the data 2216. The metamodel 300 of the software behavior 2310 of the software detailed design 230 also includes a plurality of metaclasses 330: metaclasses 330 of the behavior 2311, the control sequence 2312, and the 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 the 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 operate the software actually designed in the software detailed design 230. This allows confirmation of whether the operation defined in the software specification definition 210 is obtained.

[0070] Fig. 15 shows an ADAS system 41, which uses the metamodel 300 for system development described in Fig. 13. That is, the metamodel 300 for the requirement definition 110 (system requirement 1101), the metamodel 300 for the logical design 120 and the control design 130 (system functional structure 1201), and the metamodel 300 for the physical design 140 (system physical structure 1401) are used. Therefore, in the ADAS system 41 shown in Fig. 15 and the ADAS system 41 shown in Fig. 13, the requirement definition 110 (system requirement 1101), the logical design 120 and the control design 130 (system functional structure 1201), and the physical design 140 (system physical structure 1401) of the ADAS system 41 shown in Fig. 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, and 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, in the ADAS system 41 shown in FIG. 15 and the cockpit module system 42 shown in FIG. 14, the software specification definition 210 (software requirement 2110), the software basic design 220 (software structure 2210), the software detailed design 230 (software behavior 2310), and the test process 240 (software test 2401) of the cockpit module system 42 shown in FIG. 14 become 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 testing process 240 (software testing 2401) of the ADAS system 41 shown in FIG. 15 become the user metamodel 300B.

[0072] When the user metamodel 300B is used, 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 requirement definition 110 (system requirement 1101) are linked by a derivation 304 relationship. This allows the contents of the software requirements 212 to be reflected in the system supply. In addition, it also becomes possible to trace design information across configurations.

[0073] In addition, the metaclass 330 of the software component 2211 of the metamodel 300 of the software basic design 220 (software structure 2210) is connected to the metaclass 330 of the system configuration element 1206 of the metamodel 300 of the logical design 120 and control design 130 (system functional structure 1201) and the metaclass 330 of the component 1402 of the metamodel 300 of the physical design 140 (system physical structure 1401) through a derivation 304 relationship. In this way, by connecting through 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 are 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 simplified to "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 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 a test environment is added to the metaclass 330 of the software test 2402.

[0077] This allows the metamodel 300 of the software development 200, 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. In addition, 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 the 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 the 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 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. Moreover, 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] Also, 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 output port and input port 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 a sensor is improved. The version is upgraded when it becomes possible to add information that can be supplied due to an improvement in the maximum transfer rate.

[0081] The upgraded ADAS system 41 described in Fig. 16 can also be used in the 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) is 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 of the system component input port 1403 and the system component output port 1404 are renamed to component input port 1403 and component output port input 1404, respectively, through customization. The functions of version 1.1 are also reflected in the user metamodel 300B, and metaclasses 330 of a device 1408, a sensor 1409, and an actuator 1410 are added. In addition, a change is made to the metaclasses 330 of the component input port 1403 and the component output port 1404 by adding a field 14031 and a field 14041.

[0083] In the example of Fig. 17, even if the metamodel 300 of the physical design 140 version 1.1 is used as the utilization metamodel 300B, no inconsistency occurs. However, depending on the customization of the utilization metamodel 300B and the contents of the upgrade of the referenced metamodel 300A, an inconsistency may occur in the utilization metamodel 300B. In that case, the update of the referenced metamodel 300A is given priority, and the upgraded metamodel 300 is used as the utilization 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 which the referenced meta class B 330A2 is deleted in Figure 8. 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 meta class B 330A2 takes precedence. This is what is meant by the change on the update side (deletion of the referenced meta class B 330A2) taking precedence. If an inconsistency (conflict) occurs with the customization content during the update, the update side is forcibly adopted, and the user is notified of this. The user can look at the notification result 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 of the quality requirement and a referencing metaclass US330A9 of the user scenario. 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 referring to the referencing metaclass QR metaclass 330A8. The referencing metaclass US330A9 of the user scenario includes a field PC of the existing situation.

[0086] 18, the consumer metamodel 300B modifies the referencing metaclass QR330A8 of the referencing metamodel 300A and uses it as the consumer metaclass NR330B8 of the non-functional requirement. The consumer metamodel 300B also adds the consumer metaclass RER330B10 of the resource efficiency requirement. Conversely, the referencing metaclass US330A9 of the referencing metamodel 300A is deleted from the consumer 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 the usage name information 501, and version 1.1 is entered in the usage version information 502. In the usage metaclass information 510, the reference source presence information 503 of the usage metaclass NR330B8 indicates that the reference source metaclass QR330A8 is "present", and the invalidity flag is "F" in the invalidity information 504. This indicates that the usage metaclass NR330B8 uses the reference source metaclass QR330A8. The reference of the usage metaclass RER330B10 is "not present" in the presence information 503. This indicates that the usage metaclass RER330B10 was added in the usage metamodel 300B. The reference source metaclass US330A9 is "present" in the presence information 503, and the invalidity flag is "T". This indicates that the usage metaclass US330B9 has been invalidated (deleted) in the usage metamodel 300B. Similarly, the invalidation flag for the field PC is also set to "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 in the user metamodel 300B.

[0089] The above description of FIG. 18 is substantially the same as the description of FIG. 5 to FIG. 7. Next, the use data structure 500 of FIG. 18 will be described in more detail with reference to FIG. 19A and FIG. 19B. FIG. 19A shows the use data structure 500 of the use meta model 300B in the form of a table. The table of the use meta class information 510 includes the element list shown on the left. That is, the element list is a part of the use meta class information 510, and the five columns from the left are arranged in the following order: a column of ID 511, a column of name 512, a column of type 513, a column of base ID 514, and a column of invalid flag 515. The use meta class 330B has four rows, which are, from the top, the use meta class RER330B10, the use meta class NR330B8, the use meta class US330B9, and the field PC of the use meta class 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 usage meta class information 510 distinguishes whether it is a meta class or 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 referencing meta class 330A does not exist in the usage meta class RER330B10, the base ID 514 is blank. The invalid flag 515 indicates the invalid information 504, and as described above, if it is "F", it is used, and if it is "T", it is deleted. The field PC of the usage meta class US330B9 is automatically deleted when the parent element usage meta class US330B9 is invalidated.

[0091] The change point information 520 of the user data structure 500 shown in FIG. 19B has the following five columns. The leftmost column is a change / deletion distinction 521, followed by a target ID 522, a change content 523, information before the change 524, and information after the change 525. The distinction 521 identifies whether it is a change or a 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 the metaclass. Therefore, the target ID 522 is the ID of the metaclass to be changed or deleted. The second line in FIG. 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 the deletion. This makes it easy to restore the deleted user metaclass US330B9.

[0092] When 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 Fig. 19B, the first line of target ID 522 is the use metaclass NR330B8, which is changed. Change content 523 of this use metaclass NR330B8 is a change in name. The name of before-change information 524 of use metaclass NR330B8 is "quality requirement," and the name of after-change information 525 is "non-functional requirement."

[0093] Returning to Figure 19A, usage metaclass information 510 of usage data structure 500 also includes a table listing 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 fields PC for usage metaclass US330B9.

[0094] For user metaclass 330B, additional information 517 includes a name and a judgment as to whether it is an abstract concept. The name of user metaclass RER330B10 is entered as "resource efficiency requirement" in added content 518, and the judgment 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 added content 518, and the abstract concept is marked "T" in added content 518, indicating that it is an abstract concept. Here, the name "non-functional requirement" is the name that was changed in post-change information 525 of change point information 520, and so the change is reflected in added content 518.

[0095] In the user metaclass US330B9, the name of additional information 517 is "user scenario" in added 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 added content 518. In the field PC, the name of additional information 517 is marked "existing situation" in added content 518. In the field PC, a lower limit and an upper limit are included in additional information 517, and are marked "1" in added content 518. This is also the same as in the referencing metaclass 330A.

[0096] The design support system of this example can display the design result in a plurality of formats as shown in FIG. 20A to FIG. 20D. In other words, the design support system of this example can input design information from a plurality of screens. It can also be expressed as a tree diagram 3071 as shown in FIG. 20B or as a tree grid 3073 as shown in FIG. 20D. The designer can appropriately select the view 307 that is easy to use according to each design need. To get an overview of the entire structure, the ER diagram 3070 shown in FIG. 20A is preferable, and to define the details of each item, the tabular document form 3072 shown in FIG. 20C is preferable. However, although the four types of views 307 shown in FIG. 20A to D are all examples that are easy to use in designing, the views 307 used in the design support tool of this example are not limited to these four types. Conversely, it is also possible to reduce the types of views 307 to less than four.

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

[0098] The design support tool of 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 an inconsistency and notifies the designer of the inconsistency, allowing the designer to easily correct it 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] Although the above example is a desirable use example 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 metamodel 300 of another system, such as the cockpit module system 42, was used as the reference metamodel 300A of the ADAS system 41. This is a usage method that follows recent trends. However, it is of course acceptable to use the metamodel 300 of the same system as the reference metamodel 300A depending on the situation.

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

[0101] In addition, customization of the metaclasses 330 in the user metamodel 300B by changing, adding, or deleting them is a desirable use example for enhancing the usefulness of the design support system of the present disclosure. However, the design support system of the present disclosure only needs to be customizable, and this customization is not essential 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 for use 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. It is of course possible to use the system for the development of other systems, and it is also possible to use the system for non-automotive applications.

[0103] The design aspects of system development 100 are generally defined as a requirements definition 110, a logical design 120, a control design 130, and a physical design 140, while the design aspects of software development 200 are generally defined as a software specification definition 210, a software basic design 220, and a software detailed design 230, although other definition methods may be used. This example also shows an example in which a test 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 some relationships may be deleted depending on the usage form. 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 described above, the design support system 1 in this specification may also be called an electronic control device. The control device or the design support system 1 is provided by an algorithm. The program may be distributed alone or as a storage medium in 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. Also, a computer-readable recording medium on which a design support program for causing a computer to realize the design support is recorded is also included.

[0106] (Disclosure of technical ideas) This specification discloses multiple technical ideas described in the following multiple dependent claims. Some of the claims may be described in a multiple dependent form, where the subsequent claim alternatively refers to the preceding claim. Furthermore, some of the claims may be described in a multiple dependent form, where the subsequent claim alternatively refers to the preceding claim. The claims described in these multiple dependent forms define multiple technical ideas.

[0107] (Technical thought 1) A design support tool for supporting design, comprising: defining a referencing metamodel by one or more referencing metaclasses, said referencing metamodel having a referencing data structure; The reference data structure includes reference name information indicating a name of the reference metamodel, reference version information indicating a version of the reference metamodel, and reference metaclass information indicating the contents of the reference 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 a name of the user metamodel, user version information indicating a version of the user metamodel, user metaclass information indicating a relationship between the user metaclass and the reference source metaclass, and change point information indicating a change point 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 not updated. Design support system.

[0108] (Technical thought 2) The destination metaclass information of the destination data structure includes presence / absence information indicating the presence or absence of the reference source metaclass referenced by the destination metaclass, and invalidity information indicating the validity or invalidity of the reference source metaclass. The presence / absence information includes ID information for identifying the referencing meta class if the referencing meta class exists. A design support system as described in 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 as described in Technical Concept 2.

[0110] (Technical Thought 4) When the use metamodel uses the reference metamodel, the reference metaclass is changed to the use metaclass, The destination meta class information of the destination data structure includes ID information for identifying the referencing meta class that is referred to by the destination meta class, and for validating the referencing meta class; The change point information of the destination data structure records the change contents between the reference metaclass and the destination metaclass in the change information. A design support system as described in technical concept 3.

[0111] (Technical Thought 5) When the use metamodel uses the reference metamodel, an addition is made to the reference metaclass to make it the use 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 use metamodel uses the reference metamodel, the reference metaclass is deleted, The destination meta class information of the destination data structure includes ID information for identifying the referencing meta class that is referred to by the destination meta class and for invalidating the referencing 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 referenced metamodel is changed after the use metamodel uses the referenced metamodel, the referenced data structure is updated; Based on the updated referencing 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, 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 data structure includes reference name information indicating a name of the reference metamodel, reference version information indicating a version of the reference metamodel, and reference metaclass information indicating the contents of the reference metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the reference metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating a name of the user metamodel, user version information indicating a version of the user metamodel, user metaclass information indicating a relationship between the user metaclass and the reference source metaclass, and change point information indicating a change point between the user metaclass and the reference source metaclass, When the destination metamodel uses the reference source metamodel, the design support program updates the destination data structure while leaving the reference source 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 data structure includes reference name information indicating a name of the reference metamodel, reference version information indicating a version of the reference metamodel, and reference metaclass information indicating the contents of the reference metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the reference metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating a name of the user metamodel, user version information indicating a version of the user metamodel, user metaclass information indicating a relationship between the user metaclass and the reference source metaclass, and change point information indicating a change point between the user metaclass and the reference source metaclass, When the destination metamodel uses the reference source metamodel, the design support program updates the destination data structure while leaving the reference source data structure unchanged. A computer-readable recording medium having recorded thereon the design support program for causing a computer to realize the design support. [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, comprising: A referencing metamodel (300A) is defined by one or more referencing metaclasses (330A), said referencing metamodel having a referencing data structure (550); This reference data structure includes reference name information (551) indicating the name of the reference metamodel, reference version information (552) indicating the version of the reference metamodel, and reference metaclass information (560) indicating the contents of the reference metaclass, A consumer metamodel (300B) is defined by one or more consumer metaclasses (330B), the consumer metamodel is capable of using 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 reference source metaclass, and change point information (520) 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 not updated. Design support system.

2. The destination metaclass information of the destination data structure includes presence / absence information (503) indicating the presence or absence of the reference source metaclass referenced by the destination metaclass, and invalidity information (504) indicating the validity or invalidity of the reference source metaclass. 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 use metamodel uses the reference metamodel, the reference metaclass is changed to the use metaclass, The destination meta class information of the destination data structure includes ID information for identifying the referencing meta class that is referred to by the destination meta class, and for validating the referencing meta class; The change point information of the destination data structure records the change contents between the reference metaclass and the destination metaclass in the change information. The design support system according to claim 3.

5. When the use metamodel uses the reference metamodel, an addition is made to the reference metaclass to make it the use 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 use metamodel uses the reference metamodel, the reference metaclass is deleted, The destination meta class information of the destination data structure includes ID information for identifying the referencing meta class that is referred to by the destination meta class and for invalidating the referencing 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 referenced metamodel is changed after the use metamodel uses the referenced metamodel, the referenced data structure is updated; Based on the updated referencing 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, 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 data structure includes reference name information indicating a name of the reference metamodel, reference version information indicating a version of the reference metamodel, and reference metaclass information indicating the contents of the reference metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the reference metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating a name of the user metamodel, user version information indicating a version of the user metamodel, user metaclass information indicating a relationship between the user metaclass and the reference source metaclass, and change point information indicating a change point between the user metaclass and the reference source metaclass, When the destination metamodel uses the reference source metamodel, the design support program updates the destination data structure while leaving the reference source 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 data structure includes reference name information indicating a name of the reference metamodel, reference version information indicating a version of the reference metamodel, and reference metaclass information indicating the contents of the reference metaclass, the design support program defines a user metamodel by one or more user metaclasses, the user metamodel can use the reference metamodel, and the user metamodel has a user data structure; The user data structure includes user name information indicating a name of the user metamodel, user version information indicating a version of the user metamodel, user metaclass information indicating a relationship between the user metaclass and the reference source metaclass, and change point information indicating a change point between the user metaclass and the reference source metaclass, When the destination metamodel uses the reference source metamodel, the design support program updates the destination data structure while leaving the reference source data structure unchanged. A computer-readable recording medium having recorded thereon the design support program for causing a computer to realize the design support.

Images