Electronic and electrical development architecture management method, system and platform

Abstract

The invention discloses an electronic and electrical development architecture management method, system and platform. According to the scheme, text description data of a target development architecture is obtained; and based on the text description data, generating a logic association graph of architecture elements in the target development architecture. And defining an architecture metadata rule of the target development architecture based on the logical association graph. And instantiating and generating a structured development architecture model according to the architecture metadata rule. According to the technical scheme, accurate capture and visual presentation of the complex relation in the electronic and electrical system are achieved, the limitation of a traditional text document in the aspect of expression of structured information is effectively overcome, the management efficiency of an automobile electronic and electrical development architecture is improved, the data processing performance is optimized, and the development efficiency of the electronic and electrical system is improved. And powerful support is provided for development, design and maintenance of an automobile electronic and electrical system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automotive electronics and electrical technology, in particular to an electronic and electrical development architecture management method, system and platform. BACKGROUND

[0002] With the increasing complexity and integration of automotive electronic control units (ECU), there is a higher demand for effective management and efficient collaboration of development architectures. Currently, the representation method of automotive electronic and electrical development architectures mainly relies on traditional text document management methods, such as Excel spreadsheets, etc. However, text documents have limited ability to express structured information and often can only present data in the form of icons or plain text, making it difficult to fully demonstrate the complex structure and relevance of automotive electronic and electrical architectures.

[0003] With the development of automotive electronic and electrical systems, the amount of data has increased dramatically, and the readability and maintainability of text documents face serious challenges. In the case of large amounts of data, updating, querying and maintaining text files becomes difficult, affecting development efficiency.

[0004] In addition, text documents have low performance and efficiency when handling large-scale data, making it difficult to meet the demand of modern automotive ECU scale growing exponentially every year. At the same time, since automotive electronic and electrical development requires collaboration between multiple departments, text documents are prone to version inconsistencies and poor real-time communication when transmitted between departments, seriously affecting collaboration efficiency. SUMMARY

[0005] Based on the above problems, the present application provides an electronic and electrical development architecture management method, system and platform, aiming to improve the management efficiency of automotive electronic and electrical development architecture, the performance of data processing and the collaborative efficiency between multiple departments.

[0006] The present application embodiment discloses the following technical solutions:

[0007] The first aspect of the present application provides an electronic and electrical development architecture management method, which comprises:

[0008] obtaining text description data of a target development architecture;

[0009] generating a logical association graph of architecture elements in the target development architecture based on the text description data;

[0010] defining architecture metadata rules of the target development architecture based on the logical association graph; the architecture metadata rules include architecture element type rules, element connection relationship type rules and attribute type rules;

[0011] According to the architecture metadata rule, a structured development architecture model is instantiated.

[0012] In an optional implementation, the generating the logical association graph of the architecture elements in the target development architecture based on the text description data comprises:

[0013] Determining the hierarchical relationship and the association manner between the architecture elements in the target development architecture based on the text description data;

[0014] Generating the logical association graph based on the hierarchical relationship and the association manner between the architecture elements.

[0015] In an optional implementation, the logical association graph comprises element nodes, element node connection relationships, and element node attribute requirements.

[0016] The defining the architecture metadata rule of the target development architecture based on the logical association graph comprises:

[0017] Defining an architecture element type based on the element nodes in the logical association graph, and configuring an element type identifier and an element type name for each architecture element type to obtain an architecture element type rule;

[0018] Defining a connection relationship type rule between the architecture element types based on the element node connection relationships in the logical association graph, comprising an upstream element type, a downstream element type, and a connection relationship name;

[0019] Defining an attribute type rule based on the element node attribute requirements in the logical association graph, comprising an attribute name and an attribute data type; a value of the attribute is dynamically assigned in an instantiation stage according to the attribute data type.

[0020] In an optional implementation, the instantiating a structured development architecture model according to the architecture metadata rule comprises:

[0021] Instantiating the architecture element types in a hierarchical and dependent order according to the architecture element type rule and the connection relationship type rule between the element types, and establishing a connection relationship between the architecture element types;

[0022] Assigning an instantiated attribute value to an attribute type of each architecture element type according to the attribute type rule, to generate a structured development architecture model.

[0023] The second aspect of the application provides an electronic and electrical development architecture management system, which comprises:

[0024] A data acquisition module configured to acquire text description data of a target development architecture;

[0025] a graph generating module configured to generate a logical association graph of the architecture elements in the target development architecture based on the text description data;

[0026] a rule defining module configured to define architecture metadata rules of the target development architecture based on the logical association graph; the architecture metadata rules include architecture element type rules, element connection relationship type rules, and attribute type rules;

[0027] an architecture generating module configured to generate a structured development architecture model according to the architecture metadata rules.

[0028] In an optional implementation, the graph generating module includes:

[0029] a determining unit configured to determine a hierarchical relationship and an association manner among the architecture elements in the target development architecture based on the text description data;

