Vehicle-mounted SGW-IVI SOA service communication optimization method and system and electronic equipment

Abstract

The invention provides a vehicle-mounted SGW-IVI SOA service communication optimization method, which belongs to the field of intelligent driving and comprises the following steps: constructing a scene-service demand mapping model; in response to a service request of the SGW, the mapping model identifies a scene type corresponding to the service, and matches a corresponding service demand based on the scene type; according to the SGW-IVI service calling method and system, the contradiction between the scene engine dynamic requirement and static configuration in a traditional static service matrix is solved, the SGW-IVI service calling delay is reduced, and the real-time requirement of a high-priority scene (such as emergency braking) is met.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving technology, and in particular to a method, system, electronic device, and computer-readable medium for optimizing communication of in-vehicle SGW-IVI SOA services. Background Technology

[0002] In traditional automotive SOA architectures, the service matrix between the SGW and IVI adopts a static configuration model. During system initialization, all service interfaces (such as IDL interfaces based on SOME / IP), call paths, and communication parameters (transmission protocols, update frequencies) are defined through a fixed configuration file. Service discovery relies on the standard SOME / IP-SD mechanism—before initiating a service call, the IVI needs to send a discovery request to the SGW's service registry center to obtain the service instance address and then establish a connection.

[0003] In this scheme, service communication parameters (such as bandwidth allocation and timeout) remain fixed and are independent of the dynamic needs of the IVI scene engine. For example, high-frequency services such as vehicle speed and location are always transmitted at a fixed frequency (such as 10Hz), even if the scene engine does not require high-frequency data in the "parking and resting" scenario. At the same time, there is no service data aggregation or caching mechanism, and each time the IVI calls a service, it must obtain the data from the domain controller in real time through the SGW. Repeated requests for the same data still require the complete transmission process. Summary of the Invention

[0004] This invention aims to solve at least one of the technical problems existing in the prior art, and proposes a method and system for optimizing communication of vehicle-mounted SGW-IVI SOA services.

[0005] In a first aspect, embodiments of the present invention provide a method for optimizing communication for vehicle-mounted SGW-IVI SOA services, comprising:

[0006] In response to a service request from the SGW, the mapping model identifies the scenario type corresponding to the service and matches the corresponding service requirements based on the scenario type.

[0007] Service calls are made based on the aforementioned service requirements.

[0008] In some embodiments, the step of constructing a scenario-service requirement mapping model includes:

[0009] Establish an IVI scene engine architecture to identify scene types;

[0010] SGW services are classified based on scenario relevance and matched with corresponding service requirements;

[0011] A dynamic requirement matrix is ​​constructed based on the scenario type and service requirements.

[0012] In some embodiments, the engine architecture includes:

[0013] Input layer: Collects user behavior, vehicle status, and environmental data through onboard sensors and user interface;

[0014] Decision-making level: Employing rule engines and machine learning models for scene type identification;

[0015] Output layer: Invokes the corresponding service requirements based on the scenario type.

[0016] In some of these embodiments,

[0017] The SGW service includes:

[0018] High-frequency subscription services require low latency, high update frequency, and high reliability.

[0019] Event-triggered services require high reliability, low packet loss rate, and trigger response.

[0020] Bulk transmission services require high throughput and allow for latency fluctuations.

[0021] In some of these embodiments,

[0022] The demand matrix is: D = f(S, T).

[0023] Where S represents the scenario type, T represents the time window, and the matrix elements include service call frequency and QoS requirements.

[0024] In some of these embodiments,

[0025] Also includes:

[0026] Based on data correlation, multi-dimensional service data are merged into "composite events";

[0027] The cache duration is calculated based on the service update frequency and the historical call rate of the scenario type.

[0028] In some of these embodiments,

[0029] Also includes:

[0030] Based on the security level of the scenario type and the urgency of user needs, a scenario type priority is constructed, and the transmission queue, update frequency, and bandwidth allocation are optimized in real time according to the scenario type priority.

[0031] In some of these embodiments,

[0032] A middleware is deployed between the SGW and the IVI. This middleware includes a service discovery proxy module, a failover unit, and a status monitoring module, wherein:

[0033] The service discovery proxy module is used to cache high-frequency service addresses and pre-bind scenario-related services;

[0034] The failover unit is used to automatically switch to a backup node when an instance fails.

[0035] The status monitoring module collects data on service call latency, bandwidth usage, and CPU / memory consumption.

[0036] In some embodiments, it also includes:

[0037] Match the service matrix configuration file and use OTA technology to distribute the updated configuration file to IVI to automatically update the local configuration.

[0038] Secondly, the present invention provides a vehicle-mounted SGW-IVI SOA service communication optimization system, comprising:

[0039] The matching unit, in response to the service request from the SGW, uses a scenario-service requirement mapping model to identify the scenario type corresponding to the service, and matches the corresponding service requirement based on the scenario type.

[0040] The execution unit makes service calls based on the service requirements.

[0041] Thirdly, the present invention also provides an electronic device, comprising:

[0042] One or more processors;

[0043] Memory, used to store one or more programs;

[0044] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods.

[0045] Fourthly, the present invention also provides a computer-readable medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps in any of the methods described.

