SOA service communication method, device and system and vehicle

Abstract

The embodiment of the invention provides an SOA service communication method, device and system and a vehicle. The method comprises the following steps: in response to a service request initiated by a second service node in the vehicle, configuring a service type identification field and first service data in a first CAN XL data frame, and obtaining the configured first CAN XL data frame; the configured first CAN XL data frame is sent to the second service node through a CAN XL network, and the second service node is used for distributing the first service data to a corresponding protocol stack for processing according to the service type identification field. The method is used for realizing SOA service communication and improving the SOA service communication efficiency.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to an SOA service communication method, apparatus, system, and vehicle. Background Technology

[0002] Service-Oriented Architecture (SOA) is a standard component model defined in a loosely coupled manner, which enables the interconnection of application functional units through well-defined interfaces and contracts.

[0003] Currently, in existing technologies, various electronic devices inside vehicles mainly communicate via the Controller Area Network (CAN) bus to achieve SOA services.

[0004] However, existing CAN networks are prone to SOA service conflicts, resulting in low SOA service communication efficiency. Summary of the Invention

[0005] This application provides an SOA service communication method, apparatus, system, and vehicle to improve SOA service communication efficiency.

[0006] In a first aspect, embodiments of this application provide an SOA service communication method, including:

[0007] In response to a service request initiated by a second service node in the vehicle, the service type identifier field and the first service data in the first CAN XL data frame are configured, and the configured first CAN XL data frame is obtained.

[0008] The configured first CAN XL data frame is sent to the second service node through the CAN XL network. The second service node is used to distribute the first service data to the corresponding protocol stack for processing according to the service type identifier field.

[0009] In one possible implementation, configuring the service type identifier field in the first CAN XL data frame includes:

[0010] Obtain a predefined mapping table, in which the value of each service type identifier field corresponds to a different service type or protocol type;

[0011] Based on the service characteristics of the second service node and the mapping table, the value of the service type identifier field configured in the first CAN XL data frame is determined. The value of the service type identifier field in the first CAN XL data frame is used by the second service node to determine the corresponding protocol stack.

[0012] In one possible implementation, configuring the first service data in the first CAN XL data frame includes:

[0013] Determine the encapsulation strategy based on the data type and size of the first service data;

[0014] Based on the encapsulation strategy, the first service data is encapsulated into one or more first CAN XL data frames.

[0015] In one possible implementation, after responding to a service request initiated by a second service node in the vehicle, the method further includes:

[0016] In the first CAN XL data frame, a virtual network identifier field and a value of the virtual network identifier field are configured. The virtual network identifier field is used to identify the logical network to which the first service node belongs. Each logical network corresponds to at least one functional domain in the vehicle. The second service node is used to filter data from non-target logical networks based on the value of the virtual network identifier field.

[0017] In one possible implementation, after responding to a service request initiated by a second service node in the vehicle, the method further includes:

[0018] The service address is configured in the first CAN XL data frame, and the second service node is used to perform service addressing based on the service address and the service type identifier field.

[0019] In one possible implementation, prior to responding to a service request initiated by a second service node in the vehicle, the method further includes:

[0020] The registration request is encapsulated in the second CANXL data frame.

[0021] Configure the service type identifier field in the second CANXL data frame as a service discovery type;

[0022] Configure the service identifier, service instance identifier, service version number, service address, and virtual network identifier fields in the data fields of the second CANXL data frame;

[0023] Based on the configured second CANXL data frame, a service registration request is initiated to the service registry center in the vehicle.

[0024] In one possible implementation, it also includes:

[0025] In response to a service request initiated by a target node in the target vehicle network, the protocol type identifier field in the third CAN XL data frame is configured, and the configured third CAN XL data frame is obtained. The protocol format of the target vehicle network and the CAN XL network are different.

[0026] The configured third CAN XL data frame is sent to the gateway interface layer through the CAN XL network. The gateway interface layer is used to convert the third CAN XL data frame into the protocol format corresponding to the target vehicle network according to the protocol type identifier field, and then send it to the target vehicle network.

[0027] Secondly, embodiments of this application provide an SOA service communication device, comprising:

[0028] The data frame configuration module is used to respond to a service request initiated by the second service node in the vehicle, configure the service type identifier field and the first service data in the first CAN XL data frame, and obtain the configured first CAN XL data frame.