[0030] a generating unit configured to generate a logical association graph based on the hierarchical relationship and the association manner among the architecture elements.

[0031] In an optional implementation, the logical association graph includes element nodes, element node connection relationships, and element node attribute requirements.

[0032] The rule defining module includes:

[0033] a first defining unit configured to define architecture element types based on the element nodes in the logical association graph, and configure an element type identifier and an element type name for each architecture element type to obtain the architecture element type rules;

[0034] a second defining unit configured to define connection relationship type rules among the architecture element types based on the element node connection relationships in the logical association graph, including an upstream element type, a downstream element type, and a connection relationship name;

[0035] a third defining unit configured to define attribute type rules based on the element node attribute requirements in the logical association graph, including an attribute name and an attribute data type; a value of the attribute is dynamically assigned according to the attribute data type in an instantiation stage.

[0036] In an optional implementation, the architecture generating module includes:

[0037] an architecture instantiation unit configured to instantiate the architecture element types layer by layer in a hierarchical dependency order according to the architecture element type rules and the element connection relationship type rules, and establish connection relationships among the architecture element types;

[0038] An attribute assignment unit is configured to assign instantiated attribute values to attribute types of each architecture element type according to the attribute type rules, and generate a structured development architecture model.

[0039] The third aspect of the present application provides an electronic and electrical development architecture management platform, which is used to implement the electronic and electrical platform architecture management method according to any one of the implementation manners of the first aspect. The platform comprises:

[0040] A meta-model end is configured to define architecture metadata rules of a target development architecture.

[0041] A model instantiation end is configured to instantiate a structured development architecture model based on the architecture metadata rules defined by the meta-model end.

[0042] In an optional implementation manner, the model instantiation end supports a visual display function and provides an interactive operation interface.

[0043] Compared with the prior art, the present application has the following beneficial effects:

[0044] In the technical solution of the present application, by obtaining text description data of a target development architecture and generating a logical correlation graph of architecture elements based on the data, the complex relationships and correlations between various elements in the electronic and electrical development architecture can be clearly presented, and the limitations of traditional text documents in expressing structured information are effectively overcome. Further, the architecture metadata rules are defined based on the logical correlation graph, and a structured development architecture model is instantiated based on the rules, which not only improves the consistency and accuracy of the data, but also greatly improves the development efficiency. The structured model enables developers to more quickly understand and locate the architecture elements, facilitates modification and expansion, and also provides a unified and clear working basis for multiple departments, promoting cooperation between departments. In addition, the technical solution of the present application can efficiently process large-scale data, adapt to the growing needs of modern automotive electronic ECU, and provide strong support for the management and optimization of electronic and electrical development architecture. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0046] Figure 1 A flowchart of an electronic and electrical development architecture management method provided by the embodiments of the present application is shown in the figure.

[0047] Figure 2Another electronic and electrical development architecture management method flowchart provided by the embodiment of the present application;

[0048] Figure 3 A logical association graph provided by the embodiment of the present application;

[0049] Figure 4 A structural diagram of an electronic and electrical development architecture management system provided by the embodiment of the present application;

[0050] Figure 5 A structural diagram of an electronic and electrical development architecture management platform provided by the embodiment of the present application. DETAILED DESCRIPTION

[0051] As described above, the current electronic and electrical development architecture management method mainly relies on traditional text documents such as Excel tables, which is not enough to deal with the complexity and integration of modern automotive electronic systems. Text documents have limited ability to express structured information and are difficult to fully display the complex structure of the architecture and the association between elements, resulting in reduced readability and maintainability of the information. With the explosive growth of data, updating, querying and maintaining text documents becomes increasingly difficult, seriously affecting development efficiency. At the same time, when dealing with large-scale data, the performance and efficiency of text documents are obviously insufficient, and cannot meet the demand of rapid growth of automotive electronic ECU scale. In addition, when multiple departments cooperate, text documents are prone to cause version inconsistency, poor real-time communication and other problems, further hindering the improvement of cooperation efficiency. Therefore, it is urgent to develop a more efficient and more structured development architecture management method.

[0052] The inventor has proposed an electronic and electrical development architecture management method, system and platform.

[0053] First, the text description data of the target development architecture is obtained; then the logical association graph of the architecture elements in the target development architecture is generated based on the text description data; thereafter, the architecture metadata rules of the target development architecture are defined based on the logical association graph; finally, the structured development architecture model is generated according to the architecture metadata rules.

[0054] In order for those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0055] Reference Figure 1FIG. 1 is a flowchart of an electronic and electrical development architecture management method according to an embodiment of the present application. As shown in the figure, the method comprises the following steps: Figure 1

[0056] S101: Obtain text description data of a target development architecture.

[0057] In the embodiments of the present application, the target development architecture refers to an electronic and electrical development architecture to be managed. The text description data refers to development architecture related information recorded in the form of text.

