A Metamodel Transformation Method

Abstract

The present invention provides a metamodel conversion method, which belongs to the field of vehicle technology, and includes: step S1, obtaining a configuration file of an automobile open system architecture; step S2, parsing the configuration file to obtain a memory object; step S3, converting the memory object to obtain object data, and storing the object data in a relational database. Beneficial effect: The present invention eliminates the dependence on the Java programming language and environment by converting and storing the parsed memory object in a relational database, realizes cross-environment data access and operation, significantly reduces the coupling between business logics, effectively alleviates the impact of AUTOSAR version changes, and thus greatly improves the scalability and overall performance of the system.

Description

Technical Field

[0001] The present invention relates to the field of vehicle technology, and in particular to a meta-model conversion method. Background Art

[0002] In the AUTomotive Open System Architecture (AUTOSAR) development environment, the Ecore model provided by the Eclipse Modeling Framework (EMF) is one of the mainstream tools for describing and managing AUTOSAR metamodels. The workflow of this tool is as follows: Figure 1 As shown in the figure, first, the developer uses the AUTOSAR Extensible Markup Language (ARXML) file to describe the specific AUTOSAR configuration; then, the ARXML file is parsed through the Ecore model to convert the configuration data into Java objects in the memory; finally, these Java objects are used in the Eclipse rich client platform to perform operations such as data verification and code generation.

[0003] Since the Ecore model is implemented based on the Java programming language, the entire development process from parsing to subsequent operations is strongly dependent on the Java environment, which undoubtedly increases the complexity of the development environment and the skill requirements for developers. The Ecore model stores the parsed AUTOSAR configuration data in the form of Java objects in memory. This memory data model is only convenient for internal operations of the program. Other programming languages ​​or platforms have difficulty directly accessing this data, and it cannot meet the requirements of persistent storage and cross-process access of data. Moreover, for large AUTOSAR projects, the Java object model in memory may become large, which in turn affects system performance.

[0004] In addition, with the continuous development and updating of the AUTOSAR standard, different versions of AUTOSAR may require different versions of the Ecore model, which leads to a strong coupling between all the logic of the development program and the AUTOSAR version, increasing the complexity of development and maintenance. Summary of the invention

[0005] In order to solve the above technical problems, the present invention provides a metamodel conversion method.

[0006] The technical problem solved by the present invention can be achieved by adopting the following technical solutions:

[0007] A metamodel conversion method, comprising:

[0008] Step S1, obtaining a configuration file of an automotive open system architecture;

[0009] Step S2, parsing the configuration file to obtain a memory object;

[0010] Step S3: convert the memory object to obtain object data, and store the object data in a relational database.

[0011] Preferably, the configuration file is a description file in an extensible markup language format.

[0012] Preferably, step S2 comprises:

[0013] Step S21, inputting the configuration file into a parsing model, parsing the configuration file through the parsing model to obtain one or more objects;

[0014] Step S22: store the one or more objects in the memory to obtain the memory object.

[0015] Preferably, the memory object is stored in the memory as temporary data.

[0016] Preferably, the object data includes the object type and attribute values ​​of the memory object.

[0017] Preferably, the step S3 comprises:

[0018] The object data of the memory object is serialized into the relational database.

[0019] Preferably, the step S3 further includes:

[0020] The object data of the memory objects and the association relationships between the memory objects are stored in the relational database.

[0021] Preferably, the step S3 further includes:

[0022] Step S4, obtaining the object data from the relational database;

[0023] Step S5: Process the acquired object data according to a preset logic to obtain a target file.

[0024] Preferably, the preset logic includes generation logic;

[0025] The step S5 includes: processing the acquired object data according to the generation logic to obtain a target generation result file;

[0026] The target file includes the target generation result file.

[0027] Preferably, the preset logic includes verification logic;

[0028] The step S5 includes: processing the acquired object data according to the verification logic to obtain a target verification result file;

[0029] The target file includes the target verification result file.

[0030] The advantages or beneficial effects of the technical solution of the present invention are:

[0031] The present invention converts and stores the parsed memory objects into a relational database, thereby eliminating the dependence on the Java programming language and environment, realizing cross-environment data access and operation, significantly reducing the coupling between business logics, and effectively alleviating the impact of AUTOSAR version changes, thereby greatly improving the scalability and overall performance of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A workflow diagram for describing and managing the AUTOSAR metamodel based on the Ecore model in the prior art;