[0046] This invention provides an optimized communication method for in-vehicle SGW-IVI SOA services. It constructs a scenario-service requirement mapping model. Responding to SGW service requests, the mapping model identifies the scenario type corresponding to the service and matches the corresponding service requirement based on the scenario type. Service calls are then made based on these service requirements. This invention resolves the contradiction between "dynamic requirements and static configuration of the scenario engine" in traditional static service matrices, reduces SGW-IVI service call latency, and meets the real-time requirements of high-priority scenarios (such as emergency braking). It optimizes in-vehicle resource allocation, reduces bandwidth usage of the SGW-IVI link and CPU / memory consumption of IVI / SGW, and avoids resource waste. It achieves collaboration between the service matrix and the scenario engine, dynamically adjusting service strategies according to scenario type (such as commuting, emergency) to improve scenario response efficiency. Finally, it establishes a protection mechanism adapted to in-vehicle safety requirements, distinguishing service security levels and ensuring the security of high-security-level service calls (such as vehicle body control). Attached Figure Description

[0047] Figure 1 This is a schematic diagram illustrating the steps of an embodiment of the vehicle-mounted SGW-IVI SOA service communication optimization method of the present invention;

[0048] Figure 2 This is a schematic diagram illustrating the steps of constructing a scenario-service requirement mapping model according to an embodiment of the present invention;

[0049] Figure 3 This is a schematic diagram of an embodiment of the vehicle-mounted SGW-IVI SOA service communication optimization method system of the present invention.

[0050] Figure 4 This is a schematic diagram of the structure of an embodiment of the electronic device of the present invention. Detailed Implementation

[0051] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0052] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0053] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0054] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0055] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0056] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0057] In related technologies, static service discovery mechanisms require the IVI (In-Vision Controller) to undergo a complete service discovery process when a new service needs to be called in a new scenario, increasing service call latency and making it difficult to meet the real-time requirements of the scenario engine. For example, in an emergency braking linkage scenario, latency may lead to untimely responses from safety-related services, posing a safety hazard. Fixed communication parameters and the lack of data aggregation and caching mechanisms cause high-frequency service data to continuously consume network bandwidth and computing resources. Even when the scenario does not require high-frequency data or the data is reusable, resource consumption remains high, resulting in excessive network load and wasted CPU and memory resources. Furthermore, the inability to adjust service communication strategies according to the dynamic needs of the scenario engine means that when scenarios switch or QoS requirements change, the system cannot adaptively adjust service priorities, transmission parameters, etc., making it difficult to adapt to diverse scenario requirements and reducing user experience.

[0058] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a method for optimizing communication of vehicle-mounted SGW-IVI SOA services. Figure 1 The flowchart illustrates the steps of a method for optimizing communication in a vehicle-mounted SGW-IVI SOA service, as provided in an embodiment of the present invention.

[0059] like Figure 1 As shown, the vehicle-mounted SGW-IVI SOA service communication optimization method includes the following steps:

[0060] Step S10: Construct a scenario-service requirement mapping model.

[0061] Please see Figure 2 In this embodiment, the step of constructing the scenario-service requirement mapping model includes:

[0062] Step S11: Establish the IVI scene engine architecture to identify scene types. Specifically, this includes:

[0063] Input layer: Collects user behavior, vehicle status, and environmental data (such as GPS location and radar collision signals) through onboard sensors (such as GPS and radar) and the user interface. This data is input into the decision layer in the form of events.

[0064] Decision layer: Scene recognition is performed using a rule engine (based on predefined rules, such as "vehicle speed > 60km / h triggers highway mode") and a machine learning model (such as predicting the triggering time of "commuter mode" based on historical data). The logical chain is "event perception → rule matching → service call", that is, input data triggers the rule engine or model inference, and outputs scene ID (such as S1=commuter mode, S2=emergency braking).

[0065] Output layer: Invoke the corresponding SGW service (such as vehicle speed service, air conditioning control) based on the scene ID.

[0066] It is understood that this embodiment clearly defines the logical link between the input layer (user behavior / vehicle status / environmental data, such as GPS location and radar collision signal) and the decision layer (rule engine + machine learning model, such as predicting the triggering time of "commuting mode" based on historical data), and outlines the process of "event perception → rule matching → service invocation".

[0067] Step S12: Classify SGW services based on scenario relevance and match them with corresponding service requirements.

[0068] In this embodiment, the SGW service includes:

[0069] High-frequency subscription services require low latency, high update frequency, and high reliability.

[0070] Event-triggered services require high reliability, low packet loss rate, and trigger response.

[0071] Bulk transmission services require high throughput and allow for latency fluctuations.

[0072] For high-frequency subscription services (such as vehicle speed, battery status, and GPS location): the requirements are quantified by monitoring service call frequency and latency, namely low latency (≤20ms), high update frequency (5-10Hz), and reliability level ≥99.9%. During implementation, network probes and statistical tools (such as sliding window calculations) are used to measure these metrics in real time.

[0073] Event-triggered services (such as remote air conditioning control and brake signals): Based on functional safety standards (such as ASIL-B), the quantitative requirements are high reliability (guaranteed through redundant transmission), low packet loss rate (≤0.1%, using forward error correction technology), and trigger response ≤15ms (implemented through event-driven architecture).