[0058] In an example implementation, the text description data of the target development architecture can be obtained from design documents, technical specifications, user requirement documents, etc. The text description data records the functions, interfaces, interaction modes and overall design ideas of the elements in the target development architecture.

[0059] Obtaining the text description data of the target development architecture is the basis for subsequent management of the target development architecture, and its accuracy and integrity directly affect the generation of the subsequent logical association graph and the definition of the architecture metadata rules.

[0060] Optionally, in order to ensure the reliability and accuracy of the obtained text description data, the obtained text description data can be preliminarily checked and arranged.

[0061] For text description data in different formats, such as Word documents, Excel tables, etc., they can be uniformly converted into a processable format, such as JSON or XML, and the specific format is not limited here.

[0062] Optionally, the arranged text description data is stored in a database for subsequent access and processing.

[0063] S102: Generate a logical association graph of the architecture elements in the target development architecture based on the text description data.

[0064] In the embodiments of the present application, the architecture elements refer to the basic units constituting the electronic and electrical development architecture. The logical association graph is used to show the logical association relationship between the architecture elements.

[0065] In an example implementation, the obtained text description data can be analyzed in depth by using natural language processing (NLP) and graph algorithms, and the architecture elements and their logical association relationship can be identified and extracted. Then, the logical association graph can be constructed according to the logical association relationship.

[0066] This step can make the structural element information originally scattered in the text description data structured and displayed, which is convenient for subsequent management. ​

[0067] S103. Define the architecture metadata rules of the target development architecture based on the logical association graph.

[0068] In the embodiment of the present application, the architecture metadata rules refer to the rules that describe the architecture elements and their connection relationships and attributes, and are the basis for model instantiation.

[0069] Based on the logical association graph generated in the previous step, you can further define schema metadata rules. Schema metadata rules include schema element type rules, inter-element connection relationship type rules, and attribute type rules. Schema metadata rules provide clear guidance for subsequent model instantiation.

[0070] S104. Generate a structured development architecture model based on instantiation of architecture metadata rules.

[0071] In the embodiment of the present application, the architecture metadata rules defined in the aforementioned steps can be converted into specific, operational model instances using modeling tools or programming languages.

[0072] The structured development architecture model generated in this step not only contains all the key information of the electronic and electrical development architecture, but also has good scalability and maintainability, which greatly facilitates subsequent development, testing and maintenance work.

[0073] In an embodiment of the present application, by obtaining text description data of the target development architecture and generating a logical association map of the architecture elements based on this data, the complex relationships and correlations between the various elements in the electronic and electrical development architecture can be clearly displayed, effectively overcoming the limitations of traditional text documents in expressing structured information. Furthermore, by defining architecture metadata rules based on the logical association map and instantiating and generating a structured development architecture model based on this, not only the consistency and accuracy of the data are improved, but also the development efficiency is greatly improved. The structured development architecture model enables developers to understand and locate architecture elements more quickly, facilitating modification and expansion, while also providing a unified and clear working foundation for multiple departments, promoting collaboration and cooperation between departments. In addition, it can efficiently process large-scale data, adapt to the growing scale of modern automotive electronic ECUs, and provide strong support for the management and optimization of electronic and electrical development architectures.

[0074] Figure 2 This is a flow chart of another electronic and electrical development architecture management method provided in an embodiment of the present application. In the embodiment introduced by this figure, a more detailed description is provided for the implementation of the electronic and electrical development architecture management method.

[0075] like Figure 2 The illustrated method for managing the architecture of electronic and electrical development includes the following steps:

[0076] S201, acquire text description data of a target development architecture.

[0077] S201 is basically the same as the implementation of S101 in the method embodiments described above, and details are not repeated here. For related technical implementations, refer to the description of S101 above.

[0078] For ease of understanding, Table 1 shows an example of text description data of the signal transmission relationship between electronic control units (ECUs) in an actual production scenario.

[0079] Table 1

[0080] Signal ECU Component ADT Name Direction Protocol S1 ADM PoLC Gnm_Pld IN TCP S1 ADM MoLC Gnm_Pld OUT TCP S2 DOM HurLC Kolpd IN UDP S2 RUM RmpELC Kolpd OUT UDP S3 ADM PoLC Rtdf OUT UDP S4 DOM HurLC Dgrgg OUT UDP S5 DOM HurLC Cvhrt OUT TCP

[0081] As shown in Table 1, the Signal column is the name of the signal, the ECU column is the electronic control unit associated with each signal, the Component column is further refined to a specific component in the electronic control unit (it should be noted that one electronic control unit can contain multiple components, and each signal will be processed through a certain specific component), the ADT Name column gives the name of the application data type (ADT) used by the signal actual transmission data, the Direction column specifies the direction of the signal (where IN indicates that the signal is a received signal, and OUT indicates that the signal is a transmitted signal), and the Protocol column is the protocol stack information related to each signal.

