Vehicle-mounted SOME / IP communication processing method and device

Abstract

The invention discloses a vehicle-mounted SOME / IP communication processing method and device, and the method comprises the steps: converting a vehicle signal from a CAN bus into SOME / IP service through a target gateway, and providing the SOME / IP service to the outside, and the SOME / IP service comprises a method interface, an event interface or a field interface; aiming at the SOME / IP service converted and generated by the target gateway, respectively collecting communication indexes of a transmission layer, a session layer and a service layer; based on the communication index and the enhanced heartbeat information, a health score of the SOME / IP service is calculated, and when the health score is lower than a preset score threshold, an exception handling mechanism of a communication link is triggered, and the communication link refers to a communication link for converting a vehicle signal into the SOME / IP service. Therefore, a conversion path from the CAN signal to the SOME / IP service can be shortened, communication full-link performance observability is realized, dynamic health assessment and self-healing are supported, and the problems of high communication delay, difficulty in fault positioning and poor service reliability are solved.

Description

Technical Field

[0001] This invention relates to the field of electronic communication technology, and in particular to a vehicle-mounted SOME / IP communication processing method and apparatus. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards domain-centralized and centrally computed architectures, the Ethernet-based service-oriented communication protocol SOME / IP (Scalable service-oriented Middleware over IP) is widely used in intelligent connected vehicles to support high-bandwidth, loosely coupled service interactions.

[0003] In existing technologies, the raw CAN signals generated by vehicle sensors or actuators typically need to pass through multiple intermediate nodes (such as area controllers and application processors) for protocol parsing, logic processing, and protocol conversion before being finally encapsulated into SOME / IP services for upper-layer applications to call. This multi-hop communication link leads to a significant increase in end-to-end latency, making it difficult to meet the real-time requirements of scenarios such as advanced driver assistance systems.

[0004] Furthermore, current SOME / IP communication generally lacks fine-grained performance monitoring mechanisms for the transport, session, and service layers. Once a communication anomaly occurs, developers must rely on offline logs to troubleshoot step-by-step, with average fault location taking over 30 minutes, severely impacting development efficiency and after-sales maintenance. Simultaneously, existing service health assessments largely rely on fixed-period heartbeat packets, failing to reflect actual service quality degradation (such as slower response times and decreased throughput). This results in the system being unable to provide early warnings of performance deterioration, severely restricting the reliability and availability of automotive SOA architectures. Summary of the Invention

[0005] In view of the above problems, the present invention provides an in-vehicle SOME / IP communication processing method and apparatus, which can shorten the conversion path from CAN signal to SOME / IP service, realize the observability of the entire communication link performance, and support dynamic health assessment and self-healing, thereby solving the problems of high communication latency, difficult fault location, and poor service reliability.

[0006] According to a first aspect of the present invention, an in-vehicle SOME / IP communication processing method is provided, comprising: Vehicle signals from the CAN bus are converted into SOME / IP services through the target gateway and provided externally. The SOME / IP services include method interfaces, event interfaces, or field interfaces. For the SOME / IP service generated by the target gateway, communication metrics at the transport layer, session layer, and service layer are collected respectively. Based on the communication metrics and enhanced heartbeat information, a health score for the SOME / IP service is calculated. When the health score is lower than a preset score threshold, an abnormal handling mechanism for the communication link is triggered. The communication link refers to the communication link for converting vehicle signals into the SOME / IP service.

[0007] Optionally, the communication metrics include the average response time of the method interface, the packet loss rate of the event interface, the access latency of the field interface, and the service call success rate. The calculation of the health score of the SOME / IP service based on the communication metrics and enhanced heartbeat information includes: The success rate of receiving the enhanced heartbeat information is calculated based on the actual number of times the enhanced heartbeat is received and the expected number of times within the expected time. The average response time of the method interface, the packet loss rate of the event interface, the access latency of the field interface, the service call success rate, and the heartbeat reception success rate are all normalized to obtain the processed data. The health score is calculated based on the processed data and preset weight parameters.

[0008] Optionally, the step of triggering an anomaly handling mechanism for the communication link when the health score is lower than a preset score threshold includes: When the health score is lower than the preset score threshold, a fault log is recorded locally, an alarm is sent to the in-vehicle human-machine interaction system, and the service status information is uploaded to the remote diagnostic platform to perform a restart operation on the SOME / IP service.

