An Automated Testing Method for SOME / IP Signal Interaction in SOA In-Vehicle Infotainment Systems

Abstract

This application discloses an automated testing method for SOME / IP signal interaction in SOA vehicle infotainment systems, relating to the field of vehicle system development. The method includes: S1, Real-time Semantic Verification: The MO (Automotive Object) terminal inputs SOA service, event, and field signal information through a graphical modeling tool; the input data is transmitted to the rule engine in real time; the rule engine determines the data compliance based on the embedded SOME / IP communication rule library; if the data is found to be non-compliant, the front-end reports an error and locks the save button, forcing modification to compliance; S2, Metamodel Solidification: Compliant data is serialized into a metamodel file in XML or JSONSchema format and stored in a version control system as the sole source of fact; S3, Source Code Generation: A code generator is called to read the metamodel file and synchronously generate network protocol stack configuration files and application layer stub code; S4, Virtual Integration Simulation: Two virtual nodes are started on the PC to simulate the server and client, and based on the generated protocol stack configuration, a SOME / IP communication handshake is executed to verify the correctness of the communication logic.

Description

Technical Field

[0001] This application relates to the field of vehicle system development, and in particular to automated testing methods for SOME / IP signal interaction for SOA vehicle infotainment systems, automated testing systems for SOME / IP signal interaction for SOA vehicle infotainment systems, electronic devices, storage media, and vehicle development platforms. Background Technology

[0002] Under the new architecture, SOA can communicate via Ethernet in the vehicle infotainment system. Currently, the development of SOA (Service-Oriented Architecture) vehicle infotainment systems typically follows a process of "manually filling out the Service Information Form (Excel) -> network engineer generating protocol stack code -> application layer calling".

[0003] The protocol stack output by the network specialist isn't readily available. Instead, each MO (Service Provider) fills in the <Service Information Table>, and the network specialist generates the protocol stack based on this table. This stack is then compiled and integrated by the docking station. Only when the application mounted on the dock subscribes and the peer sends a service signal can the information be transmitted to the application layer through the transport layer. This leads to the following problems:

[0004] 1. Data and code disconnect: The Excel spreadsheets filled out by MOs (function definers) lack strong correlation verification with the underlying generated code, which often leads to definition errors (such as incorrect EventID format or discontinuous GroupID) being carried over into the code generation stage.

[0005] 2. Delayed feedback: Errors are often only discovered during real vehicle debugging or bench testing. At this time, it is necessary to backtrack, modify the Excel file, and regenerate the code, resulting in a long development iteration cycle and extremely high rework costs.

[0006] 3. High cost of manual verification: Relying on manual checks of Excel spreadsheets for compliance is inefficient and prone to overlooking complex logical rules. Summary of the Invention

[0007] The purpose of this invention is to provide an automated testing method for SOME / IP signal interaction in SOA vehicle infotainment systems, an automated testing system for SOME / IP signal interaction in SOA vehicle infotainment systems, electronic devices, storage media, and a vehicle development platform, thereby solving at least one of a number of technical problems.

[0008] Data and code disconnect: The manually filled Excel "Service Information Form" lacks strong correlation verification with the underlying protocol stack code. Definition errors such as incorrect EventID format and discontinuous GroupID can easily be carried over into the code generation stage, leading to interface consistency issues.

[0009] Delayed error feedback: Data errors are only exposed during the actual vehicle debugging or bench testing phase, requiring backtracking to modify the Excel and regenerate the code, resulting in long development iteration cycles and high rework costs;

[0010] Manual verification is inefficient: Relying on manual checks of form compliance makes it difficult to cover complex logical rules, easily leads to omissions of errors, and is inefficient.

[0011] This invention provides the following solution:

[0012] According to a first aspect of the present invention, an automated testing method for SOME / IP signal interaction in SOA vehicle infotainment systems is provided. This method, based on a graphical modeling tool, a rule engine, a meta-model repository, and a code generator, includes the following steps:

[0013] S1, Real-time semantic verification: The MO end inputs signal information of SOA services, events, and fields through graphical modeling tools;

[0014] The entered data is transmitted to the rules engine in real time;

[0015] The rules engine determines data compliance based on the embedded SOME / IP communication rules base;

[0016] If the data is found to be in violation, the front end will highlight the error and lock the save button, forcing the data to be modified to comply with regulations.

[0017] S2, Metamodel Solidification: Compliant data is serialized into a metamodel file in XML or JSON Schema format and stored in a version control system as the sole source of facts;