[0082] S202, determine the hierarchical relationship and association manner between the architecture elements in the target development architecture based on the text description data.

[0083] In the embodiments of the present application, the hierarchical relationship and association manner between the architecture elements in the target development architecture can be determined based on the text description data acquired in the previous step.

[0084] Taking the text description data shown in Table 1 as an example, since the number of ECU included therein is large, a layer of electronic control unit management layer (referred to as ECU Level) is designed as a hierarchical layer for overall management of various electronic control units. The electronic control unit layer is a mapping of various ECUs (such as ADM, DOM, etc.) listed in Table 1, ensuring that each ECU can be clearly positioned in the architecture.

[0085] Each ECU contains multiple Components, which are the basic units of ECU functions. Therefore, the Component layer is further divided under the ECU layer to depict the internal structure of the ECU. Each Component is equipped with multiple Signals, which are responsible for signal reception and transmission. Therefore, the Signal Interface layer is designed under the Component layer.

[0086] The Direction and Protocol columns in Table 1, as basic attributes of the signal, represent the signal transmission direction and the adopted protocol stack, respectively, and are crucial for a comprehensive understanding of the signal characteristics. Therefore, these two types of information (i.e., signal transmission direction and signal transmission protocol stack) are integrated into the Signal Interface layer, making the signal characteristic description more complete and accurate.

[0087] In addition, ADT plays the role of an actual data carrier in signal transmission and has reusability and independence. To highlight the importance of ADT and clearly show its function in signal transmission, an Application Data Type layer is added under the Signal Interface layer. In this way, the Application Data Type layer not only identifies the actual data type transmitted by the signal, but also makes the hierarchical relationship of the entire development architecture more clear and reasonable.

[0088] S203, generating a logical association graph based on the hierarchical relationship and association mode between the architecture elements.

[0089] In the embodiments of the present application, the logical association graph includes element nodes, element node connection relationships, and element node attribute requirements.

[0090] The element nodes in the logical association graph correspond to the architecture elements in the development architecture, such as ECU, Component, Signal, and ADT, each of which occupies an independent position in the graph and represents a different level and entity in the architecture.

[0091] The element node connection relationship reflects the interaction and dependence between the architecture elements. For example, the ECU node is connected to the Component node, indicating that the ECU contains multiple Components; the Component node is connected to the Signal node, showing that the Component is responsible for processing a specific signal; and the Signal node is connected to the ADT node, revealing the data type on which the signal transmission depends.

[0092] The element node attribute requirement (Attribute) specifies the attribute information of each element. For example, the Direction attribute requirement of the Signal node specifies the signal transmission direction, and the Protocol attribute requirement specifies the protocol stack adopted by the signal transmission.

[0093] Taking the ECU signal interaction data shown in Table 1 as an example, the corresponding logical association graph diagram is shown in FIG. 1, and the specific construction logic is as follows: Figure 3

[0094] The top layer of the graph is the electronic control unit management layer, which is the overall management unit of the entire architecture. The lower layer is the electronic control unit layer, which integrates all ECUs, such as Architecture Definition Model (ADM), Design Object Model (DOM), Runtime Unified Model (RUM), etc., to ensure that each ECU can work in an orderly manner in the architecture.

[0095] Then comes the component layer, which is associated with the electronic unit layer. Each ECU is further divided into multiple components, such as PoLC and MoLC components in ADM, which together support the functions of the ECU.

[0096] Further down is the signal interface layer, which is located below the component layer. This layer defines the signal interface for each component, such as the S1 and S3 signals in the PoLC component, and details the signal transmission direction and signal transmission protocol stack attributes to fully describe the signal characteristics.

[0097] The bottom layer is the application data type layer, which is connected to the signal interface layer. This layer binds each signal with the corresponding application data type, such as the Gnm_Pld data type for the S1 signal, which supports data multiplexing and ensures the independence of data types, providing a solid foundation for signal transmission and processing.

[0098] It should be noted that Figure 3 The logical association graph diagram shown is only presented in the form of an example. In actual operation, the specific form of the logical association graph diagram can be flexible and varied to adapt to different application scenarios and needs. It can be adjusted and optimized according to the complexity of the actual system, the preferences of the development team, and the specific specifications of the project. For example, the hierarchical structure of the graph can be more detailed or simplified, the connection between nodes can be changed, or even different graphical symbols or color coding can be used to enhance the readability and intuitiveness of the graph. In summary, the form of the logical association graph is not fixed and should be flexibly designed and adjusted according to actual conditions.

[0099] In the embodiments of the present application, by constructing the logical association graph, the multi-level relationship can be intuitively presented, effectively overcoming the flatness limitation of traditional text description, helping to deeply understand the architecture composition and operation mechanism, and providing strong support for subsequent design, development and maintenance work.

[0100] ​S204, defining an architecture element type based on the element nodes in the logical association graph, and configuring an element type identifier and an element type name for each architecture element type to obtain an architecture element type rule.