[0009] Optionally, the conversion of vehicle signals from the CAN bus into SOME / IP services via the target gateway includes: When the sampling frequency of the vehicle signal is higher than the target frequency or the signal change amplitude exceeds a preset amplitude threshold, the vehicle signal from the CAN bus is converted into SOME / IP service through the hardware acceleration unit integrated in the target gateway.

[0010] Optionally, the hardware acceleration unit may include an FPGA or a DSP chip.

[0011] Optionally, the conversion of vehicle signals from the CAN bus into SOME / IP services via the target gateway includes: Load a predefined DBC file, which defines the CAN message identifier, signal start bit, signal length, scaling factor, and physical units; Based on the DBC file, the original data frames received from the CAN bus are parsed to obtain the vehicle signals; The vehicle signals are mapped to the interfaces corresponding to the SOME / IP service.

[0012] Optionally, mapping the vehicle signal to the interface corresponding to the SOME / IP service includes: The vehicle signals representing the steady-state state are mapped to a method interface to respond to external query requests; Map vehicle signals that characterize discrete state changes to event interfaces; The configuration parameters that support remote read and write are mapped to field interfaces, providing read, write, and change notification functions.

[0013] Optionally, after mapping the vehicle signal to the interface corresponding to the SOME / IP service, the method further includes: The SOME / IP service is registered and published on the target gateway for discovery and invocation by other electronic control units via the vehicle Ethernet.

[0014] According to a second aspect of the present invention, an in-vehicle SOME / IP communication processing device is provided, comprising: The conversion module is used to convert vehicle signals from the CAN bus into SOME / IP services through the target gateway and provide them to the outside world. The SOME / IP services include method interfaces, event interfaces, or field interfaces. The acquisition module is used to collect communication metrics of the transport layer, session layer, and service layer for the SOME / IP service generated by the target gateway. An exception handling module is used to calculate the health score of the SOME / IP service based on the communication indicators and enhanced heartbeat information, and to trigger an exception handling mechanism when the health score is lower than a preset score threshold.

[0015] According to a third aspect of the present invention, a controller is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the aforementioned vehicle-mounted SOME / IP communication processing method.

[0016] According to a fourth aspect of the present invention, a vehicle is provided, the vehicle including a vehicle body and a controller installed in the vehicle body, wherein the controller performs the aforementioned vehicle-mounted SOME / IP communication processing method.

[0017] The above-described one or more technical solutions in the embodiments of this specification have at least the following technical effects: This specification provides an in-vehicle SOME / IP communication processing method and apparatus. It converts vehicle signals from the CAN bus into SOME / IP services via a target gateway and provides them externally. The SOME / IP services include method interfaces, event interfaces, or field interfaces. For the SOME / IP services generated by the target gateway, communication metrics at the transport layer, session layer, and service layer are collected. Based on these communication metrics and enhanced heartbeat information, a health score for the SOME / IP services is calculated. When the health score falls below a preset threshold, an anomaly handling mechanism for the communication link is triggered. The communication link refers to the communication link through which vehicle signals are converted into SOME / IP services. This shortens the conversion path from CAN signals to SOME / IP services, enables observable performance across the entire communication link, supports dynamic health assessment and self-healing, and solves problems such as high communication latency, difficulty in fault location, and poor service reliability.

[0018] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0019] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart of an in-vehicle SOME / IP communication processing method according to an embodiment of the present invention is shown.

[0020] Figure 2 A block diagram of an in-vehicle SOME / IP communication processing device according to an embodiment of the present invention is shown. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0022] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0023] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0024] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0025] This invention provides a method for processing in-vehicle SOME / IP communication, aiming to solve problems such as invisible link status, delayed abnormal response, and unintelligent resource scheduling during the conversion of CAN signals to SOME / IP services in existing in-vehicle communication systems. Traditional solutions typically only complete the protocol conversion, lacking a quantitative evaluation mechanism for the operational quality of the converted SOME / IP service. This results in the inability to trigger timely recovery measures when service performance deteriorates or communication links are abnormal, affecting the stability and security of the entire vehicle's electronic system. This invention, by integrating a communication indicator monitoring module and an enhanced heartbeat mechanism into the target gateway, constructs a full-link health assessment system covering the transport layer, session layer, and service layer. When the health score falls below a threshold, it proactively executes linked operations such as log recording, human-machine alarms, remote reporting, and service restart, significantly improving the availability and self-healing capability of the SOME / IP service.