[0033] Figure 2 A schematic diagram of a process flow of a metamodel conversion method in a preferred embodiment of the present invention;

[0034] Figure 3 A schematic diagram of the flow of configuration file parsing in a preferred embodiment of the present invention;

[0035] Figure 4 A schematic diagram of a flow chart of generating and verifying logic in a preferred embodiment of the present invention;

[0036] Figure 5 The overall workflow diagram of metamodel conversion in a preferred embodiment of the present invention;

[0037] Figure 6 The following is a workflow diagram of the conversion process from AUTOSAR XML (ARXML) to a relational database in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0039] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0040] To facilitate understanding of the technical solutions of the embodiments of the present application, the technical concepts involved in the embodiments of the present application are explained below.

[0041] The metamodel is an abstract representation of the model, which is used to specify the objects, data and relationships between objects contained in the model, and is described and stored using the Ecore standard.

[0042] The present invention will be further described below in conjunction with the accompanying drawings and specific embodiments, but they are not intended to limit the present invention.

[0043] See also Figure 2 In a preferred embodiment of the present invention, based on the above problems existing in the prior art, a metamodel conversion method is provided, comprising:

[0044] Step S1, obtaining a configuration file of the Automotive Open System Architecture (AUTOSAR);

[0045] Step S2, parsing the configuration file to obtain a memory object;

[0046] Step S3, converting the memory object to obtain object data, and storing the object data in a relational database.

[0047] Specifically, in this embodiment, the acquired configuration file is parsed to read the structured data in the configuration file and convert it into an object representation in the memory; then, the memory object obtained by the parsing is converted to generate object data, and the data is stored in a relational database. By converting the system architecture information originally in the form of objects into structured data in a relational database, the strong dependence of the entire development process from parsing to subsequent operations on the Java programming language and environment is eliminated.

[0048] In this embodiment, the AUTOSAR metamodel based on the relational database can conveniently access and operate the data no matter in the Java environment or in other programming environments, thereby improving the accessibility of the data and significantly reducing the coupling between business logics.

[0049] In addition, since relational databases have powerful data management and query capabilities, this method also effectively alleviates the impact of AUTOSAR version changes, allowing the system to adapt to different AUTOSAR versions more flexibly, thereby improving the scalability and overall performance of the system.

[0050] As a preferred implementation, the configuration file is a description file in the ARXML format.

[0051] AUTOSARAP development includes three main phases: architecture and design phase, software development phase, and integration and deployment phase.

[0052] In the architecture and design phase, it is necessary to determine the system requirements, functions, and services and assign them to the appropriate Machine. Developers use some modeling tools according to their personal habits, such as Simulink, ProVision, or the DSL scripting language that comes with RTA-VRTESDK, to define and design the functional requirements and architecture of the application. Create and configure service interfaces, CP / AP interoperability, software components, SWC ports, etc., and generate ARXML files.

[0053] The ARXML file is a standard format for AUTOSAR, which is used to describe the metadata and deployment manifest of the application. The output of this phase is a system configuration description (SCD), which shows the static and dynamic characteristics of the system.

[0054] In this embodiment, the configuration file is the ARXML file defined by AUTOSAR in the above architecture and design phase, such as Autosar.arxml.

[0055] As a preferred embodiment, wherein Figure 3 As shown, step S2 includes:

[0056] Step S21, inputting the configuration file into the parsing model, parsing the configuration file through the parsing model to obtain one or more objects;

[0057] Step S22, storing one or more objects in the memory to obtain a memory object.

[0058] Specifically, in this embodiment, during the parsing process, a specific parsing tool or algorithm is used to read the structured data in the configuration file and convert it into an object representation in the memory. These memory objects accurately reflect the system architecture and component information in the AUTOSAR configuration file.

[0059] In this embodiment, the parsing model is an Ecore model. The ARXML file defined by AUTOSAR is imported into the Ecore model, the ARXML file is parsed using the existing Ecore model, and the AUTOSAR data structure is loaded into the memory to output the Ecore object model.

[0060] The Ecore object model is represented in memory.