[0101] In the embodiments of the present application, the element type identifier can be a string of non-repetitive characters composed of letters (which can also contain numbers or special symbols). To ensure that each architecture element type can be uniquely identified and recognized in the system.

[0102] Specifically, the composition of the element type identifier can follow certain naming rules or conventions, which can be based on the specific needs of the project, the naming habits of the team or industry standards. For example, the identifier can contain an abbreviation of the element type, a fragment of the name or a specific coding sequence to ensure that it is both descriptive and easy to understand and remember. The specific rules are not limited here.

[0103] Table 2 is a schematic table of an architecture element type rule.

[0104] Table 2

[0105] Element Type Name Element Type Identifier SW-ECU SW_ECU_Type Software Component SWC_Type Signal Interface SIG_INTF_Type ADT ADT_Type ECU Level ECU_LVL_Type

[0106] S205, defining a connection relationship type rule between each architecture element type based on the connection relationship of the element nodes in the logical association graph, including an upstream element type, a downstream element type and a connection relationship name.

[0107] The upstream element type refers to the element type that is the starting point of the connection relationship in the logical association graph, representing the source of initiative, precondition or control.

[0108] The downstream element type refers to the element type that is the end point of the connection relationship in the logical association graph, representing the passive side, postcondition or control of the receiving side.

[0109] The connection relationship name refers to the name describing the specific logical relationship between the upstream and downstream elements.

[0110] In the embodiments of the present application, the connection relationship between each architecture element node can be determined based on the logical association graph. For each identified connection relationship, a connection relationship name is defined so that it can be clearly referenced in subsequent design, development and maintenance.

[0111] Table 3 is a schematic table of a connection relationship type rule.

[0112] Table 3

[0113] Connection Relationship Name Upstream Element Type Downstream Element Type SW-ECU Link ECU-Level SW-ECU Software Component Link SW-ECU Software Component Signal Interface Link Software Component Signal Interface ADT Link Signal Interface ADT

[0114] In Table 3, ECU-Level is an ECU management level; SW-ECU is an ECU software layer, which refers to a software system running on an ECU hardware; Software Component is a software component, which refers to a functional modular unit in ECU software, corresponding to a single or combined function; Signal Interface is a signal interface, which refers to a signal transmitted between software components or between a component and an underlying layer; and ADT is an abstract data type, which is used for standardized type definition of data in the signal interface.

[0115] As shown in Table 3, the ECU-Level and the SW-ECU are connected through the SW-ECU Link, indicating a management binding relationship; the SW-ECU and the Software Component are connected through the Software Component Link, indicating a software component integration relationship; the Software Component and the Signal Interface are connected through the Signal Interface Link, indicating that the software component exchanges data through the signal interface; and the Signal Interface and the ADT are connected through the ADT Link, indicating a data type binding relationship.

[0116] In the embodiments of the present application, by defining these connection relationship type rules, the interaction mode between various element types in the architecture can be more clearly understood, thereby providing strong support for subsequent design, development and maintenance work.

[0117] In S206, attribute type rules are defined based on the element node attribute requirements in the logical association graph, including attribute names and attribute data types.

[0118] In the embodiments of the present application, various attribute types are defined based on the element node attribute requirements in the logical association graph. The attribute type rules include attribute names and attribute data types. The values of the attributes will be dynamically assigned in the instantiation phase according to the data types. For example, the "Direction" attribute can be defined to represent a signal transmission direction, and its data type is a string (String). Its value (such as "IN" or "OUT") is dynamically assigned in the instantiation phase according to the signal transmission direction. The "Protocol" attribute can be defined to represent a signal transmission protocol, and its data type is a string (String).

[0119] In the embodiments of the present application, the attribute type rules are used to define various features, which are used by the architecture element types and the connection relationship types.

[0120] Table 4 is a table of attribute type rules used by the architecture element types.

[0121] Table 4

[0122]

[0123] S207、According to the architecture element type rules and the element interconnection relationship type rules, the architecture element types are instantiated layer by layer in the hierarchical dependency order, and the connection relationship between the architecture element types is established.

[0124] According to the architecture element type rules and the element interconnection relationship type rules in the foregoing example, one ECU Level element is first instantiated as the top node of the model for unified management of all ECU units.

[0125] Three SW-ECU elements, ADM, DOM and RUM, are instantiated.

[0126] Three SW-ECU links are created under the ECU Level node, respectively pointing to the three ECU nodes.

[0127] Four Software Component nodes are instantiated, respectively named MoLC, PoLC, HurLC and RmpELC.

[0128] Two Software Component links are created under the ADM, respectively connected to MoLC and PoLC; one Software Component link is created under the DOM connected to HurLC; and one Software Component link is created under the RUM connected to RmpELC.