[0026] Specifically, combining Figure 1 The flowchart shown illustrates that the in-vehicle SOME / IP communication processing method includes steps 101 to 103: Step 101: Convert the vehicle signal from the CAN bus into a SOME / IP service through the target gateway and provide it to the outside world. The SOME / IP service includes a method interface, an event interface, or a field interface. Step 102: For the SOME / IP service generated by the target gateway, collect communication metrics at the transport layer, session layer, and service layer respectively; Step 103: Based on the communication indicators and enhanced heartbeat information, calculate the health score of the SOME / IP service, and trigger the abnormal handling mechanism of the communication link when the health score is lower than the preset score threshold. The communication link refers to the communication link for converting vehicle signals into SOME / IP services.

[0027] In this embodiment, vehicle signals from the CAN bus are converted into service interfaces conforming to the SOME / IP specification by the target gateway and made available for external invocation. The SOME / IP services include method interfaces, event interfaces, or field interfaces, each corresponding to different vehicle signal semantics and interaction modes.

[0028] SOME / IP (Scalable Service-Oriented Middleware Over IP) is a service-oriented communication protocol designed specifically for automotive electrical and electronic architectures (EEA) and based on IP networks (such as Ethernet). The target gateway connects different in-vehicle networks, enabling data forwarding and secure isolation between different bus protocols.

[0029] Specifically, the target gateway, as a key node connecting the traditional CAN network and the vehicle Ethernet, is responsible for parsing the raw CAN frames, extracting valid signals, and mapping them to the corresponding interface types in the SOME / IP service model according to predefined rules. This conversion process not only completes protocol adaptation but also builds a service-oriented abstraction layer, enabling upper-layer applications to access the underlying vehicle status through the standard SOME / IP protocol.

[0030] In this embodiment, the target gateway is the central gateway in the vehicle's electronic and electrical architecture, or the regional master control gateway that undertakes communication aggregation and service conversion functions in a regional centralized architecture. As a key node connecting the traditional CAN bus and the vehicle Ethernet, this gateway is responsible for performing core functions such as converting CAN signals to SOME / IP services, monitoring health status, and handling anomalies.

[0031] Furthermore, after the conversion is complete, communication metrics for the transport layer, session layer, and service layer are collected respectively. Among them: Transport layer metrics reflect the quality of underlying network transmission, such as UDP / TCP packet loss and latency; Session layer metrics reflect session management status, such as request-response matching and message sequence integrity. Service layer metrics are directly related to the availability of the SOME / IP service itself, such as API call success rate and response time.

[0032] Building upon this foundation, enhanced heartbeat information is introduced. This enhanced heartbeat information not only includes regular periodic survival signals but also embeds metadata such as service status codes and load levels for more accurate service activity assessment. The aforementioned multi-dimensional communication metrics are integrated with the enhanced heartbeat information, and a comprehensive health score is calculated using a weighted algorithm. When this score falls below a preset threshold, the system automatically triggers an anomaly handling mechanism for the communication link. Here, the communication link specifically refers to the complete data path from CAN signal input, through gateway conversion, to SOME / IP service output.

[0033] This embodiment solves the problems of difficult fault location and slow recovery caused by black-box conversion in traditional solutions, and realizes visualization, measurability and intervention of SOME / IP service links.

[0034] In an optional embodiment, calculating the health score of the SOME / IP service based on the communication metrics and enhanced heartbeat information includes: The success rate of receiving the enhanced heartbeat information is calculated based on the actual number of times the enhanced heartbeat is received and the expected number of times within the expected time. The average response time of the method interface, the packet loss rate of the event interface, the access latency of the field interface, the service call success rate, and the heartbeat reception success rate are all normalized to obtain the processed data. The health score is calculated based on the processed data and preset weight parameters.

[0035] Specifically, communication metrics include the average response time of method interfaces, the packet loss rate of event interfaces, the access latency of field interfaces, and the service call success rate. The average response time of method interfaces measures the timeliness of RPC calls; the packet loss rate of event interfaces reflects the reliability of event notifications; the access latency of field interfaces assesses the real-time performance of read and write operations; and the service call success rate is the percentage of successful calls across all interfaces.

[0036] Heartbeat reception success rate is the ratio of the number of heartbeats actually received within the expected time window to the theoretically expected number. This metric can effectively identify hidden faults such as service freezes and network partitions.