[0029] The data frame sending module is used to send the configured first CAN XL data frame to the second service node through the CAN XL network. The second service node is used to distribute the first service data to the corresponding protocol stack for processing according to the service type identifier field.

[0030] Thirdly, embodiments of this application provide an SOA service communication system, including:

[0031] The service node layer is used to generate and / or receive CAN XL data frames;

[0032] The CAN XL network layer is used to transmit the CAN XL data frames generated by the first service node in the service node layer to the second service node in the service node layer.

[0033] The service management layer is used to register the first service node according to the service registration request initiated by the first service node, and to feed back the call information of the first service node to the second service node according to the service discovery request initiated by the second service node.

[0034] The gateway interface layer is used to perform protocol conversion on the CAN XL data frames and send them to the target vehicle network, or to receive data frames from the target vehicle network and convert them into CAN XL data frames, wherein the protocol format of the target vehicle network is different from the protocol format of the CAN XL data frames.

[0035] Fourthly, embodiments of this application provide a vehicle, including: a vehicle body and the aforementioned SOA service communication system.

[0036] The SOA service communication method, apparatus, system, and vehicle provided in this application embodiment can identify service types by configuring a service type identifier field (SDT field) in the CAN XL data frame. The second service node can distribute the first service data to the corresponding protocol stack for processing by parsing the value in the SDT field, thereby realizing service-level data routing. This allows services with different characteristics to coexist on the same physical network without interfering with each other, achieving service isolation and improving SOA service communication efficiency. Attached Figure Description

[0037] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0038] Figure 1 This is a schematic diagram of the SOA service communication system framework provided in the embodiments of this application;

[0039] Figure 2 A flowchart of the SOA service communication method provided in the embodiments of this application;

[0040] Figure 3 This is a schematic diagram of the data frame structure provided in an embodiment of this application;

[0041] Figure 4 This is a schematic diagram of the service registration process provided in the embodiments of this application;

[0042] Figure 5 This is a schematic diagram of the cross-network communication process provided in an embodiment of this application;

[0043] Figure 6 This is a schematic diagram of the SOA service communication device provided in this application;

[0044] Figure 7 A schematic diagram of the structure of the electronic device provided in this application.

[0045] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0047] As automotive electronic and electrical architectures evolve from traditional distributed architectures to domain architectures and centralized architectures, Service-Oriented Architecture (SOA) has become a core technological path for achieving vehicle intelligence and software-defined architecture. SOA is a distributed architecture that enables cross-domain communication through service registration, discovery, and invocation. In in-vehicle scenarios, SOA must meet requirements for high real-time performance, low latency, and cross-network compatibility. In SOA scenarios, vehicles need to achieve cross-domain communication (such as body control domain, cockpit domain, and autonomous driving domain) through unified service interfaces (such as the SOME / IP protocol), while also supporting high-bandwidth data transmission (such as diagnostic data, multimedia streaming media, and sensor data). However, traditional vehicle networks have the following problems: (1) It is difficult to balance bandwidth and cost: Although vehicle Ethernet can support high bandwidth requirements, its hardware cost (such as switches and wiring harnesses) is significantly higher than that of traditional Controller Area Network (CAN) networks; (2) Poor protocol compatibility: Traditional vehicle networks need to be compatible with classic CAN / CAN FD nodes (such as door control and lighting control), and also need to cooperate with vehicle Ethernet (such as AP gateways and smart cockpits); (3) Low service isolation and security: SOA services need to avoid cross-domain interference through logical isolation (such as virtual networks), and also need to support dynamic service discovery and addressing.

[0048] To address the aforementioned issues, this application provides a method, apparatus, system, and vehicle for implementing automotive SOA service communication based on Controller Area Network eXtended Length (CANXL). This method can meet the high bandwidth requirements of SOA, be compatible with traditional CAN networks, reduce overall vehicle costs, and achieve SOA service isolation, thereby improving service isolation performance.

[0049] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0050] Figure 1 This is a schematic diagram of the SOA service communication system framework provided in the embodiments of this application, such as... Figure 1 As shown, the system adopts a layered architecture design, including four main parts: service node layer 10, CANXL network layer 20, service management layer 30, and gateway interface layer 40.

[0051] The service node layer 10 mainly includes nodes such as electronic control units (ECUs), sensors, and actuators. Each node has the ability to provide or consume services. For example, the first service node can generate a first CAN XL data frame, and the second service node can receive the generated CAN XL data frame and consume the service.