[0129] Seven Signal Interface (2 S1, 2 S2, 1 S3, 1 S4 and 1 S5) are instantiated.

[0130] One Signal Interface link is created under MoLC connected to the first S1; two Signal Interface links are created under PoLC connected to the second S1 and S3 respectively; three Signal Interface links are created under HurLC connected to the first S2, S4 and S5 respectively; and one Signal Interface link is created under RmpELC connected to the second S2.

[0131] Five ADT elements are instantiated, respectively named Gnm_Pld, Kolpd, Rtdf, Dgrgg and Cvhrt.

[0132] An ADT Link is created to connect to Gnm_Pld under S1 signal; an ADT Link is created to connect to Kolpd under S2 signal; an ADT Link is created to connect to Rtdf under S3 signal; an ADT Link is created to connect to Dgrgg under S4 signal; an ADT Link is created to connect to Cvhrt under S5 signal.

[0133] In S208, according to the attribute type rules, attribute values are assigned to the attribute types of each architecture element type, and a structured development architecture model is generated.

[0134] In the embodiments of the present application, based on the attribute type rules defined in the foregoing steps, the abstract attribute types are converted into specific and operable attribute values, thereby generating a structured development architecture model.

[0135] For example, for a signal (Signal) type architecture element, its Direction and Protocol attributes may need to be assigned values. The Direction attribute of the S3 node can be assigned a value of "OUT", indicating that the signal is an output signal; the Protocol attribute can be assigned a value of "UDP", indicating that the signal uses the UDP protocol for transmission.

[0136] In the embodiments of the present application, after assigning attribute values to the attribute types of all architecture element types, these information is integrated together to form a structured development architecture model. This model can clearly show the architecture element types, their attributes, connection relationships, etc., and can facilitate subsequent design, development and maintenance work.

[0137] In an example implementation, the attribute types of the architecture element types can be automatically or semi-automatically assigned values through programming or configuration tools. For example, a script or configuration file can be written to specify the Direction and Protocol attribute values of each signal.

[0138] Optionally, after generating the structured development architecture model, model verification can be performed to ensure the accuracy and integrity of the model. The verification content includes the correctness of element types, connection relationships and attribute values, the consistency and integrity of the model, etc.

[0139] In an example implementation, model verification tools or custom verification scripts can be used to perform these verification tasks.

[0140] Optionally, the structured development architecture model that passes the verification is stored in a database for subsequent management and query. Visualization display functions are provided, such as using a graphical interface or a web interface to display the structure and attributes of the model, to facilitate user viewing and operation. The intelligibility and usability of the model can be improved, and communication and cooperation among teams are promoted.

[0141] The embodiments of the present application significantly improve the development architecture management efficiency by efficiently converting from text description data to a structured development architecture model, and ensure the accuracy and integrity of the development architecture model by defining detailed attribute type rules and performing model verification, avoiding development problems caused by model errors. At the same time, the structured model improves the maintainability of the system, making maintenance easier, and the visualization display function further enhances the intelligibility and usability of the model, promoting communication and cooperation among teams. In addition, the method also supports flexible expansion, which can easily cope with future system changes and new requirements, and improves the understanding of the overall architecture and operation mechanism of the development team, providing strong support for the development, design and maintenance of electronic and electrical systems.

[0142] Based on the electronic and electrical development architecture management method provided in the foregoing embodiments, the present application also provides an electronic and electrical development architecture management system. Figure 4 A structural schematic diagram of an electronic and electrical development architecture management system provided by an embodiment of the present application is shown in FIG. 4. Figure 4 As shown in FIG. 4, the electronic and electrical development architecture management system includes a data acquisition module 401, a graph generation module 402, a rule definition module 403 and an architecture generation module 404.

[0143] The data acquisition module 401 is configured to acquire text description data of a target development architecture.

[0144] The graph generation module 402 is configured to generate a logical association graph of architecture elements in the target development architecture based on the text description data.

[0145] The rule definition module 403 is configured to define architecture metadata rules of the target development architecture based on the logical association graph. The architecture metadata rules include architecture element type rules, element connection relationship type rules and attribute type rules.

[0146] The architecture generation module 404 is configured to generate a structured development architecture model according to the architecture metadata rules.

[0147] In an optional implementation, the graph generation module includes a determination unit and a generation unit.

[0148] determining unit configured to determine a hierarchical relationship and a connection mode between architecture elements in the target development architecture based on the text description data;

[0149] generating unit configured to generate a logical connection graph based on the hierarchical relationship and the connection mode between the architecture elements.

[0150] In an optional implementation, the logical connection graph includes element nodes, element node connection relationships, and element node attribute requirements. The rule definition module includes a first definition unit, a second definition unit, and a third definition unit.

[0151] The first definition unit is configured to define an architecture element type based on an element node in the logical connection graph, and configure an element type identifier and an element type name for each architecture element type to obtain an architecture element type rule;