[0074] For bulk transmission services (such as OTA data and map updates): the requirement is quantified by bandwidth testing tools as high throughput (≥10Mbps) and allowable latency fluctuations (≤100ms, using buffering mechanisms).

[0075] Based on scenario relevance, SGW services are divided into three categories, as detailed in Table 1 below.

[0076] Service Types Use Case Examples Demand characteristics High-frequency subscription Vehicle speed, battery status, GPS location Low latency (≤20ms), high update frequency (5-10Hz), and reliability level ≥99.9%. Event-triggered Remote air conditioning control, brake signal High reliability (ASIL-B level), low packet loss rate (≤0.1%), trigger response ≤15ms Bulk transfer type OTA data and map updates High throughput (≥10Mbps), with acceptable latency fluctuations (≤100ms)

[0077] Step S13: Construct a dynamic demand matrix based on the scenario type and service requirements.

[0078] In this embodiment, a demand matrix D = f(S, T) is defined, where S is the scenario ID (obtained from the decision layer) and T is the time window (default 100ms). Matrix elements include service call frequency (e.g., calls per second) and QoS requirements (latency, reliability, etc.).

[0079] Specifically, real-time databases (such as Redis) are used to store scenario and service data, and the matrix is ​​dynamically updated using machine learning models (such as time series forecasting). For example, in "commuting mode," the frequency of GPS service calls may increase from 5Hz to 10Hz.

[0080] It can be understood that a demand matrix D=f(S,T) is defined, where S is the scenario ID (e.g., S1=commuting mode, S2=emergency braking), and T is the time window (e.g., 100ms). The matrix elements represent the service call frequency and QoS requirements of a certain scenario within a certain time window, providing data support for subsequent optimization.

[0081] Step S20: In response to the service request from the SGW, the mapping model identifies the scenario type corresponding to the service and matches the corresponding service requirements based on the scenario type.

[0082] Specifically, obtain current context information, including user behavior, vehicle status, and environmental data (which come from the input layer).

[0083] The current scene ID (S) is identified based on the current context information using the decision layer (rule engine and machine learning model).

[0084] Based on the current scenario ID (S) and the current time window (T), query the dynamic demand matrix D to obtain the demand for all services in this scenario (including call frequency and QoS requirements).

[0085] For the currently requested service, extract the specific requirements of that service in this scenario from the dynamic requirement matrix.

[0086] Step S30: Make a service call based on the service requirements.

[0087] Specifically, based on the service address and QoS requirements, a service call is initiated through the corresponding communication protocol (such as SOME / IP or DDS), for example:

[0088] For high-frequency subscription services, use the UDP protocol and set up multicast groups to transmit data with low latency and high speed.

[0089] For event-triggered services, ensure the use of highly reliable transport mechanisms (such as TCP or UDP with ACK) and set high priority.

[0090] For bulk transmission services, use the TCP protocol to ensure reliability and set a lower priority to avoid affecting critical services.

[0091] In this embodiment, the optimization method provided by the present invention also includes a two-level dynamic optimization mechanism, namely service aggregation and cache optimization, and QoS dynamic adaptation engine.

[0092] Service aggregation and caching optimization include: merging multi-dimensional service data into "composite events" based on data correlation; and calculating the cache cycle based on the historical call rate of service update frequency and scenario type.

[0093] Specifically, the service aggregation rule is to merge multi-dimensional service data into "composite events" based on data correlation analysis (such as covariance calculation). For example, "GPS location + vehicle speed + heading angle" can be aggregated into "driving status event". In this case, aggregation logic is set on the SGW or middleware to reduce the number of SGW-IVI interactions (such as merging the original 3 calls into 1 call).

[0094] It is understandable that multi-dimensional service data can be merged into "composite events" based on data correlation, such as aggregating "GPS location + vehicle speed + heading angle" into "driving status event", thereby reducing the number of SGW-IVI interactions.

[0095] The IVI-side LRU caching strategy calculates the cache duration based on the service update frequency (F) and the historical call rate (R) of the scenario, using the formula: Cache duration = 0.6 × F⁻¹ + 0.4 × R. The weights (0.6 and 0.4) can be dynamically adjusted according to the scenario (e.g., through reinforcement learning). For example, for a vehicle speed service with F = 10Hz and R = 0.8, the cache duration = 0.6 × 0.1 + 0.4 × 0.8 = 0.38s. In implementation, a caching module is deployed on the IVI side, using the LRU algorithm to evict old data.

[0096] It's understandable that the cache duration is calculated based on the service update frequency (F) and the historical call rate of the scenario (R), using the formula: Cache Duration = 0.6 × F⁻¹ + 0.4 × R (the weights can be dynamically adjusted). For example, if the vehicle speed service update frequency is 10Hz (F=10) and the scenario call rate is 0.8 (R=0.8), then the cache duration = 0.6 × 0.1 + 0.4 × 0.8 = 0.38s, thus caching high-frequency data to reduce duplicate requests.

[0097] Furthermore, the QoS dynamic adaptation engine includes: constructing scenario type priorities based on the security level of scenario type and the urgency of user needs, and optimizing the transmission queue, update frequency, and bandwidth allocation in real time according to the scenario type priorities.