[0052] CANXL Network Layer 20: As the physical transmission medium, it provides a high-speed data transmission channel for transmitting CAN XL data frames generated by the first service node in the service node layer to the second service node in the service node layer.

[0053] Service Management Layer 30: Used to register the first service node according to the service registration request initiated by the first service node, and to feed back the call information of the first service node to the second service node according to the service discovery request initiated by the second service node.

[0054] In the vehicle network, the service management layer is responsible for service registration, discovery, and status monitoring. The central domain controller, acting as the service registry, is responsible for service registration.

[0055] During service registration, service nodes need to initiate a service registration request to the service management layer via the CANXL network. When a service consumer needs to invoke a service, it needs to initiate a service discovery request to the service management layer. The service management layer then feeds back the service provider's information to the service consumer, enabling the service consumer to communicate with the service producer and obtain service data.

[0056] In addition, the service management layer can also proactively initiate heartbeat checks to service nodes to monitor their status.

[0057] Gateway Interface Layer 40: Used to perform protocol conversion on CAN XL data frames and send them to the target vehicle network, or to receive data frames from the target vehicle network and convert them into CAN XL data frames.

[0058] The protocol format of the target vehicle network is different from that of the CAN XL data frame.

[0059] Gateway interface layer 40 enables cross-network communication. Specifically, service nodes registered in the service management layer can transmit CAN XL data frames to the gateway interface via the CANXL network. The gateway interface then converts the protocol format and feeds the data back to the external network (e.g., the target vehicle network).

[0060] In this embodiment, the vehicle's area controller can be selected as the gateway in the gateway interface layer to realize protocol conversion and data exchange with other vehicle networks such as vehicle Ethernet and traditional CAN network.

[0061] In this embodiment, upon system startup, the virtual networks are first initialized, and the parameters of each virtual network are configured. Then, the service registry and health monitoring are started. Finally, each service node begins registering its services. Clients obtain service instances through the service discovery mechanism and communicate with them.

[0062] The CAN XL network has the following characteristics: (1) High bandwidth: data transmission rate reaches 20 megabits per second; (2) Large data field: maximum 2048 bytes of data field, which can be encapsulated into Ethernet; (3) Compatibility: coexistence with CAN and CANFD; (4) Field enhancement: introduction of SDT (Service Data Unit Type), VCID (Virtual CAN Network ID), and AF (Receive Field). By utilizing the characteristics of CANXL, SOA service communication can be realized, which will be described in detail below through specific examples.

[0063] The traditional CAN XL protocol lacks a service type identification mechanism, resulting in the inability to achieve dynamic routing and protocol stack distribution in service communication. Data of different service types cannot be distinguished on the same physical network, leading to service conflicts and low communication efficiency. To address this issue, Figure 2 This is a flowchart of an SOA service communication method provided in an embodiment of this application. This method can be applied to vehicles, taking the first service node in the vehicle as the execution subject as an example. Figure 2 As shown, the method includes the following steps:

[0064] Step 210: In response to the service request initiated by the second service node in the vehicle, configure the service type identifier field and the first service data in the first CAN XL data frame, and obtain the configured first CAN XL data frame;

[0065] Step 220: Send the configured first CAN XL data frame to the second service node through the CAN XL network.

[0066] The second service node is used to distribute the first service data to the corresponding protocol stack for processing based on the service type identifier field.

[0067] In this embodiment, by configuring a Service Type Identifier (SDT) field in the CAN XL data frame, the service type can be identified. The second service node distributes the first service data to the corresponding protocol stack for processing by parsing the value in the SDT field. This enables service-level data routing, allowing services with different characteristics to coexist on the same physical network without interfering with each other, achieving service isolation and improving SOA service communication efficiency.

[0068] Regarding step 210 above, CAN XL is an evolved version of the CAN protocol, supporting a maximum data field of 2048 bytes and a rate of 20 megabits per second. The core improvements of CAN XL include: (1) Large data field. The maximum data field of traditional CANFD is 64 bytes, while CANXL extends it to 2048 bytes, supporting the encapsulation of Ethernet protocol stacks (such as SOME / IP). (2) Field enhancement: The introduction of the SDT field (i.e., the service type identifier field) enables service type identification.

[0069] Among them, the SOME / IP protocol is an Ethernet-based SOA communication protocol that supports service interface definition, status monitoring, and cross-domain communication.