[0037] To unify the dimensions and eliminate the difference in magnitude between the indicators, the above five data items (four communication indicators and heartbeat reception success rate) are normalized, for example by using Min-Max normalization or Z-score standardization, to obtain dimensionless values ​​in the interval [0,1].

[0038] Subsequently, the normalized data is weighted and summed using preset weight parameters (e.g., response time weight 0.25, packet loss rate weight 0.30, etc., which can be dynamically configured according to the service SLA), and a health score is finally output. The closer the score is to 1, the better the service status; if it is below the threshold (e.g., 0.6), it is considered abnormal.

[0039] For example: The target gateway performs a health status assessment on the generated SOME / IP service "Climate ControlService". This service provides method interfaces (such as setting the target temperature), event interfaces (such as fan speed change notifications), and field interfaces (such as reading the current vehicle interior temperature), and is frequently called by multiple clients such as the cockpit domain controller, mobile applications, and voice assistants.

[0040] Within a preset monitoring period (e.g., 30 seconds), the target gateway continuously collects multiple communication metrics related to the service. Specifically, this includes: an average response time of 45 milliseconds for the method interface (the average time from receiving a temperature setting request to returning a response); an 8% packet loss rate for the event interface (meaning that out of 100 fan speed change events sent within this period, only 92 were successfully received by the subscriber); an access latency of 30 milliseconds for the field interface (the average round-trip time for reading the current temperature field); and an overall service call success rate of 92% (meaning that out of 250 total calls, 230 were successfully completed, with the remainder failing due to timeouts or internal errors).

[0041] Meanwhile, the target gateway calculates the heartbeat reception success rate based on an enhanced heartbeat mechanism. This enhanced heartbeat is actively sent by the gateway once per second, carrying metadata such as service identifier, timestamp, CPU load, and memory usage, in addition to the regular liveness signal. The receiving end must return an acknowledgment response within 500 milliseconds; otherwise, it is considered lost. Theoretically, 30 heartbeats should be received within the aforementioned monitoring period, and 25.5 were actually received (based on a sliding window), corresponding to a heartbeat reception success rate of 85%.

[0042] To standardize the dimensions of each indicator and eliminate differences in magnitude, the gateway normalizes the five raw data items, mapping them to the [0,1] interval, where a value closer to 1 indicates better performance. For indicators such as response time, packet loss rate, and access latency, smaller values ​​are preferred, and inverse normalization is used; for indicators such as call success rate and heartbeat reception success rate, larger values ​​are preferred, and linear normalization is directly applied. After processing, the normalized values ​​for each indicator are as follows: method response time 0.55, event packet loss rate 0.92, field access latency 0.40, service call success rate 0.92, and heartbeat reception success rate 0.85.

[0043] Subsequently, the target gateway loads preset weight parameters according to the Service Level Agreement (SLA) requirements of the SOME / IP service. Considering that users are highly sensitive to the real-time nature of temperature setting operations, the method interface response time is assigned a weight of 0.25; overall service availability is crucial, and the call success rate is also assigned a weight of 0.25; event reliability affects system collaboration, so the packet loss rate is weighted at 0.20; field access latency has a relatively small impact on user experience, so it is weighted at 0.15; and heartbeat, as an auxiliary indicator of activity, is weighted at 0.15. Multiplying each normalized value by its corresponding weight and summing the results yields a comprehensive health score of 0.739.

[0044] The health score threshold is set to 0.70. Since the current score of 0.739 is higher than this threshold, the system determines the service is in a sub-healthy but acceptable state, recording only monitoring logs without triggering alarms. If network congestion subsequently causes the packet loss rate to rise to 25%, the normalized packet loss index will drop to 0.75, and the health score may drop to 0.68, below the threshold. At this point, the system will automatically initiate anomaly handling procedures, including recording a fault snapshot, sending alarms to the human-machine interface, uploading status information to the remote diagnostic platform, and attempting to restart the SOME / IP service.

[0045] In an optional embodiment, the step of triggering an anomaly handling mechanism for the communication link when the health score is lower than a preset score threshold includes: When the health score is lower than the preset score threshold, a fault log is recorded locally, an alarm is sent to the in-vehicle human-machine interaction system, and the service status information is uploaded to the remote diagnostic platform to perform a restart operation on the SOME / IP service.