[0152] The second definition unit is configured to define a connection relationship type rule between architecture element types based on an element node connection relationship in the logical connection graph, including an upstream element type, a downstream element type, and a connection relationship name.

[0153] The third definition unit is configured to define an attribute type rule based on an element node attribute requirement in the logical connection graph, including an attribute name and an attribute data type; a value of the attribute is dynamically assigned in an instantiation stage according to the attribute data type.

[0154] In an optional implementation, the architecture generation module includes an architecture instantiation unit and an attribute assignment unit.

[0155] The architecture instantiation unit is configured to instantiate architecture element types layer by layer in a hierarchical dependency order according to the architecture element type rule and the element connection relationship type rule, and establish a connection relationship between the architecture element types.

[0156] The attribute assignment unit is configured to assign an instantiated attribute value to an attribute type of each architecture element type according to the attribute type rule, and generate a structured development architecture model.

[0157] The electronic and electrical development architecture management system in the embodiment of the application is constructed based on the electronic and electrical development architecture management method provided in the foregoing embodiment, and realizes automatic management and efficient collaboration of development architecture data. Through collaborative work of the data acquisition module, the graph generation module, the rule definition module, and the architecture generation module, conversion from text description data to a more efficient and more structured development architecture model can be completed.

[0158] In addition, the application further provides an electronic and electrical development architecture management platform for implementing the electronic and electrical development architecture management method provided in the foregoing embodiment. Figure 5A structural schematic diagram of an electronic and electrical development architecture management platform is provided in the embodiments of the present application. As shown in Figure 5 The electronic and electrical development architecture management platform comprises a meta-model end 501 and a model instantiation end 502.

[0159] The meta-model end 501 is configured to define architecture metadata rules of a target development architecture. The architecture metadata rules comprise element type rules, connection relationship type rules and attribute type rules. These rules are the basis for subsequent instantiation of a structured development architecture model.

[0160] Optionally, the meta-model end 501 can provide an intuitive and easy-to-use rule definition interface for a user to define the architecture metadata rules. The interface supports drag-and-drop operations for the user to quickly define element types, connection relationship types and attribute types and the like.

[0161] Optionally, the meta-model end 501 can check the rules defined by the user to ensure their correctness and integrity. A feedback mechanism is provided for the user to correct the rules that do not meet the requirements.

[0162] Optionally, the meta-model end 501 can store the defined architecture metadata rules in a database for subsequent access and processing. Meanwhile, the sharing function of the rules is supported to share and reuse the rule definition results among team members.

[0163] The model instantiation end 502 is configured to instantiate a structured development architecture model based on the architecture metadata rules defined by the meta-model end.

[0164] In the embodiments of the present application, the model instantiation end 502 instantiates the architecture element types and establishes the connection relationship according to the architecture metadata rules defined by the meta-model end 501 in a hierarchical and dependent order. Meanwhile, the attribute values of the attributes of the element types are assigned according to the attribute type rules to generate the structured development architecture model.

[0165] In an optional implementation manner, the model instantiation end 502 supports a visual display function and provides an interactive operation interface.

[0166] In the embodiments of the present application, the model instantiation end 502 can provide an intuitive visual interface for the user to view and operate the structured development architecture model. The interface supports multiple display modes such as tree graphs, relationship graphs and the like for the user to select a suitable display mode according to the needs. Meanwhile, the operations such as zooming, rotating and dragging are supported to enable the user to better understand and analyze the model structure.

[0167] The model instantiation end 502 provides an interactive interface for users to edit, modify and save the model, etc. The interface supports drag-and-drop operation to quickly adjust the model structure and attribute information. At the same time, it provides rich operation tools and prompt information to help users efficiently complete the model editing and management work.

[0168] Optionally, the model instantiation end 502 verifies and tests the generated structured development architecture model to ensure its accuracy and reliability. The verification content includes the correctness of element type, connection relationship and attribute value, the consistency and integrity of the model, etc. Feedback mechanism is provided for the model that does not meet the requirements to make corrections and optimization.

[0169] Optionally, the model instantiation end 502 supports the export and import functions of the model to share and reuse the model results between different systems. The export format supports multiple formats such as JSON, XML, etc. to allow users to choose the appropriate export method according to their needs. The import function supports importing existing models from other systems or tools to allow users to further edit and optimize the work based on the existing models.

[0170] The electronic and electrical development architecture management platform provided by the embodiments of the present application improves the readability and maintainability of the data by structuring the development architecture data, reduces the manual intervention and error rate, and improves the development architecture management efficiency. The intuitive visual interface and interactive operation interface are provided to facilitate the sharing and reuse of development architecture model results between different departments, and to promote efficient cooperation and communication between departments. The electronic and electrical development architecture management platform supports user-defined element type, connection relationship type and attribute type information, and supports multiple storage formats and display methods, etc. to allow users to flexibly select and extend the platform functions according to their needs.