[0070] In this embodiment, various ECUs, sensors, and actuators in the vehicle can be used as service nodes. Specifically, an ECU may include an engine control unit, an electric power steering control unit, a tire pressure monitoring unit, etc.

[0071] In this embodiment, service data can refer to the data collected or detected by the service node. Taking the first service node as a sensor as an example, the first service data can be image data, 3D point cloud data, and video data collected by the sensor.

[0072] In particular, because CAN XL data frames use service data with large data field characteristics and the CAN XL protocol supports a maximum data field of 2048 bytes, it provides key support for the transmission of SOA service data, enabling a single CAN XL frame to completely encapsulate complex service interface data, including complete SOME / IP service messages, diagnostic service data blocks, or compressed multimedia service data.

[0073] Specifically, in some implementations, when configuring the first service data in the first CAN XL data frame, the first service data can first be serialized according to the SOA service interface definition, and then an appropriate encapsulation strategy is selected according to the data type and data size. Based on the encapsulation strategy, the first service data is then encapsulated into one or more first CAN XL data frames.

[0074] For example, taking the first service data as big data such as video or images, for big data transmission, a fragmentation mechanism can be adopted to encapsulate the first service data into multiple first CAN XL frames for transmission in sequence. This solves the problems of insufficient bandwidth and limited data carrying capacity of traditional CAN networks in SOA applications.

[0075] In this embodiment, the first service node can register in the service registry first, and the second service node can initiate a service data request through the service registry to request the service data of the first service node.

[0076] Figure 3 This is a schematic diagram of the data frame structure provided in the embodiments of this application, such as... Figure 3 As shown, in the CANXL data frame, the Service Type Identifier field (SDT field) is used for identification and routing, and is the core of SOA service identification. In some embodiments, a predefined mapping table can be obtained; then, based on the service characteristics of the second service node and the mapping table, the value of the Service Type Identifier field configured in the first CAN XL data frame is determined.

[0077] In the mapping table, the value of each service type identifier field corresponds to a different service type or protocol type. The value of the service type identifier field in the first CAN XL data frame is used by the second service node to determine the corresponding protocol stack.

[0078] In this embodiment, the mapping table is used to describe the service type or protocol type corresponding to the value of each service type identifier field (hereinafter referred to as SDT value).

[0079] For example, the SDT value can be 0x01, 0x02, etc. Here, SDT=0x01 represents SOME / IP service, and SDT=0x02 represents diagnostic service. By predefining SDT values, service type routing can be implemented, replacing protocol identifiers (such as IP protocol numbers) in traditional Ethernet.

[0080] Through a predefined SDT value mapping table, each SDT value corresponds to a specific service type or protocol type. When a service node sends data, it sets the corresponding SDT value according to the service characteristics, and the receiving node distributes the data to the corresponding processing module by parsing the SDT value. This mechanism achieves service-level data routing, enabling services with different characteristics to coexist on the same physical network without interfering with each other. Examples include service discovery messages, SOME / IP service messages, diagnostic messages, Ethernet frames, video streams, and audio streams.

[0081] The first service node sets the Service Type Identifier (SDT) field value based on service characteristics (such as SOME / IP service, Ethernet frame, video stream). The second service node parses the SDT field and directly transmits the data to the corresponding protocol stack (such as SOME / IP protocol stack or Ethernet protocol stack). For example, when SDT=0x01, the second service node distributes the data to the SOME / IP protocol stack for parsing; when SDT=0x02, the data is transmitted to the Ethernet protocol stack for processing. This mechanism achieves service-level data routing, avoiding data packet loss caused by service conflicts in traditional CAN networks and the problem of ambiguous service routing in SOA scenarios, while also improving the efficiency of service communication. Furthermore, the predefined mapping table of the SDT field supports dynamic expansion (such as adding SDT=0x03 to represent diagnostic services), enabling the system to flexibly adapt to new service types in the future, significantly enhancing the scalability of SOA services.

[0082] Regarding step 220 above, the first service node and the second service node communicate via the CANXL network layer. The CANXL network layer, as the physical transmission medium, provides a high-speed data transmission channel with a data transmission rate of up to 20 megabits per second, reducing latency. In contrast, the traditional CANFD has a maximum transmission rate of 1 megabit per second and only supports a maximum of 64 direct data fields, requiring multiple data fragments for transmission, resulting in high load and latency issues.