[0061] Specifically, the memory object is an instantiation of the Ecore object model, and the object data of the memory object includes but is not limited to a specific object type and attributes.

[0062] By way of example, the object types include, but are not limited to, ApplicationSwComponentType, RTEEvent, and the like.

[0063] As a preferred implementation, the memory object is stored in the memory as temporary data.

[0064] Specifically, these objects are stored in memory as temporary data.

[0065] As a preferred implementation, the object data includes the object type and attribute value of the memory object.

[0066] As a preferred embodiment, step S3 includes:

[0067] Serialize the object data of the memory object into the relational database.

[0068] Specifically, in this embodiment, the object data in the memory is serialized into a relational database, so that the data no longer relies on Java memory and can be accessed and operated through the relational database, providing a more flexible and persistent data storage solution that can solve the problem of strong coupling with the Java programming language and environment.

[0069] As a preferred implementation, step S3 further includes:

[0070] The object data of the memory objects and the association relationship between the memory objects are stored in a relational database.

[0071] Specifically, in this embodiment, each object instance is converted into a record in a relational database, while retaining the association relationship between the various objects.

[0072] Relational databases are used to store object data of memory objects, such as specific object types and attribute values.

[0073] Relational databases are also used to store the association relationships between various memory objects, such as aggregation relationships and reference relationships.

[0074] Furthermore, a relational database includes several database tables, and each type corresponds to a database table.

[0075] For example, for an RTEEvent object, the RTEEvent object is converted into a record in the database table RTEEvent. For example, each record includes, but is not limited to: project ID (projectld), universally unique identifier (uuid), father event universally unique identifier (fatherUuid), channel feature name (pass FeatureName), sequence number (sequence), short name (shortName), category (cateory), data type policy (dataTypePolicy), signal type (iSignalT ype), length (length), system signal (systemSignal).

[0076] Projectld is a unique identifier used to identify a specific project. In a database, it is often used to associate all records belonging to the same project.

[0077] uuid is a unique identifier for the RTEEvent object and is used to ensure that each event is unique within the database.

[0078] fatherUuid indicates which parent event the current event is derived from (if any), and is used to establish a hierarchy or parent-child relationship between events.

[0079] passFeatureName: usually refers to the name of a specific channel or path associated with an event, used to identify the context or location where the event occurred.

[0080] A sequence represents the position of an event in a specific context or sequence and is used to determine the order of events.

[0081] shortName is a brief name or identifier for the event, typically used to quickly identify the event.

[0082] Category indicates the category or type of an event and is used to group or classify events.

[0083] dataTypePolicy specifies the type of data associated with the event and how it is handled. It may involve the format, encoding, or storage policy of the data.

[0084] iSignalType indicates the type of signal carried by the event, such as analog signal, digital signal, etc., which helps to understand the nature of the event data.

[0085] Length usually refers to the length or duration of the event data, depending on the context, it may mean the duration of a signal, the length of a data packet, etc.

[0086] systemSignal indicates whether the event is a signal generated by the system rather than triggered by an external source or user input, to distinguish between system internal events and external events.

[0087] As a preferred embodiment, wherein Figure 4 As shown, after step S3, the following steps are also included:

[0088] Step S4, obtaining object data from a relational database;

[0089] Step S5, processing the acquired object data according to a preset logic to obtain a target file.

[0090] Specifically, in order to solve the adaptation problem of tool chain generation and verification logic caused by AUTOSAR version updates, preset logical operations are performed through data in the relational database, including generation logic and verification logic, without relying on memory Java object data, reducing the coupling between various logics and improving the scalability and performance of the system.

[0091] As a preferred embodiment, the preset logic includes generation logic;

[0092] Step S5 includes: processing the acquired object data according to the generation logic to obtain a target generation result file;

[0093] Target files include target generation result files.

[0094] As a preferred implementation, the preset logic includes verification logic;

[0095] Step S5 includes: processing the acquired object data according to the verification logic to obtain a target verification result file;

[0096] The target files include the target verification result files.

[0097] In the above-mentioned preferred embodiment, the embodiment method of the present invention proposes a relational database conversion implementation based on the AUTOS AR Ecore model. The core idea is to convert and store the Ecore model data of AUTOSA R into a relational database, thereby realizing access and operation of the data independently of the Java environment, thereby achieving a decoupled effect on the business logic.