[0046] It should be noted that when the health score falls below a preset threshold, this embodiment implements a multi-level, closed-loop anomaly handling mechanism, specifically including: Locally record fault logs, writing information such as the time of the anomaly, health score details, snapshots of indicators at each level, and heartbeat status to non-volatile storage for subsequent diagnostic analysis; Send alarm prompts to the in-vehicle human-machine interface (HMI) system and notify the driver or maintenance personnel through the instrument panel, central control screen and other means to improve user experience; Upload service status information to the remote diagnostic platform, and use the vehicle T-Box or OTA channel to send structured fault data to the cloud to support remote operation and maintenance and big data analysis; The SOME / IP service is restarted, and the abnormal service process is automatically terminated and reloaded on the gateway side to attempt to restore service functionality, thus achieving self-healing capability.

[0047] This mechanism ensures a complete closed loop from perception, alarm, reporting, and recovery, significantly shortening fault recovery time and improving the robustness of the vehicle's electronic and electrical architecture.

[0048] In an optional embodiment, the conversion of vehicle signals from the CAN bus into SOME / IP services via a target gateway includes: When the sampling frequency of the vehicle signal is higher than the target frequency or the signal variation amplitude exceeds a preset amplitude threshold, the vehicle signal from the CAN bus is converted into SOME / IP services through the hardware acceleration unit integrated in the target gateway. The hardware acceleration unit preferably uses an FPGA (Field-Programmable Gate Array) or DSP (Digital Signal Processor) chip. FPGAs have strong parallel processing capabilities and low latency, making them suitable for high-speed signal stream processing; DSPs excel at complex mathematical operations and have advantages in signal filtering, feature extraction, and other scenarios. Both can offload the main control CPU, improving the overall throughput of the gateway.

[0049] Specifically, to address the challenges posed by high-frequency or drastically changing vehicle signals to the gateway's processing capabilities, this invention introduces a dynamic triggering mechanism: when the sampling frequency of the vehicle signal is detected to be higher than the target frequency (e.g., >100Hz) or the signal change amplitude exceeds a preset amplitude threshold (e.g., sudden speed change >20km / h / s), the hardware acceleration unit integrated in the target gateway is automatically activated to perform SOME / IP conversion.

[0050] This avoids resource bottlenecks and latency jitter caused by processing high-frequency signals on a general-purpose CPU, ensuring the real-time performance and determinism of critical signals.

[0051] In an optional embodiment, the conversion of vehicle signals from the CAN bus into SOME / IP services via a target gateway includes: Load a predefined DBC file, which defines the CAN message identifier, signal start bit, signal length, scaling factor, and physical units; Based on the DBC file, the original data frames received from the CAN bus are parsed to obtain the vehicle signals; The vehicle signals are mapped to the interfaces corresponding to the SOME / IP service.

[0052] Specifically, to achieve accurate mapping of CAN signals to the SOME / IP interface, this invention employs a DBC (DatabaseCAN) file-driven parsing mechanism. First, a predefined DBC file is loaded, explicitly defining the CAN message identifier (CAN ID), the start bit of each signal, signal length, scaling factor (Scale / Offset), and physical units. Based on this DBC file, the raw data frames received from the CAN bus are parsed to reconstruct physically meaningful vehicle signals (e.g., "engine speed = 2500 rpm"). Then, the parsed vehicle signals are semantically mapped to the interfaces corresponding to the SOME / IP service. This approach ensures standardized, configurable, and maintainable signal conversion, avoiding the lack of flexibility inherent in hard-coding.

[0053] In an optional embodiment, mapping the vehicle signal to the interface corresponding to the SOME / IP service includes: The vehicle signals representing the steady-state state are mapped to a method interface to respond to external query requests; Map vehicle signals that characterize discrete state changes to event interfaces; The configuration parameters that support remote read and write are mapped to field interfaces, providing read, write, and change notification functions.

[0054] Specifically, the mapping rules follow the semantic characteristics of signals. Vehicle signals representing steady-state conditions (such as current vehicle speed and battery voltage) are mapped to method interfaces for external querying on demand; vehicle signals representing discrete state changes (such as door opening / closing and brake pedal pressing) are mapped to event interfaces, which are actively pushed when the state changes; configuration parameters that support remote reading and writing (such as headlight brightness settings and driving mode selection) are mapped to field interfaces, providing three functions: read (Getter), write (Setter), and change notification (Notifier).

[0055] This semantic mapping makes SOME / IP services more in line with the design principles of Service-Oriented Architecture (SOA), improving the understandability and reusability of the interface.