[0083] Since each Service Type Identifier (SDT) field corresponds to a specific service type or protocol type, when the second service node receives the first CAN XL data frame containing the SDT field, it can parse the SDT value and distribute the first service data to the corresponding processing module. This achieves service-level data routing, enabling services with different characteristics to coexist on the same physical network without interfering with each other. Examples include service discovery messages, SOME / IP service messages, diagnostic messages, Ethernet frames, video streams, and audio streams.

[0084] Because vehicles need to achieve cross-domain communication (such as body control domain, cockpit domain, autonomous driving domain, etc.) through a unified service interface (such as SOME / IP protocol), and in traditional in-vehicle network communication, services of different functional domains (such as body control service and intelligent driving service) share the same physical network, there is a risk of cross-domain interference, leading to reduced service stability. To address this issue, in some embodiments, a virtual network identifier field (virtual CAN network ID, i.e., VCID field) can be configured in the CAN XL data frame.

[0085] Specifically, the first service node can configure the virtual network identifier field and its value in the first CAN XL data frame.

[0086] The virtual network identifier field is used to identify the logical network to which the first service node belongs, and each logical network corresponds to at least one functional domain in the vehicle.

[0087] After the second service node receives the first CAN XL data frame containing the VCID field, it can filter data from non-target logical networks based on the value of the virtual network identifier field.

[0088] In this embodiment, the system divides the entire vehicle into multiple logical networks (e.g., VCID=0x10 represents the body control domain, VCID=0x20 represents the autonomous driving domain). Service communication within each logical network only occurs within the network corresponding to the VCID identifier. For example, the CAN XL frame of the body control service is set to VCID=0x10, and the frame of the autonomous driving service is set to VCID=0x20. The receiver (e.g., the second service node) filters data from non-target networks based on the VCID field. This mechanism achieves logical isolation of service communication, avoids conflicts between services from different functional domains on the physical network, and improves the reliability and security of service communication. In addition, the VCID field supports dynamic allocation (e.g., automatically adjusting VCID mapping based on load), further optimizing network resource utilization and reducing the risk of congestion in the vehicle network.

[0089] Specifically, the system can be divided into multiple logical networks according to the functional domains of the vehicle's electronic and electrical architecture. For example, the body control domain is assigned to the first logical network, the cockpit domain is assigned to the second logical network, and the autonomous driving domain is assigned to the third logical network.

[0090] Each logical network is assigned an independent VCID value. For example, the VCID value corresponding to the body control domain is 0x10, and the VCID value corresponding to the autonomous driving domain is VCID=0x20.

[0091] In this embodiment, the service nodes of the vehicle control domain, cockpit domain, autonomous driving domain, and chassis domain run in different virtual logical networks, and are logically isolated through VCID.

[0092] For example, taking the first service node as a sensor in the autonomous driving domain, since the autonomous driving domain corresponds to the third logical network, the target logical network of the second service node is the third logical network, while the first and second logical networks are non-target logical networks.

[0093] At this time, the virtual network identifier field VCID=0x20 is configured in the first CAN XL data frame. The second service node determines to retain the first CAN XL data frame by recognizing the virtual network identifier field VCID=0x20. If the virtual network identifier field VCID=0x20 is not configured in the first CAN XL data frame, the second service node will regard it as data from a non-target logical network and filter it out, thereby achieving data isolation between different domains.

[0094] In this embodiment, by configuring a virtual network identifier field in the first CAN XL data frame sent by the service node, service nodes of each domain can run in different virtual networks, thereby achieving logical isolation and solving the problem that traditional solutions can easily lead to SOA services being unable to achieve isolation on CAN XL and causing cross-domain interference.

[0095] Furthermore, traditional CAN XL networks do not provide a flexible addressing mechanism, resulting in service communication being unable to support multiple addressing modes (such as point-to-point communication, multicast communication, and broadcast communication), thus limiting the communication flexibility of SOA services. Therefore, in some embodiments, the service address can be configured in the first CAN XL data frame.

[0096] The second service node is used for service addressing based on the service address and service type identifier fields.

[0097] In this embodiment, the meaning of the service address, i.e., the AF field, is dynamically determined by the SDT field. For example, when the SDT field indicates an Ethernet service, the AF field carries the MAC address, supporting cross-network communication of Ethernet frames; when the SDT field indicates a local service, the AF field carries the logical service address (such as a service ID), supporting point-to-point communication.