[0018] S3, same as source code generation: calls the code generator to read the metamodel file and synchronously generates network protocol stack configuration files and application layer stub code;

[0019] S4, Virtual Integration Simulation: Start two virtual nodes on the PC to simulate the server and client. Based on the generated protocol stack configuration, perform a SOME / IP communication handshake to verify the correctness of the communication logic.

[0020] Furthermore, including:

[0021] In step S1, the graphical modeling tool is either a web-based or desktop interface.

[0022] Furthermore, including:

[0023] In step S1, the SOME / IP communication rule base includes EventID format specifications, GroupID continuity requirements, and service name prefix consistency check rules;

[0024] EventIDs of the Notification type begin with 0x9.

[0025] Furthermore, including:

[0026] In step S2, the version control system is Git, and the modification and update records of the metamodel file are set to be traceable.

[0027] Furthermore, including:

[0028] In step S3, the code generator is implemented based on the Jinja2 template engine to generate application layer stub code that supports C++ or Java languages ​​for the application layer to call.

[0029] According to a second aspect of the present invention, an automated testing system for SOME / IP signal interaction in SOA vehicle infotainment systems is provided. The automated testing system for SOME / IP signal interaction in SOA vehicle infotainment systems includes:

[0030] Graphical modeling module: Provides a visual interface for MO to input signal information of SOA services, events, and fields;

[0031] The rules engine module communicates with the graphical modeling module, has an embedded SOME / IP communication rule base, receives input data and performs compliance judgments, and returns error information or save instructions to the front end.

[0032] Metamodel storage module: Communicates with the rules engine module to receive compliance data, serialize it into a metamodel file in XML or JSONSchema format, and store it in the Git version control system;

[0033] Code generation module: Communicates with the metamodel storage module, reads metamodel files based on the Jinja2 template engine, and synchronously generates network protocol stack configuration files and application layer stub code;

[0034] Virtual simulation module: Communicates with the code generation module to start virtual server and client nodes on the PC, execute SOME / IP communication handshake based on protocol stack configuration, and verify communication logic.

[0035] Furthermore, including:

[0036] The rules engine module includes a custom rule configuration unit and a rule update unit;

[0037] Customizable rule configuration unit, supporting the addition of personalized specifications from car manufacturers;

[0038] The rule update unit includes online dynamic rule updates.

[0039] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0040] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps such as the SOME / IP signal interaction automated test method for SOA vehicle infotainment systems.

[0041] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device causes the electronic device to perform steps such as an automated test method for SOME / IP signal interaction for SOA vehicle infotainment systems.

[0042] According to a fifth aspect of the present invention, a vehicle development platform is provided, comprising:

[0043] Electronic devices, for implementing automated testing methods for SOME / IP signal interaction in SOA-oriented vehicle systems, etc.

[0044] The processor runs a program that, when running, executes steps from data output by the electronic device, such as the automated test method for SOME / IP signal interaction in SOA vehicle systems.

[0045] Storage medium for storing programs that, when running, execute steps such as the SOME / IP signal interaction automation test method for SOA vehicle infotainment systems based on data output from electronic devices.

[0046] The above solution achieves the following beneficial technical effects:

[0047] This application uses real-time semantic verification to intercept errors at the design source, preventing unauthorized data from flowing into subsequent processes. The error interception efficiency far exceeds that of manual inspection, intercepting data errors in advance.

[0048] This application eliminates the "decoupling between definition and implementation" from the root by using the meta-model as the sole source of fact and generating protocol stack configuration files and application layer stub code from the same source, thus completely solving the interface consistency problem and ensuring data and code consistency.

[0049] This application supports PC-based hardware-free verification through virtual integrated simulation, exposing communication logic problems in advance, avoiding rework during the actual vehicle testing phase, enabling parallel development, and shortening the development iteration cycle.

[0050] This application automates data entry, compliance assessment, and code generation by replacing manual form filling and verification, significantly reducing repetitive work and error correction costs, and lowering labor and maintenance costs. Attached Figure Description

[0051] Figure 1 This is a flowchart of an automated testing method for SOME / IP signal interaction in an SOA vehicle infotainment system, provided by one or more embodiments of the present invention.

[0052] Figure 2 This is a structural diagram of an automated testing system for SOME / IP signal interaction for SOA vehicle infotainment systems provided by one or more embodiments of the present invention.