[0056] For example: A certain smart car supports the following functions: The instrument panel or mobile app can be used to check the current low beam headlight status (on / off); Users can remotely turn the low beam headlights on / off via the central control screen; When the low beam status changes (such as when the automatic headlights are triggered), all subscribers (such as daytime running light modules and HUDs) must be notified.

[0057] This function involves three interaction modes: read, write, and status change notification, and requires a standardized service interface provided by SOME / IP. The underlying signals come from the CAN bus and need to be converted by the target gateway.

[0058] The specific steps include: Step 1: Parse the raw CAN signal based on the DBC file The vehicle development team defines DBC entries; 0x400 message: periodically sent by the Body Control Controller (BCM) to indicate the current physical status of the low beam headlights; 0x401 message: Sent by the gateway to send control commands to the BCM.

[0059] The target gateway loads this DBC file upon startup. When it receives a CAN frame 0x400 [01 00 ...], it automatically parses the following based on the definition of LowBeamState in the DBC file (start bit 0, length 1, no scaling): Low beam headlight current status = On (1) Similarly, when the upper-layer application requests "turn on low beam headlights", the target gateway packages the value 1 into the data field of CAN ID 0x401 and sends it according to the bit definition of SetLowBeam in DBC.

[0060] Step 2: Map the signal semantics to the SOME / IP field interface. Gateway analysis of "low beam" signal usage characteristics: It needs to be queried (steady-state read), and requires a Getter; It can be remotely configured (two-way control), requires a setter; Status changes need to be actively broadcast (such as automatic headlight triggering), requiring a Notifier.

[0061] This aligns perfectly with the typical application scenario for the Field interface. Therefore, the gateway performs the following mapping: Create a SOME / IP service: LightingService (Service ID = 0x8801) Define field: LowBeam Getter method: getLowBeam(), bool Setter method: setLowBeam(bool on) Notifier event: onLowBeamChanged(bool on) In the SOME / IP standard, fields are not independent message types, but rather logical abstractions implemented by a combination of Getter / Setter methods and Notifier events.

[0062] When the LowBeamState on the CAN bus changes (e.g., from 0 to 1), the target gateway not only updates its internal state but also automatically triggers the onLowBeamChanged(true) event to notify all subscribers.

[0063] When setLowBeam(false) is called remotely, the gateway converts false into the CAN signal SetLowBeam=0, and packages it into a CAN ID 0x401 frame according to the DBC rules and sends it to the BCM.

[0064] Optionally, after mapping the vehicle signal to the interface corresponding to the SOME / IP service, the method further includes: The SOME / IP service is registered and published on the target gateway for discovery and invocation by other electronic control units via the vehicle Ethernet.

[0065] In this embodiment, after the signal-to-interface mapping is completed, the target gateway also needs to perform a service registration and publishing process. The generated SOME / IP service (including metadata such as Service ID, Instance ID, and interface list) is registered to the local service registry, and service availability information is broadcast on the vehicular Ethernet via the SOME / IP-SD (Service Discovery) protocol.

[0066] Therefore, other electronic control units (ECUs) can automatically discover and call the SOME / IP service through the standard service discovery mechanism, without the need to pre-configure IP addresses or ports, thus achieving true plug-and-play and dynamic networking capabilities.

[0067] In summary, the vehicle-mounted SOME / IP communication processing method provided in this specification converts vehicle signals from the CAN bus into SOME / IP services via a target gateway and provides them externally. The SOME / IP services include method interfaces, event interfaces, or field interfaces. For the SOME / IP services generated by the target gateway, communication metrics at the transport layer, session layer, and service layer are collected. Based on these communication metrics and enhanced heartbeat information, a health score for the SOME / IP services is calculated. When the health score falls below a preset threshold, an anomaly handling mechanism for the communication link is triggered. Here, the communication link refers to the communication link through which vehicle signals are converted into SOME / IP services. This shortens the conversion path from CAN signals to SOME / IP services, enables observable performance across the entire communication link, supports dynamic health assessment and self-healing, and solves problems such as high communication latency, difficulty in fault location, and poor service reliability.