[0098] Specifically, this includes prioritizing scenarios. A priority model is constructed based on safety levels (such as ASIL standards) and the urgency of user needs (such as user interaction priority). For example, emergency braking linkage (P1) has the highest priority, followed by commuting mode (P3), and entertainment scenarios (P5) have the lowest. In implementation, a weighted scoring method (safety weight 0.7, user urgency weight 0.3) is used to calculate priorities.

[0099] A priority model is built based on the scene safety level and the urgency of user needs. The ranking results are: emergency braking linkage (P1) > commuting mode (P3) > entertainment scene (P5). The higher the priority, the more resources are allocated.

[0100] Furthermore, communication parameters are dynamically adjusted. Priority queues (such as the LinuxTC tool) are used, with P1-level services entering the highest priority queue. Adjustments are made dynamically based on priority, such as increasing the frequency of a P1-level service from 10Hz to 15Hz. Through bandwidth management protocols (such as IEEE 802.1Qav), P1-level services occupy 30% of the link bandwidth. Emergency services (such as brake signals) use UDP to reduce latency, while bulk transmissions (such as OTA) use TCP to ensure reliability. In implementation, a protocol switcher is deployed in the middleware to automatically select the appropriate protocol based on the service type.

[0101] It is understandable that the transmission queue, update frequency (P1 level service enters the highest priority queue), and bandwidth allocation (P1 level service update frequency is increased to 15Hz) are optimized in real time according to the scenario priority. The TCP / UDP adaptive switching is adopted (UDP is used to reduce latency for emergency services, and TCP is used to ensure reliability for batch transmission).

[0102] Furthermore, middleware is deployed between SGW and IVI.

[0103] In this embodiment, the middleware comprises three core modules:

[0104] Service discovery proxy module: Based on the SOME / IP-SD protocol extension, it caches high-frequency service addresses (such as vehicle speed service addresses) and pre-binds scenario-related services (such as binding GPS service to "commuter mode"). The cache validity period is synchronized with the scenario cycle (such as setting the cache validity period to 30 minutes if commuter mode lasts for 30 minutes), reducing the number of queries.

[0105] Failover Unit: Used to automatically switch to a backup node when an instance fails. It operates in primary / backup mode and monitors the service instance status via heartbeat detection (every 50ms interval). When an instance fails, it automatically switches to a pre-started backup node with dynamic IP address mapping (e.g., ARP update), and the switchover time is ≤500ms.

[0106] Status monitoring module: Collects service call latency, bandwidth usage, and CPU / memory consumption data. Based on the AUTOSARAP diagnostic interface, it collects service call latency, bandwidth usage, and CPU / memory consumption data at a sampling interval of 100ms. The data is fed back to the QoS engine (step two) for policy adjustment (such as reducing the update frequency when latency exceeds the limit).

[0107] Deploying middleware between SGW and IVI involves three core modules, listed below:

[0108] Module Name Function Description Technical Implementation Service discovery proxy module Cache frequently used service addresses (such as vehicle speed and location services), pre-bind related services for specific scenarios, and reduce the number of SOME / IP-SD queries. Based on the SOME / IP-SD protocol extension, the cache validity period is synchronized with the scene cycle. Failover Unit Monitor service instance status in real time (via heartbeat detection, every 50ms), and automatically switch to backup node when instance fails (switchover time ≤ 500ms). Employing a primary / standby model, with backup instances pre-started and IP addresses dynamically mapped. Status monitoring module Data on service call latency, bandwidth usage, and CPU / memory consumption are collected and fed back to the QoS engine to adjust policies. The diagnostic interface is based on AUTOSARAP, with a data sampling interval of 100ms.

[0109] Furthermore, standardized APIs are provided (such as ServiceDiscovery() for service discovery and QoSOptimize() for triggering optimizations) to support rapid integration between the IVI scene engine and SGW services. It is compatible with SOME / IP and DDS protocols, using a protocol adaptation layer for conversion during implementation.

[0110] This step is the execution layer of the optimization method. The service discovery proxy supports service aggregation, the failover unit ensures reliability, and the status monitoring module provides real-time data for dynamic QoS adaptation.

[0111] In this embodiment, it also includes: matching the service matrix configuration file, and using OTA technology to send the updated configuration file to the IVI to automatically update the local configuration.

[0112] In this embodiment, a service matrix configuration file is designed: service interface information, aggregation rules, caching strategies, QoS parameters, and scenario priorities are defined using XML or JSON format. For example, the XML file defines the caching period for "commuting mode" as 0.38 seconds.

[0113] It is understandable that service interface information, aggregation rules, caching strategies, QoS parameters, scenario priorities, and other configuration information are defined using XML or JSON format, and the configuration files can be remotely updated via OTA technology.

[0114] Furthermore, implementing an OTA dynamic update mechanism includes:

[0115] Secure transmission: The configuration file is encrypted using the TLS protocol and supports resuming interrupted downloads (such as based on HTTP / 2) to prevent tampering or loss.