[0053] Figure 3 This is a block diagram of an electronic device structure for an automatic memory reclamation method for in-vehicle SOME / IP protocol stack based on shadow threads, provided by one or more embodiments of the present invention. Detailed Implementation

[0054] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] Figure 1 This is a flowchart of an automated testing method for SOME / IP signal interaction in an SOA vehicle infotainment system, provided by one or more embodiments of the present invention.

[0056] like Figure 1 The automated testing method for SOME / IP signal interaction in SOA vehicle infotainment systems, as shown, is applied to the Ethernet communication scenario of intelligent connected vehicles. It addresses the technical problems of data and code disconnect, delayed error feedback, and low efficiency of manual verification caused by manually filling out Excel "Service Information Forms." This automated testing method for SOME / IP signal interaction in SOA vehicle infotainment systems is implemented based on graphical modeling tools, a rule engine, a meta-model repository, and a code generator, and includes the following steps:

[0057] S1, Real-time Semantic Verification: MO inputs signal information of SOA services, events, and fields through graphical modeling tools. The input data is transmitted to the rule engine in real time. The rule engine judges the compliance of the data based on the embedded SOME / IP communication rule library. If the data violates the rules, the front end highlights the error and locks the save button, forcing modification to compliance.

[0058] S2, Metamodel Solidification: Compliant data is serialized into a metamodel file in XML or JSON Schema format and stored in a version control system as the sole source of fact;

[0059] S3, same as source code generation: calls the code generator to read the metamodel file and synchronously generates network protocol stack configuration files and application layer stub code;

[0060] S4, Virtual Integration Simulation: Start two virtual nodes on the PC to simulate the server and client, and perform SOME / IP communication handshake based on the generated protocol stack configuration to verify the correctness of the communication logic.

[0061] Specifically, the metamodel schema supports dynamic expansion, allowing the addition of composite signal types such as nested structures, nested arrays, and nested enumerations, without affecting the compatibility of existing metamodel data.

[0062] The graphical modeling tool supports batch import and export of CSV format signal data, provides a visual editing interface for complex signal types such as nested structures and multidimensional arrays, and supports consistency verification of signals and architectures in released ARXML files.

[0063] The rule engine has a built-in signal data caching mechanism that directly reuses historical verification results for frequently entered signal parameters, reducing real-time computation overhead. When the number of signals exceeds 1,000, the verification response latency does not exceed 100ms.

[0064] This application supports integration with vehicle-mounted testing tools such as CANoe and Vector VN5640. Virtual simulation data can be synchronized to the test management platform through a standardized interface. The generated application layer piling code has built-in UDS diagnostic protocol adaptation logic, which supports diagnostic tools to read signal configuration information.

[0065] This application's metamodel repository supports fine-grained version management of metamodel files, records the addition, modification, and deletion operations of individual signals, supports tracing change history by signal dimension, and provides a version comparison tool to visually display the differences between different versions.

[0066] In this embodiment, it includes:

[0067] In step S1, the graphical modeling tool is a web-based or desktop interface, replacing the traditional Excel spreadsheet, and supports visual input of signal parameters.

[0068] In this embodiment, it includes:

[0069] In step S1, the SOME / IP communication rule base includes EventID format specifications, GroupID continuity requirements, and service name prefix consistency check rules;

[0070] EventIDs of the Notification type begin with 0x9.

[0071] In this embodiment, it includes:

[0072] In step S2, the version control system is Git, and the modification and update records of the metamodel file are traceable, supporting version rollback.

[0073] In this embodiment, it includes:

[0074] In step S3, the code generator is implemented based on the Jinja2 template engine. The generated application layer stub code supports C++ or Java languages ​​and can be directly called by the application layer.

[0075] In this embodiment, it includes:

[0076] In step S4, virtual integrated simulation does not rely on physical hardware and can complete communication logic verification before the actual vehicle or test bench is in place, thus enabling parallel development.

[0077] In this embodiment, it includes:

[0078] The rules engine supports custom rule configuration, allowing users to add personalized specifications for car manufacturers, including EventID prefixes, field naming formats, GroupID step size requirements, and supports online dynamic rule updates.

[0079] Specifically, the rule engine supports rule priority configuration, with custom rules having higher priority than embedded SOME / IP communication rules, and supports batch import and export of rule configuration files, facilitating rule reuse across multiple projects.

[0080] In this embodiment, it includes:

[0081] In step S2, the metamodel repository supports multi-MO collaboration conflict detection. When multiple users modify the same metamodel file at the same time, it automatically identifies signal-level conflicts and provides a prompt to avoid data overwriting.

[0082] In this embodiment, it includes:

[0083] The method also includes a historical data migration step, providing a batch import tool for Excel-formatted "Service Information Tables" to automatically convert historical signal data into standard meta-model files.

[0084] Specifically, the historical data migration tool supports batch import of multiple formats such as Excel and CSV, and has a data cleaning function that automatically corrects format errors and duplicate definitions in historical data, and generates a migration report with annotations of the corrections.

[0085] In this embodiment, it includes:

[0086] In step S3, the code generator provides a template customization entry point, allowing users to adjust the code generation template according to the underlying middleware type and application layer framework, and insert custom logs, monitoring logic, or macro definitions.

[0087] Specifically, the code generator supports the generation of application layer stub code in Python and C languages, and the generated network protocol stack configuration files conform to the AUTOSAR standard and can be directly imported into DaVinci and vCDT tools.

[0088] In this embodiment, it includes:

[0089] In step S4, the virtual integrated simulation supports the simulation of complex network environments and can configure network latency, packet loss, and jitter parameters to verify communication stability under extreme scenarios.

[0090] Specifically, the virtual integrated simulation supports multi-node concurrent communication verification, and can be configured with no less than 10 virtual nodes to simulate multi-service interaction scenarios. It also supports simulation verification of security features such as SOME / IP protocol encryption authentication and permission verification.

[0091] The virtual integrated simulation has a built-in automated result judgment module. It presets the expected results of communication interactions, automatically compares the communication messages and response times of virtual nodes, and generates a Pass / Fail judgment report without requiring manual log review.

[0092] In this embodiment, it includes:

[0093] In step S1, the rule engine supports exception rule configuration. For temporary signals during the testing phase and old version compatibility transition signals, rule exemptions can be set, eliminating the need for mandatory compliance.

[0094] In this embodiment, it includes:

[0095] The method also includes an error classification and processing step. The rule engine classifies errors into critical errors and minor errors. Critical errors are forcibly intercepted and saved, while minor errors only issue a warning and allow users to confirm and continue saving.

[0096] Figure 2 This is a structural diagram of an automated testing system for SOME / IP signal interaction for SOA vehicle infotainment systems provided by one or more embodiments of the present invention.

[0097] like Figure 2 The SOME / IP signal interaction automated testing system for SOA vehicle infotainment systems shown is applied to the Ethernet communication scenario of intelligent connected vehicles. The SOME / IP signal interaction automated testing system for SOA vehicle infotainment systems includes:

[0098] Graphical modeling module: Provides a visual interface for MO to input signal information of SOA services, events, and fields;

[0099] The rules engine module communicates with the graphical modeling module, has an embedded SOME / IP communication rule base, receives input data and performs compliance judgments, and returns error information or save instructions to the front end.

[0100] Metamodel storage module: Communicates with the rules engine module to receive compliance data, serialize it into a metamodel file in XML or JSONSchema format, and store it in the Git version control system;

[0101] Code generation module: Communicates with the metamodel storage module, reads metamodel files based on the Jinja2 template engine, and synchronously generates network protocol stack configuration files and application layer stub code;

[0102] Virtual simulation module: Communicates with the code generation module to start virtual server and client nodes on the PC, execute SOME / IP communication handshake based on protocol stack configuration, and verify communication logic.

[0103] Specifically, the metamodel storage module also includes a schema extension unit and a composite signal support unit. The schema extension unit supports the dynamic expansion of the metamodel schema, while the composite signal support unit provides storage and parsing capabilities for structure, array, and enumerated nested signal types.

[0104] The graphical modeling module also includes a batch processing unit, a complex signal editing unit, and a consistency verification unit. The batch processing unit supports CSV format import and export, the complex signal editing unit provides a visual composite signal editing interface, and the consistency verification unit verifies the consistency between the signal and the ARXML file.

[0105] The rules engine module also includes a cache optimization unit, which caches the verification results of high-frequency signals to reduce verification latency in large-scale signal scenarios.

[0106] The system also includes a test tool integration module that communicates with the virtual simulation module and code generation module, provides standardized interfaces with CANoe and Vector VN5640, and supports UDS diagnostic protocol adaptation.

[0107] In this embodiment, it includes:

[0108] The rules engine module includes a custom rule configuration unit and a rule update unit;

[0109] Customizable rule configuration unit, supporting the addition of personalized specifications from car manufacturers;

[0110] The rule update unit includes online dynamic rule updates.

[0111] Specifically, the rules engine module also includes a rule priority management unit and a batch configuration unit. The rule priority management unit supports priority sorting of custom rules and embedded rules, while the batch configuration unit supports batch import and export of rule configuration files.

[0112] In this embodiment, the metamodel storage module includes a collaborative conflict detection unit, which is used to identify signal-level conflicts when multiple users modify the metamodel file simultaneously and generate conflict prompt information.

[0113] In this embodiment, the system also includes a historical data migration module, which is communicatively connected to the metamodel storage module and is used to receive historical signal data in Excel format and convert it into standard metamodel files in batches.

[0114] Specifically, the historical data migration module also includes a data cleaning unit and a migration report unit. The data cleaning unit automatically corrects errors in historical data, and the migration report unit generates a migration report containing the corrections.

[0115] In this embodiment, the code generation module includes a template customization unit, which allows users to adjust the code generation template and insert custom code snippets.

[0116] Specifically, the code generation module also includes a multilingual support unit and an AUTOSAR adaptation unit. The multilingual support unit supports Python and C language code generation, and the AUTOSAR adaptation unit generates .arxml format protocol stack configuration files that conform to the AUTOSAR standard.

[0117] In this embodiment, the virtual simulation module includes a complex network simulation unit, which is used to configure network latency, packet loss, and jitter parameters to simulate extreme communication environments.

[0118] Specifically, the virtual simulation module also includes a multi-node concurrent unit, a security feature simulation unit, and an automated judgment unit. The multi-node concurrent unit supports concurrent interaction of more than 10 virtual nodes, the security feature simulation unit supports encryption authentication and permission verification simulation, and the automated judgment unit presets expected results and automatically generates test reports.

[0119] In this embodiment, the rule engine module includes an error classification processing unit, which is used to classify errors into serious errors and minor errors, and perform forced interception or warning prompt operations respectively.

[0120] In this embodiment, the system also includes a log traceability module, which communicates with each module to record the signal input operator, operation time, error type, meta-model change history, and supports full-process traceability.

[0121] Specifically, the log tracing module also includes a signal-level change tracing unit and a version comparison unit. The signal-level change tracing unit records the entire lifecycle changes of a single signal, while the version comparison unit visualizes the version differences of the meta-model file.

[0122] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0123] In one specific embodiment, an automated signal interaction testing method is disclosed. Using a <Service Information Table> and a protocol stack provided by a network professional, a simulated server-side subscription signal is constructed. The results are then returned via the protocol stack, and these results are used for judgment and analysis. This addresses the problems in existing technologies such as inconsistencies between SOA signal definition data (Excel) and generated code, delayed error detection, and low efficiency of manual verification.

[0124] In this embodiment:

[0125] 1.1 Graphical Modeling Tools (Front-end):

[0126] It replaces traditional Excel spreadsheets and provides a graphical interface for web or desktop use.

[0127] Used for MOs (functionality definers) to input signal information such as SOA services, events, and fields.

[0128] 1.2 Rule Engine (Brain):

[0129] Embedded in the modeling tool backend, it contains a set of predefined SOME / IP communication rule bases (such as: Event ID must start with 0x9, Group ID must be consecutive, service name prefix consistency check, etc.).

[0130] 1.3 Metamodel Repository (Data Source):

[0131] Store verified, standardized data in XML or JSON Schema format as a "Single Source of Truth".

[0132] 1.4 Code Generator (Execution End):

[0133] Based on a template engine (such as Jinja2), it reads data from the metamodel repository and automatically generates the underlying protocol stack configuration file and application layer interface code.

[0134] Specific implementation steps

[0135] Step 1: Real-time semantic validation (design phase)

[0136] Operation: When MO inputs signal parameters in the graphical tool (e.g., entering Event ID as 0x801), the data is not saved directly, but is first sent to the rules engine.

[0137] Judgment: According to the preset SOME / IP specification, the rule engine detected that the ID does not conform to the rule that "Notification type must start with 0x9".

[0138] Feedback: The system immediately highlights the error on the front-end interface, locks the save button, and forces the MO to be modified to compliant data (such as 0x901).

[0139] Technical effect: Errors are intercepted at the design source, preventing erroneous data from entering subsequent processes.