[0068] Based on the same inventive concept, combined with Figure 2 As shown, this embodiment of the invention also provides an in-vehicle SOME / IP communication processing device, comprising: The conversion module is used to convert vehicle signals from the CAN bus into SOME / IP services through the target gateway and provide them to the outside world. The SOME / IP services include method interfaces, event interfaces, or field interfaces. The acquisition module is used to collect communication metrics of the transport layer, session layer, and service layer for the SOME / IP service generated by the target gateway. An exception handling module is used to calculate the health score of the SOME / IP service based on the communication indicators and enhanced heartbeat information, and to trigger an exception handling mechanism when the health score is lower than a preset score threshold.

[0069] Optionally, the exception handling module is also used for: The success rate of receiving the enhanced heartbeat information is calculated based on the actual number of times the enhanced heartbeat is received and the expected number of times within the expected time. The average response time of the method interface, the packet loss rate of the event interface, the access latency of the field interface, the service call success rate, and the heartbeat reception success rate are all normalized to obtain the processed data. The health score is calculated based on the processed data and preset weight parameters.

[0070] Optionally, the exception handling module is also used for: When the health score is lower than the preset score threshold, a fault log is recorded locally, an alarm is sent to the in-vehicle human-machine interaction system, and the service status information is uploaded to the remote diagnostic platform to perform a restart operation on the SOME / IP service.

[0071] Optionally, the conversion module is also used for: When the sampling frequency of the vehicle signal is higher than the target frequency or the signal change amplitude exceeds a preset amplitude threshold, the vehicle signal from the CAN bus is converted into SOME / IP service through the hardware acceleration unit integrated in the target gateway.

[0072] Optionally, the hardware acceleration unit may include an FPGA or a DSP chip.

[0073] Optionally, the conversion module is also used for: Load a predefined DBC file, which defines the CAN message identifier, signal start bit, signal length, scaling factor, and physical units; Based on the DBC file, the original data frames received from the CAN bus are parsed to obtain the vehicle signals; The vehicle signals are mapped to the interfaces corresponding to the SOME / IP service.

[0074] Optionally, the conversion module is also used for: The vehicle signals representing the steady-state state are mapped to a method interface to respond to external query requests; Map vehicle signals that characterize discrete state changes to event interfaces; The configuration parameters that support remote read and write are mapped to field interfaces, providing read, write, and change notification functions.

[0075] Optionally, the conversion module is also used for: The SOME / IP service is registered and published on the target gateway for discovery and invocation by other electronic control units via the vehicle Ethernet.

[0076] In summary, the vehicle-mounted SOME / IP communication processing device provided in this specification converts vehicle signals from the CAN bus into SOME / IP services via a target gateway and provides them externally. The SOME / IP services include method interfaces, event interfaces, or field interfaces. For the SOME / IP services generated by the target gateway, communication metrics at the transport layer, session layer, and service layer are collected. Based on these communication metrics and enhanced heartbeat information, a health score for the SOME / IP services is calculated. When the health score falls below a preset threshold, an anomaly handling mechanism for the communication link is triggered. Here, the communication link refers to the communication link through which vehicle signals are converted into SOME / IP services. This shortens the conversion path from CAN signals to SOME / IP services, enables observable performance across the entire communication link, supports dynamic health assessment and self-healing, and solves problems such as high communication latency, difficulty in fault location, and poor service reliability.

[0077] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the vehicle-mounted SOME / IP communication processing device described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0078] Based on the same inventive concept, embodiments of the present invention also provide a controller, which includes an in-vehicle SOME / IP communication processing device, a memory, a processor, and a communication unit. The memory stores machine-readable instructions that can be executed by the processor. When the controller is running, the processor and the memory communicate with each other via a bus. The processor executes the machine-readable instructions and performs the in-vehicle SOME / IP communication processing method.

[0079] The memory, processor, and communication unit are electrically connected directly or indirectly to achieve signal transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The in-vehicle SOME / IP communication processing device includes at least one software functional module that can be stored in the memory in the form of software or firmware. The processor is used to execute the executable module stored in the memory (e.g., the software functional module or computer program included in the in-vehicle SOME / IP communication processing device).

[0080] The memory can be, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc.

[0081] In some embodiments, the processor is used to perform one or more functions described in this embodiment. In some embodiments, the processor may include one or more processing cores (e.g., a single-core processor (S) or a multi-core processor (S)).

[0082] In this embodiment, the memory is used to store the program, and the processor is used to execute the program after receiving the execution instruction. The process definition method disclosed in any implementation of this embodiment can be applied to the processor, or implemented by the processor.