[0171] It should be noted that each of the embodiments in the specification is described in a progressive manner, and the same and similar parts of each embodiment can be referred to each other. Each embodiment focuses on the difference from other embodiments. In particular, the system and platform embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the part of the method embodiment. The system and platform embodiments described above are only illustrative, and the units described as separate components can be or can not be physically separated, and the components prompted as units can be or can not be physical units, that is, they can be located in one place or distributed on multiple network units. According to the actual needs, some or all of the modules can be selected to achieve the purpose of the embodiments. Those skilled in the art can understand and implement without creative labor.

[0172] The above merely provides one specific embodiment of the present application, but the protection scope of the present application is not limited thereto, any changes or replacements within the technical scope disclosed by the present application, which can be easily thought by any person skilled in the art, should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for managing electronic and electrical development architecture, characterized in that: The method comprises: Get text description data of the target development architecture; Generating a logical association graph of architecture elements in the target development architecture based on the text description data; Defining the architecture metadata rules of the target development architecture based on the logical association graph; the architecture metadata rules include architecture element type rules, inter-element connection relationship type rules and attribute type rules; A structured development architecture model is instantiated and generated according to the architecture metadata rules.

2. The method according to claim 1, characterized in that Generating a logical association graph of architecture elements in the target development architecture based on the text description data includes: Determining the hierarchical relationship and association mode between various architecture elements in the target development architecture based on the text description data; A logical association graph is generated based on the hierarchical relationship and association method between the various architectural elements.

3. The method according to claim 1, characterized in that The logical association graph includes element nodes, element node connection relationships and element node attribute requirements; The architecture metadata rules for defining the target development architecture based on the logical association graph include: Defining architectural element types based on element nodes in the logical association graph, and configuring an element type identifier and an element type name for each architectural element type to obtain architectural element type rules; Based on the element node connection relationship in the logical association graph, define the connection relationship type rules between each architecture element type, including upstream element type, downstream element type and connection relationship name; Based on the attribute requirements of the element nodes in the logical association graph, attribute type rules are defined, including attribute names and attribute data types; the values ​​of the attributes are dynamically assigned according to the attribute data types during the instantiation phase.

4. The method according to claim 1, wherein The instantiating and generating a structured development architecture model according to the architecture metadata rules includes: According to the architectural element type rules and the inter-element connection relationship type rules, instantiate the architectural element types layer by layer in a hierarchical dependency order, and establish connection relationships between the architectural element types; According to the attribute type rules, the attribute type of each architecture element type is assigned an instantiated attribute value to generate a structured development architecture model.

5. An electronic and electrical development architecture management system, characterized in that: include: Data acquisition module, used to obtain text description data of the target development architecture; A graph generation module, configured to generate a logical association graph of the architecture elements in the target development architecture based on the text description data; A rule definition module, configured to define architecture metadata rules of the target development architecture based on the logical association graph; the architecture metadata rules include architecture element type rules, inter-element connection relationship type rules, and attribute type rules; The architecture generation module is used to instantiate and generate a structured development architecture model according to the architecture metadata rules.

6. The system according to claim 5, characterized in that The graph generation module includes: A determining unit, configured to determine, based on the text description data, the hierarchical relationship and association mode between the architecture elements in the target development architecture; A generating unit is used to generate a logical association graph based on the hierarchical relationship and association mode between the various architectural elements.

7. The system according to claim 5, characterized in that The logical association graph includes element nodes, element node connection relationships and element node attribute requirements; The rule definition module includes: A first definition unit is configured to define an architecture element type based on the element nodes in the logical association graph, and configure an element type identifier and an element type name for each architecture element type to obtain an architecture element type rule; A second definition unit is configured to define a connection relationship type rule between various architecture element types based on the element node connection relationship in the logical association graph, including an upstream element type, a downstream element type, and a connection relationship name; The third definition unit is used to define attribute type rules based on the element node attribute requirements in the logical association graph, including attribute name and attribute data type; the value of the attribute is dynamically assigned according to the attribute data type during the instantiation stage.

8. The system according to claim 5, wherein: The architecture generation module includes: An architecture instantiation unit, configured to instantiate architecture element types layer by layer in a hierarchical dependency order according to the architecture element type rules and the inter-element connection relationship type rules, and to establish connection relationships between architecture element types; The attribute assignment unit is used to assign instantiated attribute values ​​to the attribute types of each architecture element type according to the attribute type rules, so as to generate a structured development architecture model.

9. An electronic and electrical development architecture management platform, characterized in that: Used to implement the electronic and electrical platform architecture management method according to any one of claims 1 to 4, the platform comprising: The metamodel side is used to define the architecture metadata rules of the target development architecture; The model instantiation end is used to instantiate and generate a structured development architecture model based on the architecture metadata rules defined by the metamodel end.

10. The platform according to claim 9, characterized in that The model instantiation end supports visual display function and provides an interactive operation interface.

Images