[0098] like Figure 5 and Figure 6As shown in the figure, the conversion process from AUTOSAR XML (ARXML) to relational database is mainly divided into four parts: Arxml parsing, memory objects, conversion and database.

[0099] Part 1: Arxml parsing

[0100] Input: ARXML file defined by AUTOSAR, such as Autosar.arxml.

[0101] Output: Ecore object model, which is represented in memory.

[0102] Part 2: Memory Objects

[0103] Instantiation of the Ecore object model, including specific types and properties.

[0104] Example object types: ApplicationSwComponentType, RTEEvent, etc. These objects are stored in memory as temporary data.

[0105] Part 3: Conversion

[0106] Read the property value of the Ecore object through the reflection mechanism.

[0107] Each object instance is converted into a record in a relational database, while retaining the relationship between objects.

[0108] Part 4: Database

[0109] Output: A relational database that stores the attribute data of all Ecore objects and the aggregation and reference relationships between objects.

[0110] The operation on database data in the embodiment of the present invention is applicable to various program types, such as RCP program, Web service, Python script program, etc.

[0111] Whether it is an RCP program or other program, as long as the parsed database data is consistent, the same generation and verification logic can be used. The implementation of generation and verification no longer depends on a specific environment platform and programming language, fundamentally achieving the decoupling of various business logics.

[0112] The advantages or beneficial effects of adopting the above technical solution are:

[0113] 1. Data is stored in a standard relational database and is no longer strongly dependent on the Java environment, so that various programming languages ​​and platforms can easily access and process AUTOSAR data, reducing system dependencies;

[0114] 2. Programs no longer rely on memory data, and can share and operate data through the database, reducing coupling.

[0115] 3. Since the data is stored in the database, the generation and verification logic can remain stable, greatly reducing the impact of AUTOSAR version changes and reducing version dependence.

[0116] 4. It avoids the problem of loading large-scale data into memory, improves the resource utilization efficiency of the system, and optimizes resource utilization.

[0117] 5. The operation of database data can be applied to various program types (such as RCP programs, Web services, Python script programs, etc.), which broadens the scope of application and improves scalability.

[0118] The above are only preferred embodiments of the present invention, and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should be aware that all solutions obtained by equivalent substitutions and obvious changes made using the contents of this specification and illustrations should be included in the protection scope of the present invention.

Claims

1. A metamodel conversion method, characterized in that: include: Step S1, obtaining a configuration file of an automotive open system architecture; Step S2, parsing the configuration file to obtain a memory object; Step S3: convert the memory object to obtain object data, and store the object data in a relational database.

2. The metamodel conversion method according to claim 1, characterized in that: The configuration file is a description file in the format of extensible markup language.

3. The metamodel conversion method according to claim 1, characterized in that: The step S2 comprises: Step S21, inputting the configuration file into a parsing model, parsing the configuration file through the parsing model to obtain one or more objects; Step S22: store the one or more objects in the memory to obtain the memory object.

4. The metamodel conversion method according to claim 1, characterized in that: The memory object is stored in the memory as temporary data.

5. The metamodel conversion method according to claim 1, characterized in that: The object data includes the object type and attribute value of the memory object.

6. The metamodel conversion method according to claim 1, characterized in that: The step S3 comprises: The object data of the memory object is serialized into the relational database.

7. The metamodel conversion method according to claim 1, characterized in that: The step S3 further comprises: The object data of the memory objects and the association relationships between the memory objects are stored in the relational database.

8. The metamodel conversion method according to claim 1, characterized in that: After step S3, the following steps are also included: Step S4, obtaining the object data from the relational database; Step S5: Process the acquired object data according to a preset logic to obtain a target file.

9. The metamodel conversion method according to claim 8, characterized in that: The preset logic includes generation logic; The step S5 includes: processing the acquired object data according to the generation logic to obtain a target generation result file; The target file includes the target generation result file.

10. The metamodel conversion method according to claim 8, characterized in that: The preset logic includes verification logic; The step S5 includes: processing the acquired object data according to the verification logic to obtain a target verification result file; The target file includes the target verification result file.

Images