[0116] Configuration Updates: After receiving the configuration file, the configuration management modules of IVI and SGW parse and update the local configuration (such as modifying the demand matrix), and restart relevant service components (such as the service discovery proxy and the QoS dynamic adaptation engine). In implementation, version control (such as Git-style) is used to manage the configuration.

[0117] Error handling: Supports rollback mechanism. If network interruption or verification failure occurs during the update process, it will automatically roll back to the previous version to avoid system failure.

[0118] This step is understandably a maintenance layer for the optimization method, ensuring the system can adapt to new scenarios or service changes. The configuration file contains the requirement matrix for step S10 and the optimization parameters for step S20; OTA updates allow these parameters to be dynamically adjusted. This step relies on the middleware interface of step S30 (such as updating the service address via ServiceDiscovery()), and simultaneously feeds back to steps S10 and S20, forming a closed-loop optimization.

[0119] Understandably, when adding new services, adjusting service optimization strategies, or fixing configuration vulnerabilities, updated configuration files are distributed to IVI and SGW via OTA technology. Upon receiving the configuration files, the configuration management modules of IVI and SGW automatically update their local configurations and restart relevant service components (such as service discovery agents and QoS dynamic adaptation engines) to ensure the new configuration takes effect. Simultaneously, to ensure the security and reliability of the update process, encrypted transmission (such as the TLS protocol) and breakpoint resumption technology are employed to prevent configuration files from being tampered with or lost. In the event of an anomaly during the update process (such as network interruption), it supports rolling back to the previous configuration version to avoid system failure.

[0120] This invention provides an optimized communication method for in-vehicle SGW-IVI SOA services. It constructs a scenario-service requirement mapping model. Responding to SGW service requests, the mapping model identifies the scenario type corresponding to the service and matches the corresponding service requirement based on the scenario type. Service calls are then made based on these service requirements. This invention resolves the contradiction between "dynamic requirements and static configuration of the scenario engine" in traditional static service matrices, reduces SGW-IVI service call latency, and meets the real-time requirements of high-priority scenarios (such as emergency braking). It optimizes in-vehicle resource allocation, reduces bandwidth usage of the SGW-IVI link and CPU / memory consumption of IVI / SGW, and avoids resource waste. It achieves collaboration between the service matrix and the scenario engine, dynamically adjusting service strategies according to scenario type (such as commuting, emergency) to improve scenario response efficiency. Finally, it establishes a protection mechanism adapted to in-vehicle safety requirements, distinguishing service security levels and ensuring the security of high-security-level service calls (such as vehicle body control).

[0121] Please see Figure 3 The present invention also provides an SGW-IVI SOA service communication optimization system. Applied to the vehicle-mounted SGW-IVI SOA service communication optimization method provided in the above embodiments, it specifically includes: a matching unit and an execution unit.

[0122] The matching unit is used to respond to the service request from the SGW, identify the scenario type corresponding to the service using a scenario-service requirement mapping model, and match the corresponding service requirement based on the scenario type.

[0123] The construction of the scenario-service requirement mapping model includes:

[0124] Input layer: Collects user behavior, vehicle status, and environmental data (such as GPS location and radar collision signals) through onboard sensors (such as GPS and radar) and the user interface. This data is input into the decision layer in the form of events.

[0125] Decision layer: Scene recognition is performed using a rule engine (based on predefined rules, such as "vehicle speed > 60km / h triggers highway mode") and a machine learning model (such as predicting the triggering time of "commuter mode" based on historical data). The logical chain is "event perception → rule matching → service call", that is, input data triggers the rule engine or model inference, and outputs scene ID (such as S1=commuter mode, S2=emergency braking).

[0126] Output layer: Invoke the corresponding SGW service (such as vehicle speed service, air conditioning control) based on the scene ID.

[0127] It is understood that this embodiment clearly defines the logical link between the input layer (user behavior / vehicle status / environmental data, such as GPS location and radar collision signal) and the decision layer (rule engine + machine learning model, such as predicting the triggering time of "commuting mode" based on historical data), and outlines the process of "event perception → rule matching → service invocation".

[0128] Classify SGW services and quantify requirements to define service objectives.

[0129] In this embodiment, classifying SGW services and quantifying demand to define service objectives includes:

[0130] For high-frequency subscription services (such as vehicle speed, battery status, and GPS location): the requirements are quantified by monitoring service call frequency and latency, namely low latency (≤20ms), high update frequency (5-10Hz), and reliability level ≥99.9%. During implementation, network probes and statistical tools (such as sliding window calculations) are used to measure these metrics in real time.

[0131] Event-triggered services (such as remote air conditioning control and brake signals): Based on functional safety standards (such as ASIL-B), the quantitative requirements are high reliability (guaranteed through redundant transmission), low packet loss rate (≤0.1%, using forward error correction technology), and trigger response ≤15ms (implemented through event-driven architecture).

[0132] For bulk transmission services (such as OTA data and map updates): the requirement is quantified by bandwidth testing tools as high throughput (≥10Mbps) and allowable latency fluctuations (≤100ms, using buffering mechanisms).

[0133] Based on scenario relevance, SGW services are divided into three categories, as detailed in Table 1 below.