[0140] Step 2: Metamodel solidification (storage phase)

[0141] Operation: After all input data passes the rule engine validation, the tool serializes it into a standard metamodel file (XML / JSON) and stores it in a version control system (such as Git).

[0142] Technical effect: Ensures that the data entering the code generation stage is 100% compliant and traceable.

[0143] Step 3: Same as source code generation (build phase) operation: Call the code generator and read the same metamodel file.

[0144] Generate A: Generate network protocol stack configuration (for use by the underlying communication middleware).

[0145] Generate B: Generate application layer stub / skeleton code (for C++ / Java application layer calls).

[0146] Technical effect: Since A and B come from the same "parent" (metamodel), they are naturally consistent in their interface definitions, completely eliminating the risk of "inconsistency between definition and implementation".

[0147] Step 4: Virtual Integration Simulation (Verification Phase)

[0148] Operation: Before the physical hardware is in place, use the generated code to start two virtual nodes (simulating the server and client) on the PC.

[0149] Interaction: Virtual nodes perform SOME / IP communication handshakes based on the generated configuration.

[0150] Technical effect: Verify the correctness of communication logic in an environment without a real vehicle, ensuring that it can be used immediately upon installation.

[0151] The innovative contribution in this embodiment lies in:

[0152] SOA signal meta-model definition method: especially the technical solution of embedding business rules (such as ID naming conventions and group continuity) into the data schema.

[0153] Same-origin generation logic based on meta-model: that is, a method that uses the same metadata to generate both the underlying protocol stack and the upper-layer application interface code.

[0154] Real-time semantic validation mechanism: rule interception is performed during the data entry stage, rather than testing after code generation.

[0155] The technical background of this embodiment is as follows: SOME / IP (Scalable Service-Oriented Middleware IP) is a communication protocol stack for automotive electronic systems and other embedded systems. It aims to provide a mechanism for communication over IP networks to meet the communication needs of modern automotive electronics. The following is some basic information about the SOME / IP protocol stack:

[0156] Protocol Layers: The SOME / IP protocol stack typically consists of multiple protocol layers, covering all aspects from the underlying network communication to the application layer. These layers include the physical layer, network layer, transport layer, and application layer.

[0157] Communication Modes: SOME / IP supports two communication modes: publish-subscribe and request-response. In the publish-subscribe mode, service providers can publish messages, and subscribers can subscribe to and receive these messages. In the request-response mode, one entity can send a request to another entity and wait for a response.

[0158] Service discovery: SOME / IP supports a service discovery mechanism that enables devices to discover available services on the network. This helps in finding and connecting to services in dynamic network environments.

[0159] Message Format: SOME / IP messages typically use a binary format. The message format includes a message header and a payload. The message header contains metadata about the message type, data size, and service ID, etc.

[0160] Interface Definition Language (IDL): To enable different systems to understand and exchange messages, SOME / IP uses an Interface Definition Language (IDL) to define the structure of services and messages. This helps ensure consistency between communicating parties.

[0161] Message serialization and deserialization: In order to transmit messages over a network, SOME / IP uses message serialization and deserialization mechanisms to convert messages from data structures into byte streams and byte streams back into data structures.

[0162] Security: Security is paramount in modern automotive electronics. SOME / IP supports secure communication through methods such as encryption and authentication.

[0163] Supported transport layers: SOME / IP can run on different transport layers, including UDP (User Datagram Protocol) and TCP (Transmission Control Protocol).

[0164] The actual implementation of SOME / IP can vary depending on the supplier, system requirements, and the specific application of the automotive electronics system. Typically, automakers, suppliers, and development teams will select or customize the SOME / IP protocol stack to meet their specific communication needs.

[0165] Figure 3 This is a block diagram of an electronic device structure for an automatic memory reclamation method for in-vehicle SOME / IP protocol stack based on shadow threads, provided by one or more embodiments of the present invention.

[0166] like Figure 3 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0167] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps of an automatic memory reclamation method for the in-vehicle SOME / IP protocol stack based on shadow threads.

[0168] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a shadow thread-based automatic memory reclamation method for the vehicle-mounted SOME / IP protocol stack.

[0169] This application also provides a vehicle development platform, including:

[0170] Electronic devices, steps for implementing an automatic memory reclamation method for the in-vehicle SOME / IP protocol stack based on shadow threads;

