Vehicle-mounted SOA development system and method, electronic equipment and computer readable medium
By developing an in-vehicle SOA system, using Iceoryx and CycloneDDS to achieve zero-copy data transmission, the problem of resource waste in the in-vehicle system is solved, and data exchange efficiency and system stability are improved.
Patent Information
- Application Number
- CN202511187815.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-25
- Publication Date
- 2025-12-09
Smart Images
Figure CN121092136A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of intelligent driving technology, and in particular to an in-vehicle SOA development system, method, electronic device, computer-readable medium, and intelligent cockpit. Background Technology
[0002] With the rapid development of intelligent vehicles and autonomous driving technologies, intelligent cockpits have become an important component of modern automobiles. By integrating multiple functions such as navigation, entertainment, communication, and driver assistance, intelligent cockpits create a more comfortable and efficient travel environment for drivers and passengers. However, with the continuous advancement of vehicle intelligence, the data communication needs between various modules and electronic control units are increasing exponentially. An increasing number of sensors, cameras, and intelligent devices are constantly generating and transmitting data within the vehicle, involving multiple aspects such as environmental perception, vehicle status, and passenger information. This complex interaction leads to bottlenecks in data processing, especially in the processes of data transmission, copying, and serialization, which significantly consume system resources and waste CPU and memory resources. Traditional communication mechanisms often rely on message queues and network protocols, which requires data to undergo multiple serialization and deserialization processes during transmission. Each serialization requires additional computation and memory allocation, and this overhead can severely impact the system's real-time performance, especially in scenarios with high-frequency data updates. Summary of the Invention
[0003] This invention aims to solve at least one of the technical problems existing in the prior art, and proposes an in-vehicle SOA development system, method, electronic device, computer-readable medium and smart cockpit.
[0004] In a first aspect, embodiments of the present invention provide an in-vehicle SOA development system, which includes: a server, a client, an intermediate communication layer, and a code tool generation layer;
[0005] The server is used to publish events and push them to the client through the intermediate communication layer;
[0006] The client is used to invoke the server to make a request, and the server processes the request and returns a response to the client.
[0007] The code generation layer is used to generate corresponding code according to the needs of the server and / or the client.
[0008] In some embodiments, the server includes:
[0009] Server-side interfaces are used to provide interfaces that can be directly called by the business logic layer;
[0010] A server-side adapter is used to adapt the calls to the server-side interface to the service framework implementation layer.
[0011] The service framework implementation layer is used to implement specific service methods, events, and fields, and is responsible for interacting with the intermediate communication layer.
[0012] In some embodiments, the client includes:
[0013] The client interface is used to provide a client interface for the business logic layer.
[0014] A client-side proxy is a proxy object used to represent the client in communication with the server.
[0015] Service framework implementation layer: This layer provides the service framework implementation for the client and is responsible for handling responses and events from the server.
[0016] In some embodiments, the intermediate communication layer includes:
[0017] Iceoryx is used to provide a zero-copy, shared-memory-based communication mechanism;
[0018] CycloneDDS is used to achieve data distribution and synchronization between multiple electronic control units;
[0019] ARA::COM is used to wrap the C and C++ language API interfaces of iceoryx through the ARA::COM API.
[0020] In some embodiments, the server registers its services with the iceoryx runtime management process RouDi, depending on its own business type.
[0021] For applications with less stringent real-time requirements, the client discovers the service through FindService and then listens for messages from the server via a subscription model.
[0022] To address the need for real-time updates, message interaction with the server is conducted using a request pattern.
[0023] In some embodiments, the code generation layer uses automated scripts to parse business logic configuration files and automatically generate corresponding interfaces and business logic code, which are then provided to the server and the client.
[0024] In some embodiments, if the server and / or client have Java code, the corresponding JNI code is automatically generated using automation scripts and SWIG.
[0025] This invention also provides a development method for an in-vehicle SOA development system, comprising:
[0026] The server publishes events and pushes them to the client through an intermediate communication layer; or the client makes a request to the server, the server processes the request and returns a response to the client.
[0027] The code generation layer generates corresponding code based on the needs of the server and / or the client.
[0028] Thirdly, the present invention also provides an electronic device, comprising:
[0029] One or more processors;
[0030] Memory, used to store one or more programs;
[0031] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods.
[0032] Fourthly, the present invention also provides a computer-readable medium on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps in any of the methods described.
[0033] The in-vehicle SOA development system provided by this invention includes: a server, a client, an intermediate communication layer, and a code generation layer. The server publishes events and pushes them to the client through the intermediate communication layer. The client subscribes to events and receives event information from the server; or the client invokes a request from the server, the server processes the request and returns a response to the client. The code generation layer is used to generate corresponding code according to the needs of the server and / or the client. This architecture is compatible with multiple system platforms and achieves zero-copy data transmission, significantly reducing the use of system memory resources. Its low-latency real-time communication capability ensures rapid data exchange between various modules of the system, thereby improving the overall response speed and stability. Attached Figure Description
[0034] Figure 1 This is a schematic diagram of the structure of an embodiment of the vehicle-mounted SOA development system provided in this invention;
[0035] Figure 2 This is a schematic diagram of the structure of one embodiment of the server provided in this invention;
[0036] Figure 3 This is a flowchart illustrating the steps of one embodiment of the client provided in this invention.
[0037] Figure 4 This is a schematic diagram of bridge connection interaction implemented by CycloneDDS according to an embodiment of the present invention;
[0038] Figure 5 This is a schematic diagram of the structure of an embodiment of the electronic device of the present invention. Detailed Implementation
[0039] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.
[0040] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.
[0041] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.
[0042] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.
[0043] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.
[0044] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.
[0045] In related technologies, a protobuffer interface is defined in the application layer. The interface file is compiled into Java files and CPP files for use by the client and server to realize IPC communication between the client and server. This achieves cross-platform functionality of in-vehicle SOA based on fdbus without completely relying on the Android system. However, this solution will cause a huge consumption of system resources in business logic with large amounts of real-time data interaction. In addition, this solution does not implement the ARA::COM API interface based on the AUTOSAR architecture standard. When migrating to different system platforms, it may be necessary to reimplement the functionality of the business logic layer.
[0046] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides an in-vehicle SOA development system. Figure 1 This invention provides a schematic diagram of the structure of an in-vehicle SOA development system, including: a server 10, a client 20, an intermediate communication layer 30, and a code tool generation layer 40. The specific implementation methods of each module are described in detail below.
[0047] In this embodiment, there are two main communication modes between the server 10 and the client 20:
[0048] Publishing mode (for events): The server publishes events (e.g., sensor data updates), and the client subscribes to these events;
[0049] Alternatively, when an event occurs on the server, the data can be directly pushed to all subscribed clients (within the same ECU) via Iceoryx (shared memory) or forwarded to clients of other ECUs via CycloneDDS.
[0050] Request / response pattern (for method invocation): The client calls a method on the server (request), the server processes the request and returns a response. Similarly, request and response data are transferred via Iceoryx (shared memory), and via CycloneDDS when crossing ECUs.
[0051] Please see Figure 2Furthermore, server 10 includes the following functional modules:
[0052] 1. Server-side interface: The interface directly called by the business logic layer.
[0053] 2. Server-side adapter: Adapts the calls to the server-side interface to the service framework implementation layer.
[0054] 3. Service Framework Implementation Layer: Implements specific service methods, events, and fields, and is responsible for interacting with the intermediate communication layer.
[0055] 4. Methods / Events / Fields: The specific capabilities provided by the service.
[0056] 5. Server-side method publishing: The server publishes the methods for the client to call.
[0057] Please see Figure 3 Furthermore, client 20 includes the following functional modules:
[0058] 1. Client Interface: The client interface used by the business logic layer.
[0059] 2. Client Proxy: A proxy object that represents communication between the client and the server.
[0060] 3. Service Framework Implementation Layer: The client-side service framework implementation is responsible for handling responses and events from the server.
[0061] 4. Methods / Events / Fields: The methods that the client needs to call, the events it needs to subscribe to, and the fields it needs to access.
[0062] 5. Client-side method subscription: The client subscribes to methods or events published by the server.
[0063] In this embodiment, the intermediate communication layer 30 includes: Iceoryx, CycloneDDS, and ARA::COM. Wherein:
[0064] Iceoryx, as middleware, can provide a zero-copy, shared-memory-based communication mechanism.
[0065] It is understood that the in-vehicle SOA development system based on iceoryx in this embodiment solves the problems of high real-time performance and high reliability data exchange in in-vehicle systems by providing low-latency, high-throughput, and zero-copy data communication technologies. Its shared memory, automatic service discovery, and dynamic resource scheduling features give the in-vehicle SOA system greater flexibility, scalability, and fault tolerance, enabling it to cope with complex in-vehicle computing environments and high-concurrency data exchange needs. Supporting multiple communication modes, iceoryx can implement both publish / subscribe patterns, where publishers send messages to a topic and subscribers subscribe to that topic to receive messages—a mode suitable for one-to-many real-time data transmission; and request / response patterns, where clients send requests and servers return responses—suitable for synchronous service call scenarios.
[0066] In addition, iceoryx achieves dynamic scheduling through the use of service discovery mechanisms, which can establish connections between applications in real time. This feature is a perfect fit for automotive SOA architecture.
[0067] Furthermore, the RouDi process, the runtime management process of iceoryx, reads the configuration file upon startup. The configuration file contains the services and themes of the business, and configures the shared memory management terminal according to the services and themes of the business.
[0068] Furthermore, when registering services on the server side, RouDi injects the services into the registry for the client to findService. Once the client and server establish a connection, RouDi supports the server's publish / respond mode and the client's subscribe / request mode, enabling interaction between the server and the client.
[0069] It is understandable that, depending on its own business type, the server registers its services with the iceoryx runtime management process RouDi, which enables it to interact with the client through either the request mode or the publish mode. After the client discovers the service through FindService, it can listen to the server's messages through the subscription mode. However, the subscription mode has limited real-time performance, so for needs with strong real-time requirements, the request mode is used to interact with the server.
[0070] See Figure 4 CycloneDDS, as middleware, can be used to distribute and synchronize data between multiple electronic control units (ECUs) in a highly efficient and real-time manner, thereby improving the processing capabilities of the entire vehicle system. Depending on the load of different ECUs, CycloneDDS can flexibly adjust data processing tasks to ensure system balance and efficiency.
[0071] Specifically, when compiling iceoryx, CycloneDDS is selected to implement bridge connection interaction, enabling efficient data exchange between different electronic control units and the processing load of each electronic control unit.
[0072] ARA::COM is used to encapsulate the C and C++ language API interfaces of iceoryx through the ARA::COM API.
[0073] This embodiment uses the ARA::COM API to encapsulate the C and C++ language API interfaces of iceoryx. Users can choose between C or C++ based on actual hardware resources, system resources, and business types. It provides publish, subscribe, request, and response interfaces for the business logic layer.
[0074] It is understood that this embodiment, by encapsulating the ARA::COM API with iceoryx, ensures compatibility across different operating systems and hardware platforms, while supporting multiple communication modes, including point-to-point communication, broadcast communication, and multicast communication, ensuring that the system can function normally under various communication requirements.
[0075] In the system provided by this invention, the intermediate communication layer 30 is compatible with different system platforms. It uses the ARA::COM API in the AUTOSAR architecture standard to encapsulate the iceoryx interface and provides it for use by the upper-layer business logic. This separates the business logic from the iceoryx interface and enables seamless integration of the interface functions into other AUTOSAR platforms, improving the maintainability and scalability of the system. Depending on actual business needs, the iceoryx-based vehicle SOA architecture can be combined with CycloneDDS capabilities to realize the data communication functions of various electronic control units and achieve collaborative functional capabilities between various electronic and electrical units.
[0076] The code generation layer 40 provided in this embodiment of the invention is used to generate corresponding code according to the needs of the server and / or the client. Specifically, the code generation layer is used to parse the business logic configuration file using automated scripts, automatically generate corresponding interface and business logic code, and provide them to the server and the client for use.
[0077] Understandably, the code generation layer 40 uses configuration files based on business types, with the business provider's file acting as the server and the business requester's file as the client. Automated scripts parse these configuration files, defining the business logic, and automatically generate corresponding interfaces and business logic code based on the parsed content. This code can be used on both the server and client sides, reducing the workload of manual coding and improving code consistency and maintainability.
[0078] Furthermore, if the project involves Java code, the automation script can automatically generate the corresponding JNI code using SWIG. This allows Java applications to call underlying code written in C or C++, making full use of existing codebases and improving performance.
[0079] The in-vehicle SOA development system provided by this invention includes: a server, a client, an intermediate communication layer, and a code generation layer. The server publishes or subscribes to events and pushes them to the client through the intermediate communication layer, or the client invokes a request from the server. The server processes the request and returns a response to the client. The code generation layer generates corresponding code based on the needs of the server and / or the client. This architecture is compatible with multiple system platforms and achieves zero-copy data transmission, significantly reducing the use of system memory resources. Its low-latency real-time communication capability ensures rapid data exchange between system modules, thereby improving overall response speed and stability.
[0080] Based on the same inventive concept, embodiments of the present invention also provide a development method for in-vehicle SOA, applied to the aforementioned in-vehicle SOA development system. It includes the following steps:
[0081] The server publishes events and pushes them to the client through an intermediate communication layer. The client subscribes to the events and receives event information from the server; or the client makes a request to the server, the server processes the request and returns a response to the client.
[0082] The code generation layer generates corresponding code based on the needs of the server and / or the client.
[0083] The development method for in-vehicle SOA provided in this embodiment of the invention has the following workflow:
[0084] 1. Code generation (tool generation)
[0085] Developers write configuration files based on business requirements to define services (including methods, events, and fields) as well as service providers (servers) and demanders (clients).
[0086] Use automated scripts to parse configuration files and generate server-side and client-side interface code, business logic framework code (service framework implementation layer), and communication adaptation code.
[0087] If Java code is involved, JNI bridging code will also be generated via SWIG, enabling Java to call C / C++ code.
[0088] 2. Server startup and registration
[0089] When the server starts, it registers the service with RouDi (the Iceoryx daemon) by calling Iceoryx's API (encapsulated through ARA::COM) through the service framework implementation layer.
[0090] RouDi allocates shared memory resources based on configuration files and maintains the service registry.
[0091] 3. Client Discovery Service
[0092] After the client starts, it calls FindService through the client proxy to query RouDi and find available servers.
[0093] RouDi returns the server's location information (such as its address in shared memory).
[0094] 4. Communication Mode
[0095] There are two main communication modes between the server and the client:
[0096] Publish / subscribe pattern (for events):
[0097] The server publishes events (e.g., sensor data updates), and the client subscribes to these events.
[0098] When an event occurs on the server, the data is pushed directly to all subscribed clients (within the same ECU) via Iceoryx (shared memory) or forwarded to clients in other ECUs via CycloneDDS.
[0099] Request / response pattern (used for method calls):
[0100] The client calls a method (request) on the server, and the server processes the request and returns a response.
[0101] Similarly, request and response data are transferred via Iceoryx (shared memory) and via CycloneDDS when crossing ECUs.
[0102] 5. Communication Details
[0103] Communication within the same ECU: Directly uses Iceoryx's shared memory mechanism, zero copy, and extremely low latency.
[0104] Cross-ECU communication: Implemented via CycloneDDS. Iceoryx transmits data to CycloneDDS, which is responsible for publishing the data on the network. After receiving the data, the CycloneDDS of the target ECU transmits it to the client through the local Iceoryx.
[0105] 6. ARA::COM is used to encapsulate the C and C++ language API interfaces of iceoryx through the ARA::COM API. It supports multiple communication modes (point-to-point, broadcast, multicast) and multiple QoS policies. Depending on system resources, either C or C++ can be used.
[0106] In this embodiment of the invention, automatic code generation reduces repetitive work and improves code standardization and consistency; Iceoryx achieves zero-copy within the same ECU through shared memory, providing high throughput and low latency; CycloneDDS is used, supporting the DDS protocol and offering efficient data distribution and synchronization capabilities; RouDi is responsible for service registration and discovery, supporting dynamic connection establishment; it supports both publish / subscribe (event) and request / response (method call) modes to adapt to different real-time requirements. Simultaneously, zero-copy data transmission is achieved, significantly reducing system memory resource usage. Its low-latency real-time communication capabilities ensure rapid data exchange between system modules, thereby improving overall response speed and stability.
[0107] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the power state mode switching methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.
[0108] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).
[0109] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.
[0110] In some embodiments, the one or more processors 101 include a field-programmable gate array.
[0111] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the in-vehicle SOA development methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.
[0112] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described vehicle-mounted SOA development method.
[0113] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).
[0114] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0115] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.
[0116] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.
[0117] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.
[0118] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0119] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0120] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.
[0121] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0122] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.
Claims
1. A vehicle-mounted SOA development system, characterized in that, include: Server-side, client-side, intermediate communication layer, and code generation tool layer; The server is used to publish events and push them to the client through the intermediate communication layer; The client is used to invoke the server to make a request, and the server processes the request and returns a response to the client. The code generation layer is used to generate corresponding code according to the needs of the server and / or the client.
2. The vehicle-mounted SOA development system according to claim 1, characterized in that, The server includes: Server-side interfaces are used to provide interfaces that can be directly called by the business logic layer; A server-side adapter is used to adapt the calls to the server-side interface to the service framework implementation layer. The service framework implementation layer is used to implement specific service methods, events, and fields, and is responsible for interacting with the intermediate communication layer.
3. The in-vehicle SOA development system according to claim 1, characterized in that, The client includes: The client interface is used to provide a client interface for the business logic layer. A client-side proxy is a proxy object used to represent the client in communication with the server. Service framework implementation layer: This layer provides the service framework implementation for the client and is responsible for handling responses and events from the server.
4. The vehicle-mounted SOA development system according to claim 1, characterized in that, The intermediate communication layer includes: Iceoryx is used to provide a zero-copy, shared-memory-based communication mechanism; CycloneDDS is used to achieve data distribution and synchronization between multiple electronic control units; ARA::COM is used to wrap the C and C++ language API interfaces of iceoryx through the ARA::COM API.
5. The vehicle-mounted SOA development system according to claim 4, characterized in that, Based on its own business type, the server registers its services with the iceoryx runtime management process RouDi; For applications with less stringent real-time requirements, the client discovers the service through FindService and then listens for messages from the server via a subscription model. To address the need for real-time updates, message interaction with the server is conducted using a request pattern.
6. The vehicle-mounted SOA development system according to claim 1, characterized in that, The code generation layer uses automated scripts to parse business logic configuration files and automatically generate corresponding interfaces and business logic code, which are then provided to the server and the client.
7. The vehicle-mounted SOA development system according to claim 6, characterized in that, If the server and / or client have Java code, use automation scripts and SWIG to automatically generate the corresponding JNI code.
8. A method for implementing an in-vehicle SOA development system as described in any one of claims 1-7, characterized in that, include: The server publishes events and pushes them to the client via an intermediate communication layer. Alternatively, the client may make a request to the server, which will process the request and return a response to the client. The code generation layer generates corresponding code based on the needs of the server and / or the client.
9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in claim 8.
10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in claim 8.