[0083] The communication unit is used to establish communication connections between the controller and other devices via the network, and to send and receive data via the network.

[0084] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the controller described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0085] Based on the same inventive concept, embodiments of the present invention also provide a vehicle, including a vehicle body and a controller installed in the vehicle body, the controller being used to implement the aforementioned vehicle-mounted SOME / IP communication processing method.

[0086] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the vehicle controller described above can be referred to the corresponding process in the aforementioned method, and will not be elaborated further here.

[0087] The above are merely various embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A vehicle-mounted SOME / IP communication processing method, characterized in that, include: Vehicle signals from the CAN bus are converted into SOME / IP services through the target gateway and provided externally. The SOME / IP services include method interfaces, event interfaces, or field interfaces. For the SOME / IP service generated by the target gateway, communication metrics at the transport layer, session layer, and service layer are collected respectively. Based on the communication metrics and enhanced heartbeat information, a health score for the SOME / IP service is calculated. When the health score is lower than a preset score threshold, an abnormal handling mechanism for the communication link is triggered. The communication link refers to the communication link for converting vehicle signals into the SOME / IP service.

2. The method according to claim 1, characterized in that, The communication metrics include the average response time of the method interface, the packet loss rate of the event interface, the access latency of the field interface, and the service call success rate. The calculation of the health score of the SOME / IP service based on the communication metrics and enhanced heartbeat information includes: The success rate of receiving the enhanced heartbeat information is calculated based on the actual number of times the enhanced heartbeat is received and the expected number of times within the expected time. The average response time of the method interface, the packet loss rate of the event interface, the access latency of the field interface, the service call success rate, and the heartbeat reception success rate are all normalized to obtain the processed data. The health score is calculated based on the processed data and preset weight parameters.

3. The method according to claim 1, characterized in that, The mechanism for triggering anomaly handling of the communication link when the health score is lower than a preset score threshold includes: When the health score is lower than the preset score threshold, a fault log is recorded locally, an alarm is sent to the in-vehicle human-machine interaction system, and the service status information is uploaded to the remote diagnostic platform to perform a restart operation on the SOME / IP service.

4. The method according to claim 1, characterized in that, The process of converting vehicle signals from the CAN bus into SOME / IP services via the target gateway includes: When the sampling frequency of the vehicle signal is higher than the target frequency or the signal change amplitude exceeds a preset amplitude threshold, the vehicle signal from the CAN bus is converted into SOME / IP service through the hardware acceleration unit integrated in the target gateway.

5. The method according to claim 4, characterized in that, The hardware acceleration unit includes an FPGA or a DSP chip.

6. The method according to claim 1, characterized in that, The process of converting vehicle signals from the CAN bus into SOME / IP services via the target gateway includes: Load a predefined DBC file, which defines the CAN message identifier, signal start bit, signal length, scaling factor, and physical units; Based on the DBC file, the original data frames received from the CAN bus are parsed to obtain the vehicle signal; The vehicle signals are mapped to the interfaces corresponding to the SOME / IP service.

7. The method according to claim 6, characterized in that, The step of mapping the vehicle signal to the interface corresponding to the SOME / IP service includes: The vehicle signals representing the steady-state state are mapped to a method interface to respond to external query requests; Map vehicle signals that characterize discrete state changes to event interfaces; The configuration parameters that support remote read and write are mapped to field interfaces, providing read, write, and change notification functions.

8. The method according to claim 7, characterized in that, After mapping the vehicle signal to the interface corresponding to the SOME / IP service, the method further includes: The SOME / IP service is registered and published on the target gateway for discovery and invocation by other electronic control units via the vehicle Ethernet.

9. A vehicle-mounted SOME / IP communication processing device, characterized in that, include: The conversion module is used to convert vehicle signals from the CAN bus into SOME / IP services through the target gateway and provide them to the outside world. The SOME / IP services include method interfaces, event interfaces, or field interfaces. The acquisition module is used to collect communication metrics of the transport layer, session layer, and service layer for the SOME / IP service generated by the target gateway. An exception handling module is used to calculate the health score of the SOME / IP service based on the communication indicators and enhanced heartbeat information, and to trigger an exception handling mechanism when the health score is lower than a preset score threshold.

10. A vehicle, characterized in that, The vehicle includes a vehicle body and a controller installed in the vehicle body, wherein the controller executes the vehicle-mounted SOME / IP communication processing method according to any one of claims 1-8.

Images