[0171] The processor runs a program, and when the program runs, it executes the steps of the shadow thread-based automatic memory reclamation method for the vehicle SOME / IP protocol stack memory based on the data output from the electronic device.

[0172] Storage medium used to store programs that, when running, execute steps of an onboard SOME / IP protocol stack memory auto-reclamation method based on shadow threads for data output from electronic devices.

[0173] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0174] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0175] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0176] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0177] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0178] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0179] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0180] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0181] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0182] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. An automated testing method for SOME / IP signal interaction in SOA vehicle infotainment systems, characterized in that, The automated testing method for SOME / IP signal interaction in SOA vehicle systems includes: S1, Real-time semantic verification: The MO end inputs signal information of SOA services, events, and fields through graphical modeling tools; The entered data is transmitted to the rules engine in real time; The rules engine determines data compliance based on the embedded SOME / IP communication rules base; If the data is found to be in violation, the front end will highlight the error and lock the save button, forcing the data to be modified to comply with regulations. S2, Metamodel Solidification: Compliant data is serialized into a metamodel file in XML or JSON Schema format and stored in a version control system as the sole source of facts; S3, same as source code generation: calls the code generator to read the metamodel file and synchronously generates network protocol stack configuration files and application layer stub code; S4, Virtual Integration Simulation: Start two virtual nodes on the PC to simulate the server and client. Based on the generated protocol stack configuration, perform a SOME / IP communication handshake to verify the correctness of the communication logic.

2. The automated testing method for SOME / IP signal interaction in SOA vehicle systems according to claim 1, characterized in that, include: In step S1, the graphical modeling tool is a web-based or desktop interface.

3. The automated testing method for SOME / IP signal interaction in SOA vehicle systems according to claim 1, characterized in that, include: In step S1, the SOME / IP communication rule base includes EventID format specifications, GroupID continuity requirements, and service name prefix consistency check rules; EventIDs of the Notification type begin with 0x9.

4. The automated testing method for SOME / IP signal interaction in SOA vehicle systems according to claim 1, characterized in that, include: In step S2, the version control system is Git, and the modification and update records of the metamodel file are set to be traceable.

5. The automated testing method for SOME / IP signal interaction in SOA vehicle systems according to claim 1, characterized in that, include: In step S3, the code generator is implemented based on the Jinja2 template engine to generate application layer stub code that supports C++ or Java languages ​​for application layer to call.

6. An automated testing system for SOME / IP signal interaction in SOA vehicle infotainment systems, characterized in that, The automated testing system for SOME / IP signal interaction in SOA-based vehicle systems includes: Graphical modeling module: Provides a visual interface for MO to input signal information of SOA services, events, and fields; The rules engine module communicates with the graphical modeling module, has an embedded SOME / IP communication rule base, receives input data and performs compliance judgments, and returns error information or save instructions to the front end. Metamodel storage module: Communicates with the rules engine module to receive compliance data, serialize it into a metamodel file in XML or JSONSchema format, and store it in the Git version control system; Code generation module: Communicates with the metamodel storage module, reads metamodel files based on the Jinja2 template engine, and synchronously generates network protocol stack configuration files and application layer stub code; Virtual simulation module: Communicates with the code generation module to start virtual server and client nodes on the PC, execute SOME / IP communication handshake based on protocol stack configuration, and verify communication logic.

7. The automated testing system for SOME / IP signal interaction for SOA vehicle infotainment systems according to claim 6, characterized in that, include: The rule engine module includes a custom rule configuration unit and a rule update unit; Customizable rule configuration unit, supporting the addition of personalized specifications from car manufacturers; The rule update unit includes online dynamic rule updates.

8. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by a processor, causes the processor to perform the steps of the automated testing method for SOME / IP signal interaction for SOA vehicle systems as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, include: The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the automated test method for SOME / IP signal interaction for SOA vehicle systems as described in any one of claims 1 to 6.

10. A vehicle development platform, characterized in that, include: An electronic device for implementing the steps of the automated testing method for SOME / IP signal interaction of an SOA-oriented vehicle infotainment system as described in any one of claims 1 to 6; The processor runs a program that, when the program is running, performs the steps of the automated test method for SOME / IP signal interaction of an SOA vehicle system as described in any one of claims 1 to 6, based on data output from the electronic device. A storage medium for storing a program that, when running, performs the steps of the automated test method for SOME / IP signal interaction for SOA vehicle systems as described in any one of claims 1 to 6 on data output from an electronic device.

Images