[0098] In addition, the AF field also supports multicast addresses (e.g., when SDT=multicast service, the AF field is set to the multicast MAC address), enabling multiple nodes to receive service data simultaneously.

[0099] In this embodiment, configuring the service address in the first CAN XL data frame enhances the flexibility of service communication and supports the communication needs of SOA services in various scenarios (such as broadcast communication in cockpit entertainment systems and point-to-point communication in autonomous driving systems). Simultaneously, the dynamic interpretation mechanism of the AF field reduces protocol complexity, avoids redundancy in designing independent addressing fields for different service types, and further optimizes the scalability of the CAN XL protocol.

[0100] During SOA service communication, a service registration and discovery process needs to be executed. As mentioned above, service registration, discovery, and status monitoring can be achieved through the service management layer. The first service node can initiate a service registration request to the service registry.

[0101] Specifically, Figure 4 This is a schematic diagram of the service registration process provided in the embodiments of this application, such as... Figure 4 As shown, it includes the following steps:

[0102] Step 410: Encapsulate the registration request in the second CANXL data frame;

[0103] Step 420: Configure the service type identifier field in the second CANXL data frame to the service discovery type;

[0104] Step 430: Configure the service identifier, service instance identifier, service version number, service address, and virtual network identifier fields in the data field of the second CANXL data frame;

[0105] Step 440: Based on the configured second CANXL data frame, initiate a service registration request to the service registry center in the vehicle.

[0106] In this embodiment, when a service instance on a service node starts up, it can send a registration request to the service registry. The registration request is encapsulated in a second CANXL frame.

[0107] In addition, the SDT field in the second CANXL frame is set to the service discovery type so that subsequent nodes can call the service.

[0108] Furthermore, the data fields in the second CANXL frame include information such as service ID, instance ID, version number, service address (i.e., AF address), and the virtual network to which it belongs (i.e., VCID).

[0109] After receiving a registration request, the service registry stores the service information in the registry. When other nodes need to call the service later, they can first query the service registry to obtain the address and metadata of available service instances. Alternatively, other nodes can also obtain available service instance information through a service discovery request (SDT = Service Discovery Type).

[0110] Furthermore, a security authentication module can be integrated into the service registry to perform encrypted verification on nodes initiating service registration (e.g., the second CANXL data frame needs to carry authentication information) to prevent unauthorized nodes from registering. This can prevent unauthorized nodes from injecting fake services or attacking the network, thus threatening the security of SOA services.

[0111] In addition, the service registry can perform periodic health checks on services. For example, it can periodically send heartbeat requests (SDT = health check type) to service nodes. Service nodes are required to respond to these heartbeat requests. If a response times out, it is marked as abnormal, which can trigger service migration or load balancing.

[0112] In this embodiment, by configuring service discovery type, service identifier, service instance identifier, service version number, service address and virtual network identifier fields in the second CANXL data frame and initiating registration with the service registry, it is possible to facilitate service calls between various nodes. At the same time, the service registration mechanism can also prevent illegal nodes from injecting fake services or attacking the network, thereby improving the security of SOA services.

[0113] Vehicle networks need to be compatible with CAN / CAN FD nodes (such as door control and lighting control) and also need to collaborate with in-vehicle Ethernet (such as AP gateways and smart cockpits). However, traditional in-vehicle Ethernet and traditional CAN networks present high complexity issues in cross-network communication. To address this problem, in some embodiments, the compatibility features of CAN XL (coexistence with CAN / CAN FD) can be combined to achieve hybrid network communication.

[0114] Specifically, Figure 5 This is a schematic diagram of the cross-network communication process provided in the embodiments of this application, such as... Figure 5 As shown, it includes the following steps:

[0115] Step 510: In response to a service request initiated by a target node in the target vehicle network, configure the protocol type identifier field in the third CAN XL data frame and obtain the configured third CAN XL data frame;

[0116] Step 520: Send the configured third CAN XL data frame to the gateway interface layer through the CANXL network.

[0117] The gateway interface layer is used to convert the third CAN XL data frame into the protocol format corresponding to the target vehicle network according to the protocol type identifier field, and then send it to the target vehicle network.

[0118] The protocol format of the target vehicle network is different from that of the CAN XL network used by the first service node.