[0134] Service Types Use Case Examples Demand characteristics High-frequency subscription Vehicle speed, battery status, GPS location Low latency (≤20ms), high update frequency (5-10Hz), and reliability level ≥99.9%. Event-triggered Remote air conditioning control, brake signal High reliability (ASIL-B level), low packet loss rate (≤0.1%), trigger response ≤15ms Bulk transfer type OTA data and map updates High throughput (≥10Mbps), with acceptable latency fluctuations (≤100ms)

[0135] A dynamic demand matrix is ​​constructed based on the described scenarios and service objectives.

[0136] In this embodiment, a demand matrix D = f(S, T) is defined, where S is the scenario ID (obtained from the decision layer) and T is the time window (default 100ms). Matrix elements include service call frequency (e.g., calls per second) and QoS requirements (latency, reliability, etc.).

[0137] Specifically, real-time databases (such as Redis) are used to store scenario and service data, and the matrix is ​​dynamically updated using machine learning models (such as time series forecasting). For example, in "commuting mode," the frequency of GPS service calls may increase from 5Hz to 10Hz.

[0138] It can be understood that a demand matrix D=f(S,T) is defined, where S is the scenario ID (e.g., S1=commuting mode, S2=emergency braking), and T is the time window (e.g., 100ms). The matrix elements represent the service call frequency and QoS requirements of a certain scenario within a certain time window, providing data support for subsequent optimization.

[0139] Specifically, obtain current context information, including user behavior, vehicle status, and environmental data (which come from the input layer).

[0140] The current scene ID (S) is identified based on the current context information using the decision layer (rule engine and machine learning model).

[0141] Based on the current scenario ID (S) and the current time window (T), query the dynamic demand matrix D to obtain the demand for all services in this scenario (including call frequency and QoS requirements).

[0142] For the currently requested service, extract the specific requirements of that service in this scenario from the dynamic requirement matrix.

[0143] An execution unit is used to make service invocations based on the service requirements.

[0144] Specifically, based on the service address and QoS requirements, a service call is initiated using the appropriate communication protocol (such as SOME / IP or DDS). Simultaneously, the middleware configures communication parameters according to the QoS requirements, for example:

[0145] For high-frequency subscription services, use the UDP protocol and set up multicast groups to transmit data with low latency and high speed.

[0146] For event-triggered services, ensure the use of highly reliable transport mechanisms (such as TCP or UDP with ACK) and set high priority.

[0147] For bulk transmission services, use the TCP protocol to ensure reliability and set a lower priority to avoid affecting critical services.

[0148] In this embodiment, it also includes:

[0149] Based on data correlation, multi-dimensional service data are merged into "composite events"; the cache period is calculated based on the historical call rate of service update frequency and scenario type.

[0150] Specifically, the service aggregation rule is to merge multi-dimensional service data into "composite events" based on data correlation analysis (such as covariance calculation). For example, "GPS location + vehicle speed + heading angle" can be aggregated into "driving status event". In this case, aggregation logic is set on the SGW or middleware to reduce the number of SGW-IVI interactions (such as merging the original 3 calls into 1 call).

[0151] It is understandable that multi-dimensional service data can be merged into "composite events" based on data correlation, such as aggregating "GPS location + vehicle speed + heading angle" into "driving status event", thereby reducing the number of SGW-IVI interactions.

[0152] The IVI-side LRU caching strategy calculates the cache duration based on the service update frequency (F) and the historical call rate (R) of the scenario, using the formula: Cache duration = 0.6 × F⁻¹ + 0.4 × R. The weights (0.6 and 0.4) can be dynamically adjusted according to the scenario (e.g., through reinforcement learning). For example, for a vehicle speed service with F = 10Hz and R = 0.8, the cache duration = 0.6 × 0.1 + 0.4 × 0.8 = 0.38s. In implementation, a caching module is deployed on the IVI side, using the LRU algorithm to evict old data.

[0153] It's understandable that the cache duration is calculated based on the service update frequency (F) and the historical call rate of the scenario (R), using the formula: Cache Duration = 0.6 × F⁻¹ + 0.4 × R (the weights can be dynamically adjusted). For example, if the vehicle speed service update frequency is 10Hz (F=10) and the scenario call rate is 0.8 (R=0.8), then the cache duration = 0.6 × 0.1 + 0.4 × 0.8 = 0.38s, thus caching high-frequency data to reduce duplicate requests.

[0154] The QoS dynamic adaptation engine includes building a priority model based on security level and user demand urgency, and dynamically adjusting the priority model according to communication parameters.

[0155] Specifically, this includes prioritizing scenarios. A priority model is constructed based on safety levels (such as ASIL standards) and the urgency of user needs (such as user interaction priority). For example, emergency braking linkage (P1) has the highest priority, followed by commuting mode (P3), and entertainment scenarios (P5) have the lowest. In implementation, a weighted scoring method (safety weight 0.7, user urgency weight 0.3) is used to calculate priorities.

[0156] A priority model is built based on the scene safety level and the urgency of user needs. The ranking results are: emergency braking linkage (P1) > commuting mode (P3) > entertainment scene (P5). The higher the priority, the more resources are allocated.