[0119] In this embodiment, the gateway interface layer is responsible for protocol conversion between the CANXL network and other target vehicular networks (such as vehicular Ethernet and CAN FD). When a target node in the target vehicular network initiates a service request, the first service node can configure the value of the SDT field in the third CAN XL data frame to identify the protocol type. When the gateway interface layer receives the third CAN XL data frame from the CANXL network, it determines the data type based on the SDT field and converts it to the protocol format corresponding to the target network.

[0120] For example, the first service node uses the protocol format of the CAN XL network to encapsulate SOME / IP messages into a third CAN XL data frame and identifies the protocol type through the SDT field. When the gateway interface layer receives the third CAN XL data frame, it converts the SOME / IP message into a SOME / IP message on the Ethernet.

[0121] Similarly, when the first service node initiates a service request, the gateway interface layer can also convert the SOME / IP messages on the Ethernet into SOME / IP messages encapsulated in the CANXL protocol format. This enables SOA services to communicate across different networks.

[0122] In addition, the gateway interface layer can pre-cache protocol mapping tables (such as SOME / IP → Ethernet frame format) to achieve seamless protocol conversion between CAN XL and Ethernet / CAN FD, reduce the cost of vehicle network upgrades, and support the evolution of hybrid network architecture.

[0123] In this embodiment, by utilizing the CAN XL's compatibility with CAN / CAN FD, seamless protocol conversion between CAN XL and Ethernet / CAN FD can be achieved, avoiding the high cost of a full vehicle upgrade to Ethernet, reducing the overall vehicle network upgrade cost, and also reducing the overall vehicle network upgrade cost.

[0124] Figure 6 This is a schematic diagram of the SOA service communication device provided in this application, as shown below. Figure 6 As shown, the SOA service communication device 60 provided in this embodiment includes:

[0125] The data frame configuration module 610 is used to respond to a service request initiated by the second service node in the vehicle, configure the service type identifier field and the first service data in the first CAN XL data frame, and obtain the configured first CAN XL data frame.

[0126] The data frame sending module 620 is used to send the configured first CAN XL data frame to the second service node through the CAN XL network.

[0127] The second service node is used to distribute the first service data to the corresponding protocol stack for processing based on the service type identifier field.

[0128] In one possible implementation, the data frame configuration module can be specifically used to: obtain a predefined mapping table; and determine the value of the service type identifier field configured in the first CAN XL data frame based on the service characteristics of the second service node and the mapping table.

[0129] In the mapping table, the value of each service type identifier field corresponds to a different service type or protocol type. The value of the service type identifier field in the first CAN XL data frame is used by the second service node to determine the corresponding protocol stack.

[0130] In one possible implementation, the data frame configuration module can be used to: determine an encapsulation strategy based on the data type and size of the first service data; and encapsulate the first service data into one or more first CAN XL data frames based on the encapsulation strategy.

[0131] In one possible implementation, a network identifier configuration module is also included, used to configure a virtual network identifier field and its value in the first CAN XL data frame. The virtual network identifier field identifies the logical network to which the first service node belongs, with each logical network corresponding to at least one functional domain in the vehicle. The second service node is used to filter data from non-target logical networks based on the value of the virtual network identifier field.

[0132] In one possible implementation, a service addressing configuration module is also included, used to configure the service address in the first CAN XL data frame. The second service node is used for service addressing based on the service address and service type identifier field.

[0133] In one possible implementation, a node registration module is also included, used for:

[0134] The registration request is encapsulated in the second CANXL data frame.

[0135] Configure the service type identifier field in the second CANXL data frame as a service discovery type;

[0136] Configure the service identifier, service instance identifier, service version number, service address, and virtual network identifier fields in the data field of the second CANXL data frame;

[0137] Based on the configured second CANXL data frame, a service registration request is initiated to the service registry center in the vehicle.

[0138] In one possible implementation, a protocol identifier configuration module is also included, which is used to: in response to a service request initiated by a target node in the target vehicle network, configure the protocol type identifier field in the third CAN XL data frame, obtain the configured third CAN XL data frame (the target vehicle network and the CAN XL network have different protocol formats), and send the configured third CAN XL data frame to the gateway interface layer through the CAN XL network.

[0139] The gateway interface layer is used to convert the third CAN XL data frame into the protocol format corresponding to the target vehicle network according to the protocol type identifier field, and then send it to the target vehicle network.

[0140] The SOA service communication device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0141] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus 704.