[0157] Furthermore, communication parameters are dynamically adjusted. Priority queues (such as the LinuxTC tool) are used, with P1-level services entering the highest priority queue. Adjustments are made dynamically based on priority, such as increasing the frequency of a P1-level service from 10Hz to 15Hz. Through bandwidth management protocols (such as IEEE 802.1Qav), P1-level services occupy 30% of the link bandwidth. Emergency services (such as brake signals) use UDP to reduce latency, while bulk transmissions (such as OTA) use TCP to ensure reliability. In implementation, a protocol switcher is deployed in the middleware to automatically select the appropriate protocol based on the service type.

[0158] It is understandable that the transmission queue, update frequency (P1 level service enters the highest priority queue), and bandwidth allocation (P1 level service update frequency is increased to 15Hz) are optimized in real time according to the scenario priority. The TCP / UDP adaptive switching is adopted (UDP is used to reduce latency for emergency services, and TCP is used to ensure reliability for batch transmission).

[0159] The execution unit makes service calls based on the service requirements.

[0160] Specifically, based on the service address and QoS requirements, a service call is initiated through the corresponding communication protocol (such as SOME / IP or DDS), for example:

[0161] For high-frequency subscription services, use the UDP protocol and set up multicast groups to transmit data with low latency and high speed.

[0162] For event-triggered services, ensure the use of highly reliable transport mechanisms (such as TCP or UDP with ACK) and set high priority.

[0163] For bulk transmission services, use the TCP protocol to ensure reliability and set a lower priority to avoid affecting critical services.

[0164] In this invention, the optimization system also includes middleware deployed between the SGW and IVI, which comprises three core modules:

[0165] Service discovery proxy module: Based on the SOME / IP-SD protocol extension, it caches high-frequency service addresses (such as vehicle speed service addresses) and pre-binds scenario-related services (such as binding GPS service to "commuter mode"). The cache validity period is synchronized with the scenario cycle (such as setting the cache validity period to 30 minutes if commuter mode lasts for 30 minutes), reducing the number of queries.

[0166] Failover Unit: Used to automatically switch to a backup node when an instance fails. It operates in primary / backup mode and monitors the service instance status via heartbeat detection (every 50ms interval). When an instance fails, it automatically switches to a pre-started backup node with dynamic IP address mapping (e.g., ARP update), and the switchover time is ≤500ms.

[0167] Status monitoring module: Collects service call latency, bandwidth usage, and CPU / memory consumption data. Based on the AUTOSARAP diagnostic interface, it collects service call latency, bandwidth usage, and CPU / memory consumption data at a sampling interval of 100ms. The data is fed back to the QoS engine (step two) for policy adjustment (such as reducing the update frequency when latency exceeds the limit).

[0168] The details are shown in the table below:

[0169] Module Name Function Description Technical Implementation Service discovery proxy module Cache frequently used service addresses (such as vehicle speed and location services), pre-bind related services for specific scenarios, and reduce the number of SOME / IP-SD queries. Based on the SOME / IP-SD protocol extension, the cache validity period is synchronized with the scene cycle. Failover Unit Monitor service instance status in real time (via heartbeat detection, every 50ms), and automatically switch to backup node when instance fails (switchover time ≤ 500ms). Employing a primary / standby model, with backup instances pre-started and IP addresses dynamically mapped. Status monitoring module Data on service call latency, bandwidth usage, and CPU / memory consumption are collected and fed back to the QoS engine to adjust policies. The diagnostic interface is based on AUTOSARAP, with a data sampling interval of 100ms.

[0170] Furthermore, standardized APIs are provided (such as ServiceDiscovery() for service discovery and QoSOptimize() for triggering optimizations) to support rapid integration between the IVI scene engine and SGW services. It is compatible with SOME / IP and DDS protocols, using a protocol adaptation layer for conversion during implementation.

[0171] This step is the execution layer of the optimization method. The service discovery proxy supports service aggregation, the failover unit ensures reliability, and the status monitoring module provides real-time data for dynamic QoS adaptation.

[0172] In this invention, the optimization system also includes: matching the service matrix configuration file, and using OTA technology to send the updated configuration file to the IVI to automatically update the local configuration.

[0173] In this embodiment, a service matrix configuration file is designed: service interface information, aggregation rules, caching strategies, QoS parameters, and scenario priorities are defined using XML or JSON format. For example, the XML file defines the caching period for "commuting mode" as 0.38 seconds.

[0174] It is understandable that service interface information, aggregation rules, caching strategies, QoS parameters, scenario priorities, and other configuration information are defined using XML or JSON format, and the configuration files can be remotely updated via OTA technology.

[0175] Furthermore, implementing an OTA dynamic update mechanism includes:

[0176] Secure transmission: The configuration file is encrypted using the TLS protocol and supports resuming interrupted downloads (such as based on HTTP / 2) to prevent tampering or loss.

[0177] Configuration Updates: After receiving the configuration file, the configuration management modules of IVI and SGW parse and update the local configuration (such as modifying the demand matrix), and restart relevant service components (such as the service discovery proxy and the QoS dynamic adaptation engine). In implementation, version control (such as Git-style) is used to manage the configuration.

[0178] Error handling: Supports rollback mechanism. If network interruption or verification failure occurs during the update process, it will automatically roll back to the previous version to avoid system failure.