[0142] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to perform the above-described method.

[0143] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0144] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0145] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0146] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0147] This application also provides a vehicle, which includes a vehicle body and an SOA service communication device or SOA service communication system deployed in the vehicle body, the SOA service communication device or SOA service communication system being able to implement the above-described SOA service communication method.

[0148] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0149] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0150] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0151] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0152] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0153] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0155] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0156] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0157] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for communication in SOA services, characterized in that, The method, applied to the first service node in a vehicle, includes: In response to a service request initiated by a second service node in the vehicle, the service type identifier field and the first service data in the first CAN XL data frame are configured, and the configured first CAN XL data frame is obtained. The configured first CAN XL data frame is sent to the second service node through the CAN XL network. The second service node is used to distribute the first service data to the corresponding protocol stack for processing according to the service type identifier field.

2. The method according to claim 1, characterized in that, Configure the service type identifier field in the first CAN XL data frame, including: Obtain a predefined mapping table, in which the value of each service type identifier field corresponds to a different service type or protocol type; Based on the service characteristics of the second service node and the mapping table, the value of the service type identifier field configured in the first CAN XL data frame is determined. The value of the service type identifier field in the first CAN XL data frame is used by the second service node to determine the corresponding protocol stack.

3. The method according to claim 1, characterized in that, The configuration of the first service data in the first CAN XL data frame includes: Determine the encapsulation strategy based on the data type and size of the first service data; Based on the encapsulation strategy, the first service data is encapsulated into one or more first CAN XL data frames.

4. The method according to claim 1, characterized in that, After responding to the service request initiated by the second service node in the vehicle, the method further includes: In the first CAN XL data frame, a virtual network identifier field and a value of the virtual network identifier field are configured. The virtual network identifier field is used to identify the logical network to which the first service node belongs. Each logical network corresponds to at least one functional domain in the vehicle. The second service node is used to filter data from non-target logical networks based on the value of the virtual network identifier field.

5. The method according to claim 1, characterized in that, After responding to the service request initiated by the second service node in the vehicle, the method further includes: The service address is configured in the first CAN XL data frame, and the second service node is used to perform service addressing based on the service address and the service type identifier field.

6. The method according to claim 1, characterized in that, Before responding to a service request initiated by a second service node in the vehicle, the method further includes: The registration request is encapsulated in the second CANXL data frame. Configure the service type identifier field in the second CANXL data frame as a service discovery type; Configure the service identifier, service instance identifier, service version number, service address, and virtual network identifier fields in the data fields of the second CANXL data frame; Based on the configured second CANXL data frame, a service registration request is initiated to the service registry center in the vehicle.

7. The method according to claim 1, characterized in that, Also includes: In response to a service request initiated by a target node in the target vehicle network, the protocol type identifier field in the third CAN XL data frame is configured, and the configured third CAN XL data frame is obtained. The protocol format of the target vehicle network and the CAN XL network are different. The configured third CAN XL data frame is sent to the gateway interface layer through the CAN XL network. The gateway interface layer is used to convert the third CAN XL data frame into the protocol format corresponding to the target vehicle network according to the protocol type identifier field, and then send it to the target vehicle network.

8. An SOA service communication device, characterized in that, include: The data frame configuration module is used to respond to a service request initiated by the second service node in the vehicle, configure the service type identifier field and the first service data in the first CAN XL data frame, and obtain the configured first CAN XL data frame. The data frame sending module is used to send the configured first CAN XL data frame to the second service node through the CAN XL network. The second service node is used to distribute the first service data to the corresponding protocol stack for processing according to the service type identifier field.

9. An SOA service communication system, characterized in that, include: The service node layer is used to generate and / or receive CAN XL data frames; The CAN XL network layer is used to transmit the CAN XL data frames generated by the first service node in the service node layer to the second service node in the service node layer. The service management layer is used to register the first service node according to the service registration request initiated by the first service node, and to feed back the call information of the first service node to the second service node according to the service discovery request initiated by the second service node. The gateway interface layer is used to perform protocol conversion on the CAN XL data frames and send them to the target vehicle network, or to receive data frames from the target vehicle network and convert them into CAN XL data frames, wherein the protocol format of the target vehicle network is different from the protocol format of the CAN XL data frames.

10. A vehicle, characterized in that, include: The vehicle body and the SOA service communication system as described in claim 9 above.

Images