[0179] This step is understandably a maintenance layer for the optimization method, ensuring the system can adapt to new scenarios or service changes. The configuration file contains the requirement matrix for step S10 and the optimization parameters for step S20; OTA updates allow these parameters to be dynamically adjusted. This step relies on the middleware interface of step S30 (such as updating the service address via ServiceDiscovery()), and simultaneously feeds back to steps S10 and S20, forming a closed-loop optimization.

[0180] Understandably, when adding new services, adjusting service optimization strategies, or fixing configuration vulnerabilities, updated configuration files are distributed to IVI and SGW via OTA technology. Upon receiving the configuration files, the configuration management modules of IVI and SGW automatically update their local configurations and restart relevant service components (such as service discovery agents and QoS dynamic adaptation engines) to ensure the new configuration takes effect. Simultaneously, to ensure the security and reliability of the update process, encrypted transmission (such as the TLS protocol) and breakpoint resumption technology are employed to prevent configuration files from being tampered with or lost. In the event of an anomaly during the update process (such as network interruption), it supports rolling back to the previous configuration version to avoid system failure.

[0181] This invention provides an in-vehicle SGW-IVI SOA service communication optimization system that constructs a scenario-service requirement mapping model. Responding to SGW service requests, the mapping model identifies the scenario type corresponding to the service and matches the corresponding service requirement based on the scenario type. Service calls are then made based on these service requirements. This invention resolves the contradiction between "dynamic requirements and static configuration of the scenario engine" in traditional static service matrices, reduces SGW-IVI service call latency, and meets the real-time requirements of high-priority scenarios (such as emergency braking). It optimizes in-vehicle resource allocation, reduces bandwidth usage of the SGW-IVI link and CPU / memory consumption of IVI / SGW, and avoids resource waste. It achieves collaboration between the service matrix and the scenario engine, dynamically adjusting service strategies according to scenario type (such as commuting, emergency) to improve scenario response efficiency. Finally, it establishes a protection mechanism adapted to in-vehicle safety requirements, distinguishing service security levels and ensuring the security of high-security-level service calls (such as vehicle body control).

[0182] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the vehicle-mounted SGW-IVI SOA service communication optimization methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0183] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0184] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0185] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0186] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the in-vehicle SGW-IVI SOA service communication optimization methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0187] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described vehicle-mounted SGW-IVI SOA service communication optimization method.

[0188] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0189] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0190] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0191] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0192] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0193] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0194] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0195] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0196] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0197] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for optimizing communication in a vehicle-mounted SGW-IVI SOA service, characterized in that, It includes: Construct a scenario-service requirement mapping model; In response to a service request from the SGW, the mapping model identifies the scenario type corresponding to the service and matches the corresponding service requirements based on the scenario type. Service calls are made based on the aforementioned service requirements.

2. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 1, characterized in that, The steps involved in building a scenario-service requirement mapping model include: Establish an IVI scene engine architecture to identify scene types; SGW services are classified based on scenario relevance and matched with corresponding service requirements; A dynamic requirement matrix is ​​constructed based on the scenario type and service requirements.

3. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 2, characterized in that, The engine architecture includes: Input layer: Collects user behavior, vehicle status, and environmental data through onboard sensors and user interface; Decision-making level: Employing rule engines and machine learning models for scene type identification; Output layer: Invokes the corresponding service requirements based on the scenario type.

4. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 3, characterized in that, The SGW service includes: High-frequency subscription services require low latency, high update frequency, and high reliability. Event-triggered services require high reliability, low packet loss rate, and trigger response. Bulk transmission services require high throughput and allow for latency fluctuations.

5. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 4, characterized in that, The demand matrix is: D = f(S, T). Where S represents the scenario type, T represents the time window, and the matrix elements include service call frequency and QoS requirements.

6. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 1, characterized in that, Also includes: Based on data correlation, multi-dimensional service data are merged into "composite events"; The cache duration is calculated based on the service update frequency and the historical call rate of the scenario type.

7. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 1, characterized in that, Also includes: Based on the security level of the scenario type and the urgency of user needs, a scenario type priority is constructed, and the transmission queue, update frequency, and bandwidth allocation are optimized in real time according to the scenario type priority.

8. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 1, characterized in that, Also includes: A middleware is deployed between the SGW and the IVI. This middleware includes a service discovery proxy module, a failover unit, and a status monitoring module, wherein: The service discovery proxy module is used to cache high-frequency service addresses and pre-bind scenario-related services; The failover unit is used to automatically switch to a backup node when an instance fails. The status monitoring module collects data on service call latency, bandwidth usage, and CPU / memory consumption.

9. The vehicle-mounted SGW-IVI SOA service communication optimization method according to claim 1, characterized in that, Also includes: Match the service matrix configuration file and use OTA technology to distribute the updated configuration file to IVI to automatically update the local configuration.

10. A vehicle-mounted SGW-IVI SOA service communication optimization system, characterized in that, include: The matching unit, in response to the service request from the SGW, uses a scenario-service requirement mapping model to identify the scenario type corresponding to the service, and matches the corresponding service requirement based on the scenario type. The execution unit makes service calls based on the service requirements.

Images