Communication middleware construction method and system based on open architecture

Abstract

The invention provides a communication middleware construction method and system based on an open architecture. The method comprises the following steps: acquiring an open architecture model required for constructing lightweight communication middleware; modifying a data communication structure of the lightweight communication middleware into a data communication interface based on an open architecture model; according to the method, basic data processing and communication functions of lightweight communication middleware are deployed in an open architecture model, an upper-layer service interface of the lightweight communication middleware in the open architecture model is constructed, and specific calling of software components of the open architecture model is realized by utilizing the upper-layer service interface, the upper-layer service interface comprises an initialization service interface and a data release service interface of the lightweight communication middleware. According to the invention, the lightweight DDS is deployed in the AUTOSAR CP, and compared with the traditional IP-based service-centered communication middleware in the AUTOSAR CP, the DDS middleware enhances the guarantee of service quality.

Description

Technical Field

[0001] The present invention relates to the technical field of communication middleware, and particularly relates to a method and system for constructing a communication middleware based on an open architecture. Background Art

[0002] The Data Distribution Service middleware (DDS) is a platform that is set in the domain controller and MCU of a vehicle and is responsible for transmitting data on the domain controller and MCU. Currently, some enterprises or organizations usually package the DDS middleware into software and deploy it on the operating system of the vehicle domain controller, or directly run the DDS middleware on the resource-constrained vehicle MCU in bare metal. However, when the DDS middleware runs in bare metal on a microcontroller (MCU), the efficiency is low, the real-time performance is poor, the performance of the MCU cannot be fully utilized, resulting in waste of vehicle resources, and the lack of an operating system in bare metal operation leads to poor robustness of the communication system. The Automotive Open System Architecture Classic Platform (AUTOSAR) is a standard software architecture commonly used by vehicle MCUs. However, currently, AUTOSAR CP lacks adaptation to the DDS middleware, especially the adaptation support for the lightweight DDS middleware. Summary of the Invention

[0003] Based on this, the purpose of the present invention is to provide a method and system for constructing a communication middleware based on an open architecture to at least solve the above-mentioned deficiencies in the technology.

[0004] The present invention proposes a method for constructing a communication middleware based on an open architecture, including: Obtaining an open architecture model required for constructing a lightweight communication middleware; Modifying the data communication structure of the lightweight communication middleware into a data communication interface based on the open architecture model, wherein the communication transport layer protocol adopted by the data communication interface includes the User Datagram Protocol and the Transmission Control Protocol; Deploying the basic data processing and communication functions of the lightweight communication middleware in the open architecture model, and constructing an upper-layer service interface of the lightweight communication middleware in the open architecture model, and implementing specific calls of software components of the open architecture model by using the upper-layer service interface, wherein the upper-layer service interface includes an initialization service interface and a data publishing service interface of the lightweight communication middleware.

[0005] Further, the step of obtaining an open architecture model required for constructing a lightweight communication middleware includes: Obtaining a corresponding TCP / IP protocol stack based on the open architecture, and configuring the unicast address of the TCP / IP protocol stack and its communication interface with the upper-layer socket adapter SoAd module; Configure the communication interface between the socket adapter SoAd module and the complex driver module Cdd to obtain the corresponding open architecture model.

[0006] Further, the steps of modifying the data communication structure of the lightweight communication middleware to the data communication interface based on the open architecture model include: Determine the transport protocol identifier according to the platform type, and perform data type conversion on the sending data address and length to convert them into the PDU information type required by the SoAd general sending interface; Call the SoAd general sending interface to pass the PDU information type to the lower-layer TCP / IP protocol stack to implement the sending of the interface data of the lightweight communication middleware.

[0007] Further, the steps of modifying the data communication structure of the lightweight communication middleware to the data communication interface based on the open architecture model include: Parse the received PDU data and temporarily store its data start pointer and data length information; Judge whether the initialization of the lightweight communication middleware is completed. If the initialization of the lightweight communication middleware is completed, pass the PDU data to the upper-layer application, and the upper-layer application calls the corresponding interface of the lightweight communication middleware to perform message deserialization and service data extraction; If the initialization of the lightweight communication middleware is not completed, directly perform message reading processing in the SoAd transfer interface.

[0008] Further, the steps of constructing the upper-layer service interface of the lightweight communication middleware in the open architecture model include: Construct the data to be sent by the lightweight communication middleware in the topic format, and perform serialization processing on the data to be sent through the serialization interface to obtain serialized data; Put the serialized data into the output stream, and call the push stream interface of the protocol stack of the communication middleware to publish the content of the output stream.

[0009] The present invention also proposes a communication middleware construction system based on an open architecture, including: A model construction module for obtaining an open architecture model required for constructing a lightweight communication middleware; An interface modification module for modifying the data communication structure of the lightweight communication middleware to a data communication interface based on the open architecture model, where the communication transport layer protocol adopted by the data communication interface includes the User Datagram Protocol and the Transmission Control Protocol; A data processing module, which is used to deploy the basic data processing and communication functions of the lightweight communication middleware in the open architecture model, construct the upper-layer service interface of the lightweight communication middleware in the open architecture model, and use the upper-layer service interface to implement the specific call of the software components in the open architecture model. Among them, the upper-layer service interface includes the initialization service interface and the data publishing service interface of the lightweight communication middleware.

[0010] Further, the model construction module includes: A first interface configuration unit, which is used to obtain the corresponding TCP / IP protocol stack based on the open architecture, and configure the unicast address of the TCP / IP protocol stack and its communication interface with the upper-layer socket adapter SoAd module; A second interface configuration unit, which is used to configure the communication interface between the socket adapter SoAd module and the complex driver module Cdd to obtain the corresponding open architecture model.

[0011] Further, the interface modification module includes: A type conversion unit, which is used to determine the transmission protocol identifier according to the platform type, and perform data type conversion on the sending data address and length to convert them into the PDU information type required by the SoAd general sending interface; An interface call unit, which is used to call the SoAd general sending interface to pass the PDU information type to the lower-layer TCP / IP protocol stack to implement the sending of the interface data of the lightweight communication middleware.

[0012] Further, the interface modification module is specifically used for: Parse the received PDU data and temporarily store its data start pointer and data length information; Judge whether the initialization of the lightweight communication middleware is completed. If the initialization of the lightweight communication middleware is completed, pass the PDU data to the upper-layer application, and the upper-layer application calls the corresponding interface of the lightweight communication middleware to perform message deserialization and service data extraction; If the initialization of the lightweight communication middleware is not completed, directly perform message reading processing in the SoAd transfer interface.

[0013] Further, the data processing module is specifically used for: Construct the data to be sent by the lightweight communication middleware according to the topic format, and perform serialization processing on the data to be sent through the serialization interface to obtain serialized data; Put the serialized data into the output stream, and call the push stream interface of the protocol stack of the communication middleware to publish the content of the output stream.

[0014] The present invention also provides a readable storage medium, on which a computer program is stored. When the program is executed by a processor, the above-mentioned method for constructing a communication middleware based on an open architecture is implemented.

[0015] The present invention also provides a computer, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the above-mentioned method for constructing a communication middleware based on an open architecture is implemented.

[0016] In the method and system for constructing a communication middleware based on an open architecture in the present invention, lightweight DDS is deployed in AUTOSAR CP. Compared with the traditional IP-based service-centered communication middleware in AUTOSAR CP, the DDS middleware enhances the guarantee of service quality; on the other hand, the communication mechanism for real-time processing of messages by the lightweight DDS middleware proposed in this application in AUTOSAR CP can effectively combine DDS and AUTOSAR CP, reduce the blocking time of the MCU for executing tasks, and reduce the resource occupation of DDS at the MCU end; finally, the lightweight DDS deployed under AUTOSAR CP implemented in this application is almost imperceptible to the upper-layer SWC, and the lightweight DDS module can be called on the premise of slightly modifying the code of the application service layer. Description of the Drawings

[0017] Figure 1 It is a flowchart of the method for constructing a communication middleware based on an open architecture in the first embodiment of the present invention; Figure 2 It is an example diagram of the AUTOSAR CP architecture in the first embodiment of the present invention; Figure 3 It is an example diagram of the standard DDS subscription and publication model in the first embodiment of the present invention; Figure 4 It is an example diagram of the DDS subscription and publication model for resource-constrained environments in the first embodiment of the present invention; Figure 5 It is an example diagram of the construction method for integrating lightweight DDS into the basic software layer of AUTOSAR CP in the first embodiment of the present invention; Figure 6 It is an example diagram of the overall subscription and publication model of the lightweight DDS system in the first embodiment of the present invention; Figure 7 It is an example diagram of the construction method for the complex driver module of integrating lightweight DDS into the basic software layer of AUTOSAR CP in the first embodiment of the present invention; Figure 8 It is an example diagram of the best-effort service quality communication mechanism of the lightweight DDS in the first embodiment of the present invention; Figure 9 It is an example diagram of the reliable transmission service quality communication mechanism of the lightweight DDS in the first embodiment of the present invention; Figure 10 It is an example diagram of the communication mechanism for AUTOSAR real-time processing messages of the lightweight DDS in the first embodiment of the present invention; Figure 11 It is an example diagram of the asynchronous startup function communication mechanism of the lightweight DDS in the first embodiment of the present invention; Figure 12 It is an example diagram of the restart and reconnection function communication mechanism of the lightweight DDS in the first embodiment of the present invention; Figure 13 It is a structural block diagram of a communication middleware construction system based on an open architecture in the second embodiment of the present invention; Figure 14 It is a structural block diagram of a computer in the third embodiment of the present invention.

[0018] The following specific embodiments will further illustrate the present invention in conjunction with the above-mentioned drawings. Specific Embodiments

[0019] To facilitate the understanding of the present invention, the present invention will be described more comprehensively below with reference to the relevant drawings. Several embodiments of the present invention are given in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, these embodiments are provided to make the disclosure of the present invention more thorough and comprehensive.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention belongs. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention. The term "and / or" used herein includes any and all combinations of one or more of the related listed items.

[0021] This application relates to the relevant knowledge of AUTOSAR CP and DDS. To better understand the solutions of the embodiments of this application, the following will first introduce the relevant terms and concepts that may be involved in the embodiments of this application. It should be understood that the relevant concept explanations may be limited by the specific circumstances of the embodiments of this application, but it does not mean that this application can only be limited to this specific situation. There may also be differences in the specific circumstances of different embodiments, and no specific limitations are made here.

[0022] AUTOSAR, the automotive open system architecture, is jointly founded by leading companies in the automotive and software industries, aiming to develop and establish a standardized software framework and an open E / E system architecture for intelligent transportation.

[0023] AUTOSAR CP, the AUTOSAR Classic Platform, is a software platform with a layered software architecture defined by AUTOSAR for deeply embedded systems and application software with high requirements for predictability, safety, security, and responsiveness. It differentiates three software layers running on the microcontroller at the highest level of abstraction: the application, the Runtime Environment (RTE), and the Basic Software (BSW), and provides a modular and extensible approach to software development.

[0024] SWC, Software Component, is the basic building block of AUTOSAR application software. Several SWCs form the application layer and implement the specific functions of the upper-layer applications.

[0025] RTE, Runtime Environment, is the virtual function bus of the AUTOSAR CP platform, which separates the application from the infrastructure and communicates through dedicated ports. The communication interfaces of application software are usually mapped to the ports of the RTE and then communicate with different application software or basic software layers.

[0026] BSW, Basic Software Layer, can be divided into the service layer, the Electronic Control Unit (ECU) abstraction layer, the microcontroller abstraction layer, and complex driver modules, which provide basic functions such as the operating system and communication services for the upper layer.

[0027] CDD, Complex Driver Module, is used to carry function modules outside the AUTOSAR CP platform standard, and its function interfaces are generally directly called by the upper-layer SWCs.

[0028] DDS, Data Distribution Service, is a data-centric distributed communication middleware.

[0029] XRCE DDS, DDS for resource-constrained platforms, is different from the standard DDS and has its own unique specifications. XRCE DDS is divided into a client and an agent. The client is deployed on resource-constrained devices, and the agent is deployed on more powerful network nodes; the client only needs to maintain the information of basic communication entities, and creates specific DDS communication entities on the agent through XRCEDDS messages, so as to communicate and interact with the DDS data space.

[0030] HEARTBEAT, Heartbeat, is a type of XRCE DDS message, usually sent from the client to the agent to ensure that all messages in the reliable stream are received.

[0031] ACKNACK, Acknowledgment / Negation, is a type of XRCE DDS message, indicating whether the sequence number of the currently received message is the same as the previous one, used to ensure that all messages in the reliable stream are received.

[0032] QoS, Quality of Service, refers to the service capabilities of DDS and XRCE DDS to handle network latency and congestion in this application.

[0033] BE, Best Effort, is a quality of service that DDS and XRCE DDS can provide. Under this quality of service, DDS and XRCE DDS only send and receive messages, without considering packet loss, out-of-order, etc. caused by network congestion, etc. It is the most basic quality of service.

[0034] RELIABLE, Reliable Transmission, is a quality of service that DDS and XRCE DDS can provide. Under this quality of service, DDS and XRCE DDS will number the message sequence and add it to the message header. The message sender and receiver ensure that the messages are in-order and without packet loss through HEARTBEAT messages and ACKNACK messages.

[0035] With the continuous development of automotive intelligent networking, more and more advanced driver assistance systems are deployed in vehicles. The increasing number of sensors, actuators, and electronic control units generate a large amount of real-time traffic, which promotes the birth of in-vehicle Ethernet. At the same time, the traditional distributed electronic and electrical architecture can no longer meet the needs of automotive electronics due to the disadvantages of decentralized ECUs, long development cycles, and poor scalability. The automotive open system architecture AUTOSAR provides a system architecture with software and hardware decoupling and proposes a domain centralized automotive electronic and electrical architecture, which has currently become the main development trend of automotive electronic and electrical architectures. In the AUTOSAR architecture specification, an IP-based scalable service-oriented communication middleware and a data distribution service middleware have been defined successively. Among them, the IP-based scalable service-oriented communication middleware was defined earlier and has been widely used currently. The data distribution service middleware was added to the protocol later, and there are currently few specific implementation solutions. However, compared with the IP-based scalable service-oriented communication middleware, it has the advantage of quality of service and has a large number of successful cases in many fields such as aerospace, smart grid, and intelligent healthcare. Therefore, it is regarded as the next-generation service-oriented communication middleware in the automotive field and has good development potential.

[0036] Embodiment 1 Please refer to Figure 1 , which shows a method for constructing a communication middleware based on an open architecture in the first embodiment of the present invention. The method specifically includes steps S101 to S103: S101, obtain an open architecture model required for constructing a lightweight communication middleware; Further, the step S101 specifically includes steps S1011~S1012: S1011, obtain the corresponding TCP / IP protocol stack based on the open architecture, and configure the unicast address of the TCP / IP protocol stack and its communication interface with the upper-layer socket adapter SoAd module; S1012, configure the communication interface between the socket adapter SoAd module and the complex driver module Cdd to obtain the corresponding open architecture model.

[0037] In specific implementation, please refer to Figure 2 , which shows the AUTOSAR CP platform architecture (i.e., the open architecture model) in this embodiment. The AUTOSAR CP architecture can be divided into three layers: the application layer, the runtime environment, and the basic software layer. A number of SWCs are deployed in the application layer, and the SWC is the specific implementation of the application software function. The environment in which the SWC runs is provided by the RTE. The internal communication between SWCs and the communication between SWCs and the BSW require the RTE to perform signal connection and scheduling. The BSW is the basic software layer of AUTOSAR, which can be specifically divided into four parts: the service layer, the ECU abstraction layer, the microcontroller abstraction layer, and the complex driver module. The BSW provides basic services that can be used by the upper-layer SWCs, such as memory management, task scheduling, and basic communication. For other services not mentioned in the AUTOSAR standard, they can be directly called by the upper-layer application by deploying them in the complex driver module and providing service interfaces. The complex driver module can also call the services provided by other modules of the BSW, such as the basic Ethernet transceiver function and the memory management function.

[0038] Please refer to Figure 3 , which shows an example diagram of the standard DDS (lightweight communication middleware) publish-subscribe model in the embodiment of this application. The DDS data space is divided into each domain. The domain participants within the domain can freely perform data interaction. The domain participant is the abstraction of the application program in the DDS publish-subscribe model, and it contains a number of publishers and subscribers. There are also a number of data writers and data readers above the publisher and the subscriber. The data writer and the data reader can discover each other through the DDS discovery message, and determine whether to establish a communication connection according to the topic. The topic contains information such as quality of service, data type, and name. The data writer and the data reader match according to the topic. After the connection is established, the application program above the data writer and the data reader can perform data transmission through DDS.

[0039] Please refer to Figure 4, as shown is an example diagram of the DDS subscription and publication model for resource-constrained environments in an embodiment of the present application. Since the standard DDS protocol consumes relatively high memory and CPU resources and is difficult to deploy in resource-constrained devices, the Object Management Group has developed the XRCE DDS standard. XRCE DDS is a protocol based on the standard DDS specifically designed for resource-constrained devices, which is divided into a client and an agent. The client participates in the data interaction in the DDS data space through the agent. The client first establishes a session with the agent, and then transmits information such as the domain participant, publisher, subscriber, topic, data writer, data reader to be established and the QoS of these communication entities to the agent through the XRCE DDS protocol. The agent establishes the standard DDS communication entities required by the client. Subsequently, the client realizes the DDS communication function with other DDS nodes through the agent according to the data writer and data reader. The client only needs to maintain the session, data reader, data writer, and topic information and does not need to care about other communication entities in the standard DDS protocol, so the resource occupancy is very small. After receiving the message for creating an entity from the client, the agent node creates the standard DDS communication entities, and converts the standard DDS message and the XRCE DDS message to each other during the communication between the client and other standard DDS communication nodes, and transmits them to the required client or other standard DDS nodes. In addition to acting as an agent for the client to help it participate in DDS communication, the agent node itself can also create communication entities for the application program according to the standard DDS protocol for DDS communication.

[0040] S102. Modify the data communication structure of the lightweight communication middleware into a data communication interface based on the open architecture model, wherein the communication transport layer protocol adopted by the data communication interface includes the User Datagram Protocol and the Transmission Control Protocol; Further, the step S102 specifically includes steps S1021 to S1022: S1021. Determine the transport protocol identifier according to the platform type, and perform data type conversion on the sending data address and length to convert them into the PDU information type required by the SoAd general sending interface; S1022. Call the SoAd general sending interface to transfer the PDU information type to the underlying TCP / IP protocol stack to realize the sending of the interface data of the lightweight communication middleware.

[0041] Further, the step S102 further includes steps S1121 to S1123: S1121, Parse the received PDU data and temporarily store the data start pointer and data length information; S1122, Determine whether the initialization of the lightweight communication middleware is completed. If the initialization of the lightweight communication middleware is completed, transfer the PDU data to the upper-layer application, and the upper-layer application calls the interface corresponding to the lightweight communication middleware to perform deserialization of the message and extraction of service data; S1123, If the initialization of the lightweight communication middleware is not completed, directly perform message reading processing in the SoAd transfer interface.

[0042] Currently, the AUTOSAR CP specification has classified both DDS and SOME / IP as supported service-oriented communication middleware. For the specific construction method proposed by the AUTOSAR CP specification, please refer to Figure 5 , Figure 5 This is an example diagram of a construction method for integrating lightweight DDS into the basic software layer of AUTOSAR CP provided by the embodiments of this application. The AUTOSAR CP specification integrates the domain participant, publisher, subscriber, data writer, data reader of DDS, as well as the serialization and deserialization functions of messages, into the DDS module of the BSW. Under this construction method, the configuration of DDS mainly focuses on the process of generating AUTOSAR static configuration code. Users need to customize the configuration of DDS functions, mainly configure PDU routing, message priority, message data type, etc. During the DDS message sending process, the data of the upper-layer SWC first passes through the RTE, LdCom, and PduR modules and is transferred to the DDS module. No operation is performed on the PDU during this process. Then the PDU is serialized in the DDS module and encapsulated into a DDS message, which is transferred to the SoAd module and sent through the lower-layer Ethernet communication protocol stack. The DDS message receiving process is the opposite of the sending process and will not be elaborated here. Although this construction method has high code reusability and the upper-layer application is unaware of the underlying software, it does not support real-time sending and receiving. From the sending process, it can be seen that no processing is performed on the data during the process of the SWC data passing through the RTE and some BSW modules, which is very redundant; and the data also faces the problem of possible spin locks in the RTE, which is also the reason why the DDS function proposed by the current AUTOSAR CP specification does not support multi-core distribution. Even so, currently major AUTOSAR manufacturers have not launched AUTOSAR code packages according to this specification, and the actual application of DDS on the AUTOSAR CP platform is still in the exploration stage.

[0043] In specific implementation, the embodiment of the present application adopts a construction method of integrating lightweight DDS into the complex driver module in the basic software layer of AUTOSAR CP. First, the overall publish-subscribe model of the lightweight DDS system in the embodiment of the present application is introduced below. For details, please refer to Figure 6 , Figure 6 which is an example diagram of the overall publish-subscribe model of the lightweight DDS system in the embodiment of the present application. In the embodiment of the present application, on the microcontroller side, a construction method of integrating lightweight DDS into the complex driver module in the basic software layer of AUTOSAR CP is adopted, and the XRCE DDS client is deployed on the AUTOSAR CP platform. On the domain controller side, the XRCE DDS proxy side is deployed in the operating system by directly encapsulating it into software. The operating system on the domain controller side is not limited here and can be a Linux operating system, a FreeRTOS operating system, a QNX operating system, etc. Before the SWC on the microcontroller publishes a DDS message, it first needs to establish a session with the domain controller and send a CREATE_CLIENT message through the XRCE DDS client to inform the XRCE DDS proxy side of the existence of the Client. After receiving the message, the XRCE DDS proxy side saves information such as the IP address and port number of the client and then sends an AGENT_STATUS message to reply to the XRCE DDS client about the session creation status. Subsequently, the XRCE DDS client will create an XRCE DDS data stream locally, allocate memory space for it, and create an XRCE DDS communication entity. After writing the information of the XRCE DDS communication entity into a CREATE message through XML or other means, it is sent to the XRCE DDS proxy side. Then, the proxy side creates an XRCE DDS communication entity and a standard DDS communication entity according to the XML information and informs the XRCE DDS client of the status of the communication entity creation through a STATUS message. After the XRCE DDS initialization is completed, the XRCE DDS client can realize message sending and receiving with other standard DDS nodes through the XRCE DDS proxy side, and can also communicate with other XRCE DDS clients through the XRCE DDS proxy side. The XRCE DDS proxy side can also establish a DDS communication entity for the application programs on it. The DDS protocol does not stipulate a one-to-one mapping between physical nodes and DDS communication nodes. Therefore, the domain controller side can deploy its own DDS communication entity and the XRCE DDS proxy side at the same time.

[0044] Furthermore, for the construction method of integrating the lightweight DDS in the embodiment of the present application into the complex driver module in the basic software layer of AUTOSAR CP, for details, please refer to Figure 7 , Figure 7This is an example diagram of the construction method of a complex driver module that integrates lightweight DDS into the basic software layer of AUTOSAR CP. In the embodiments of this application, the lightweight XRCE DDS function is adapted in the complex driver module of the AUTOSAR CP platform, and specific functions such as the initialization of XRCE DDS, serialization and deserialization of XRCE DDS, message parsing and encapsulation of XRCE DDS, and triggering of callback functions by the receive function are implemented in the complex driver module. When performing the static configuration of the AUTOSAR CP platform in the embodiments of this application, in addition to configuring the OS, RTE, and the lower-layer Ethernet communication protocol stack, the PDU and Socket information of the CDD module are also configured and added, that is, the first interface at the AUTOSAR CP end is configured to reserve a communication interface for subsequent adaptation with XRCE DDS. In addition, when configuring the upper-layer SWC of AUTOSAR CP using relevant software, in the embodiments of this application, a runnable with a period of 100 ms is added on core 2, and the second interface at the AUTOSAR CP end is reserved for calling the second service interface of XRCE DDS to implement the basic communication function of XRCE DDS. After the static configuration of the software tool at the AUTOSAR CP end is completed in the embodiments of this application, software component configuration code and AUTOSAR CP protocol stack code are generated for subsequent adaptation of lightweight DDS. Subsequently, the XRCE DDS client code is added to the complex driver module in the embodiments of this application and mutually adapted with the AUTOSAR CP static configuration code. The adaptation mainly includes the adaptation of the first interface for communication between the SoAd module of AUTOSAR CP and the CDD module and the first communication interface of XRCE DDS, and the adaptation of the second interface of the upper-layer SWC of AUTOSAR CP and the second interface for the specific function implementation of XRCE DDS in the CDD module. The adaptation of the first interface and the second interface will be introduced separately below.

[0045] The adaptation of the first interface is mainly the adaptation of the communication interface. In the embodiments of the present application, the sending and receiving functions of XRCE DDS are adapted to the sending and receiving functions of AUTOSAR CP. During the sending process, the application layer SWC in the embodiments of the present application calls the sending interface in the second interface of XRCE DDS for sending. Through the second interface, it calls the XRCE DDS sending interface of the CDD module, that is, the XRCE DDS first sending interface. The XRCE DDS first sending interface calls the AUTOSAR CP first sending interface reserved for the CDD module during the static configuration of AUTOSAR CP, thereby realizing the adaptation of XRCE DDS to the AUTOSAR CP first sending interface. During the receiving process, AUTOSAR CP in the embodiments of the present application adopts the interrupt receiving method, that is, interrupting the tasks of the current core, and first receiving and storing the message to prevent the memory queue of the Ethernet protocol stack from being occupied for a long time. After the interruption occurs, the underlying Ethernet communication protocol stack obtains the Socket information based on information such as the port number and IP address, and triggers the receiving interrupt function of CDD in the SoAd module, that is, the AUTOSAR CP first receiving interface. During the initialization process, the AUTOSAR CP first receiving interface calls the message parsing interface of XRCE DDS in the CDD module to parse the message, and the latter is the XRCE DDS first receiving interface, and finally completes the message parsing and modifies the status and other info fields of the session. After the initialization is completed, the receiving process in the embodiments of the present application needs to be completed through the second interface.

[0046] The adaptation of the second interface is mainly the adaptation of the service interface. In the embodiment of the present application, a DDS communication function service interface implemented by XRCE DDS is constructed, that is, the XRCE DDS second interface is adapted to the SWC service interface of the AUTOSAR CP service layer. In the embodiment of the present application, an XRCE DDS initialization interface, a sending interface, and a receiving interface are constructed, and corresponding runnables are added during the AUTOSAR CP static configuration to call the service interface. The process of the upper-layer SWC of XRCE DDS in the embodiment of the present application calling the service interface is as follows: First, the upper-layer SWC waits for the AUTOSAR CP operating system and the underlying protocol stack to start, and then calls the XRCE DDS initialization interface until the initialization is successful; Subsequently, the upper-layer SWC calls the XRCE DDS sending service interface in the user-defined manner, calls the XRCE DDS deployed in the complex driver module to serialize the message, and finally sends the message by calling the XRCE DDS sending first interface. The whole-process message receiving process in the embodiment of the present application is relatively complex and is divided into two cases: before and after the completion of XRCE DDS initialization. The receiving interface in the AUTOSAR CP first interface in the embodiment of the present application directly calls the XRCE DDS message receiving second interface before the completion of XRCE DDS initialization to reduce the blocking of the core by XRCE DDS initialization; after the completion of XRCE DDS initialization, the receiving interface in the AUTOSAR CP first interface passes information such as the memory address and length of the message to the runnable responsible for receiving and processing the message through the RTE. The runnable calls the XRCE DDS message receiving second interface to complete message parsing, and after extracting the data, it passes the data to other SWCs through the RTE, or calls a callback function to directly process the data to implement functions such as loopback sending.

[0047] S103. Deploy the basic data processing and communication functions of the lightweight communication middleware in the open architecture model, and construct the upper-layer service interface of the lightweight communication middleware in the open architecture model, and use the upper-layer service interface to implement the specific call of the software components in the open architecture model, where the upper-layer service interface includes the initialization service interface and the data publishing service interface of the lightweight communication middleware.

[0048] Further, the step S103 specifically includes steps S1031 to S1032: S1031. Construct the data to be sent by the lightweight communication middleware according to the topic format, and perform serialization processing on the data to be sent through the serialization interface to obtain serialized data; S1032. Put the serialized data into the output stream, and call the push stream interface of the protocol stack of the communication middleware to publish the content of the output stream.

[0049] In specific implementation, in the development and design process of the embodiments of the present application, the service scenario is first determined. The service scenario of the embodiments of the present application is a simple data loopback scenario, that is: deploy a dtatwriter and a dtatreader in the XRCE DDS client of the microcontroller, associate two topics with the same data type but different names, namely loopback1 and loopback2, deploy the XRCE DDS proxy and a standard DDS node on the domain controller, there is a datawriter and a datareader on the standard DDS node, and the associated topics are loopback2 and loopback1 respectively, so as to realize the data loopback between the standard DDS and the XRCE DDS client through the XRCE DDS proxy. Subsequently, the embodiments of the present application configure the AUTOSAR CP architecture, configure the socket ID of the PDU for the CDD module, set the IP address of the microcontroller in the network and allocate the port number used for DDS communication, and realize the mapping between the port number and the socket ID. In addition, in the AUTOSAR CP static configuration stage, the embodiments of the present application also configure the upper-layer SWC and perform service calls on the second interface. Then, the embodiments of the present application perform lightweight DDS communication interface adaptation to realize the adaptation between the first interface and the second interface. Finally, the embodiments of the present application call the second interface in the runnable of the upper-layer SWC of AUTOSAR CP to realize the call of the basic XRCE DDS communication service, and call the first interface through the second interface to realize the XRCE DDS message sending and receiving function by using the AUTOSAR CP basic Ethernet protocol stack.

[0050] Furthermore, the present application proposes a communication mechanism for the lightweight DDS middleware to process messages in real time in AUTOSAR CP, which mainly includes two service qualities and two communication functions. The two service qualities are the best-effort service quality and the reliable transmission service quality respectively, and the two communication functions are the asynchronous start function and the restart and reconnection function respectively. To further illustrate the implementation methods of the two service qualities, after introducing the two service qualities provided by the present application, the specific implementation methods of the two service qualities will be described in combination with the embodiments of the present application.

[0051] The best-effort service quality mode, usually abbreviated as the BE mode, for details please refer to Figure 8 , Figure 8This is an example diagram of the best-effort quality of service communication mechanism for the lightweight DDS provided by the embodiments of this application. The BE mode does not guarantee any quality of service. The sender does not guarantee the receipt of the message after sending. The real-time performance of the communication is high, but the reliability is lacking. In the BE mode of the embodiments of this application, the XRCE DDS client and the agent do not make any confirmation after sending the message. During the XRCE DDS initialization process in the BE mode of the embodiments of this application, the XRCE DDS client first sends a CREATE_CLIENT message to the XRCE DDS agent, indicating information such as the IP address and port number of the XRCE DDS client. After receiving the CREATE_CLIENT message, the XRCE DDS agent stores the XRCE DDS client information locally and replies with a STATUS_AGENT message indicating that the session is established. Subsequently, the XRCE DDS client creates XRCE DDS communication entities according to local requirements. A total of 7 XRCE DDS communication entities are created in the embodiments of this application, namely participant, publisher, datawriter, loopback1, subscriber, datareader, and loopback2. And a BE input / output stream for caching messages is created. A CREATE message is created in the BE output stream. The CREATE message contains all the information of these communication entities. Subsequently, the XRCE DDS client sends the CREATE message. After receiving the CREATE message, the XRCE DDS agent creates standard DDS communication entities according to the information in the message and sends a STATUS message for each successful creation. The XRCE DDS client determines which communication entity's status this message represents according to the request_id of the STATUS message and updates the status table. The XRCE DDS client checks the status table of the communication entities at all times until the XRCE DDS initialization is completed after all the communication entities are ready on the XRCE DDS agent. Finally, after the XRCE DDS initialization is completed, the XRCE DDS client can request the agent to send or receive DDS messages through WRITE_DATA or READ_DATA. The XRCE DDS agent replies with the corresponding message and proxies the DDS service. In these processes, no guarantee is made for the quality of service either.

[0052] The quality of service mode of reliable transmission, usually abbreviated as the RELIABLE mode. For details, please refer to Figure 9 , Figure 9This is an example diagram of the reliable transmission quality of service communication mechanism for the lightweight DDS provided by the embodiments of this application. In the RELIABLE mode, it is necessary to ensure that the messages transmitted through the reliable data stream can reach the peer end. Therefore, when the XRCE DDS client receives a message transmitted through the reliable stream, it needs to send an ACKNACK message and a HEARTBEAT message. The purpose of sending the HEARTBEAT message is to indicate the sequence number of the unacknowledged reliable stream sent by the XRCE DDS client, and the purpose of sending the ACKNACK message is to indicate the sequence number of the first unacknowledged reliable stream of the XRCE DDS agent. After receiving the HEARTBEAT message and the ACKNACK message, if the XRCE DDS agent finds that there are messages sent by the XRCE DDS client that have not been received, it will send an ACKNACK message to request the XRCE DDS client to retransmit the unacknowledged messages. If it is found that the messages sent by the XRCE DDS agent have not been acknowledged and received by the XRCE DDS client, the XRCE DDS agent will retransmit the unacknowledged messages. After receiving the ACKNACK message, the XRCE DDS client will determine whether it is necessary to retransmit the message. Due to the existence of the confirmation retransmission mechanism, when initializing and communicating XRCE DDS in the RELIABLE mode, in addition to sending basic messages such as CREATE_CLIENT, STATUS_AGENT, CREATE, STATUS, WRITE_DATA, and READ_DATA necessary to complete the function like in the BE mode, the XRCE DDS client and the XRCE DDS agent also need to send HEARTBEAT messages and ACKANACK messages to ensure the reliable transmission of the basic messages. During the initialization process of XRCE DDS in the RELIABLE mode of the embodiments of this application, the XRCE DDS client first sends a CREATE_SESSION message using the default stream. Subsequently, after determining that the session creation of the XRCE DDS agent is completed, the XRCE DDS client creates a reliable input / output stream and uses this data stream to send and receive messages. The subsequent communication process between the XRCE DDS client and the agent is basically the same as that in the BE mode, and HEARTBEAT messages and ACKNACK messages are interspersed during the communication process to ensure reliable communication.

[0053] The following combines Figure 10 to introduce the communication mechanism for the lightweight DDS provided by the embodiments of this application to process messages in real time on the AUTOSAR CP platform. Figure 10This is an example diagram of the communication mechanism for AUTOSAR real-time processing messages of the lightweight DDS provided by the embodiments of this application. In the XRCE DDS initialization phase of the embodiments of this application, the initialization of message sending and session creation are implemented by the microcontroller core 2, and message reception and parsing are implemented by core 0. After the initialization is completed, the microcontroller of the embodiments of this application and the domain controller will implement message loopback communication through the DDS protocol stack. During the message loopback communication process, the reception will be implemented by another runnable of core 2. Since the message loopback communication process is the same as the initialization reception process, only the processing cores are different, so only the XRCE DDS initialization process of the embodiments of this application will be introduced in detail below.

[0054] When the lightweight DDS of the embodiments of this application is initialized on the AUTOSAR CP platform, first, the runnable in the SWC of core 2 calls the initialization function to create a session and send a CREATE_CLIENT message. After sending, it enters a confirmation loop. If the STATUS of the session creation is correct, the creation of the next XRCE DDS communication entity will be carried out. Otherwise, it will continue to wait until timeout. After timeout, an error value will be returned, and this SWC will retry the XRCE DDS initialization. After core 2 creates the XRCE DDS communication entity, it sends a CREATE message to the XRCE DDS proxy side and also enters a confirmation loop. If all communication entities are successfully created on the XRCE DDS proxy side, the initialization is completed. Otherwise, it will continue to wait until timeout. When timeout occurs, an error value will be returned, and this SWC will retry the XRCE DDS initialization. During the XRCE DDS initialization process, the reception is completed by core 0. The reception triggers the XRCE DDS reception first interface by the AUTOSAR reception interrupt. After the interrupt is triggered, the message header is first parsed, and the data stream type is judged according to the message header information. There are three types of data streams: default stream (None), reliable stream (Reliable), and best-effort stream (best_effort). According to the type of sub-message in the message, the XRCE DDS client and proxy side will select different data streams for message transmission and assign different values to the corresponding fields of the message header. For the reliable stream, in addition to parsing the message content, storing the data, and executing the callback function for other operations, the XRCE DDS will also send an ACKNACK message; for the default stream, the type of its sub-message is usually STATUS, so the XRCE DDS usually updates the STATUS and INFO information of the session after parsing the message content; for the best-effort stream, the way the XRCE DDS processes the message is similar to that of the reliable stream, but it will not send an ACKNACK message after the parsing and processing are completed. After all sub-messages of the message are parsed and processed, the XRCE DDS will publish a HEARTBEAT message through the reliable stream to ensure that all the reliable stream messages sent locally are correctly received.

[0055] Based on the above communication mechanism of the lightweight DDS for real-time message processing on the AUTOSAR CP platform, the embodiments of this application can implement two communication functions, namely the asynchronous startup function and the restart and reconnection function. For the asynchronous startup function, please refer to Figure 11 , Figure 11 which is an example diagram of the communication mechanism of the asynchronous startup function of the lightweight DDS provided by the embodiments of this application. The asynchronous startup specifically means that when the XRCE DDS client starts, if the XRCE DDS agent has not started yet, it periodically sends messages to wait for the XRCE DDS agent to start. In the embodiments of this application, when the domain controller has not started, the microcontroller will continuously send CREATE_CLIENT messages at a period of 100 ms until the XRCE DDS agent starts and replies with the STATUS_AGENT message, and then further complete the subsequent XRCE DDS initialization process. In the embodiments of this application, to prevent blocking core 2 due to too long an initialization timeout confirmation time for XRCE DDS during the asynchronous startup process, the original waiting time and retry times are adjusted. In the code provided by the open source protocol, the original waiting time is 1000 ms and the retry times are 10 times. Therefore, if the XRCE DDS agent on the domain controller fails to start correctly within 10 s, core 2 will be in a process of waiting - confirmation - retry all the time, blocking the execution of other tasks of core 2 and reducing the performance of the AUTOSAR real-time operating system. In the embodiments of this application, the waiting time is adjusted to 20 ms, the retry times are 0, and the confirmation time of the communication entity is 70 ms. In this way, the overall execution duration of the runnable is reduced, the blocking of core 2 by XRCE DDS initialization is reduced, and the real-time performance of AUTOSAR CP is improved. For the restart and reconnection function, please refer to Figure 12 , Figure 12 which is an example diagram of the communication mechanism of the restart and reconnection function of the lightweight DDS provided by the embodiments of this application. The restart and reconnection function specifically means that when the XRCE DDS client has to restart due to technical reasons, the XRCE DDS agent can re - proxy the DDS communication function for this client. In the embodiments of this application, the domain controller does not perceive the state of the microcontroller in real time because the microcontroller may go into sleep at irregular times and the domain controller is not allowed to wake it up without permission. Therefore, when the microcontroller restarts and creates a session again, the XRCE DDS agent will update the client registry using the replacement mode and reply with the STATUS_AGENT message. Similarly, when the XRCE DDS agent receives a CREATE message, it will recreate the communication entity for the same client with the same ID in a replacement manner and reply with the STATUS message, thus implementing the restart and reconnection function.

[0056] In summary, in the above embodiments of the present invention, the method for constructing a communication middleware based on an open architecture deploys lightweight DDS in AUTOSAR CP. Compared with the traditional IP-based service-centric communication middleware in AUTOSAR CP, the DDS middleware enhances the guarantee of service quality. On the other hand, the communication mechanism of the lightweight DDS middleware proposed in this application for real-time processing of messages in AUTOSAR CP can effectively combine DDS and AUTOSAR CP, reduce the blocking time of the MCU for executing tasks, and reduce the resource occupation of DDS at the MCU end. Finally, the lightweight DDS deployed under AUTOSAR CP implemented in this application is almost imperceptible to the upper-layer SWC, and the lightweight DDS module can be called on the premise of slightly modifying the code of the application service layer.

[0057] Embodiment 2 On the other hand, the present invention also proposes a system for constructing a communication middleware based on an open architecture. Please refer to Figure 13 , which shows the system for constructing a communication middleware based on an open architecture in the second embodiment of the present invention. The system includes: A model construction module 11, configured to obtain an open architecture model required for constructing a lightweight communication middleware; An interface modification module 12, configured to modify the data communication structure of the lightweight communication middleware into a data communication interface based on the open architecture model, wherein the communication transport layer protocol adopted by the data communication interface includes the User Datagram Protocol and the Transmission Control Protocol; A data processing module 13, configured to deploy the basic data processing and communication functions of the lightweight communication middleware in the open architecture model, and construct an upper-layer service interface of the lightweight communication middleware in the open architecture model, and use the upper-layer service interface to implement specific calls of software components in the open architecture model, wherein the upper-layer service interface includes an initialization service interface and a data publication service interface of the lightweight communication middleware.

[0058] Further, the model construction module 11 includes: A first interface configuration unit, configured to obtain a corresponding TCP / IP protocol stack based on the open architecture, and configure the unicast address of the TCP / IP protocol stack and its communication interface with the upper-layer socket adapter SoAd module; A second interface configuration unit, configured to configure the communication interface between the socket adapter SoAd module and the complex driver module Cdd to obtain a corresponding open architecture model.

[0059] Further, the interface modification module 12 includes: A type conversion unit for determining a transmission protocol identifier according to the platform type and performing data type conversion on the sending data address and length to convert them into the PDU information type required by the SoAd general sending interface; An interface call unit for calling the SoAd general sending interface to pass the PDU information type to the underlying TCP / IP protocol stack to implement the sending of the interface data of the lightweight communication middleware.

[0060] Further, the interface modification module 12 is specifically configured to: Parse the received PDU data and temporarily store its data start pointer and data length information; Determine whether the initialization of the lightweight communication middleware is completed. If the initialization of the lightweight communication middleware is completed, the PDU data is passed to the upper-layer application, and the upper-layer application calls the corresponding interface of the lightweight communication middleware to perform deserialization of the message and extraction of service data; If the initialization of the lightweight communication middleware is not completed, the message is directly read and processed in the SoAd transfer interface.

[0061] Further, the data processing module 13 is specifically configured to: Construct the data to be sent by the lightweight communication middleware in the topic format and perform serialization processing on the data to be sent through the serialization interface to obtain serialized data; Put the serialized data into the output stream and call the push stream interface of the protocol stack of the communication middleware to publish the content of the output stream.

[0062] The functions or operation steps implemented when the above-mentioned modules and units are executed are substantially the same as those in the above method embodiment, and will not be elaborated here.

[0063] The communication middleware construction system based on an open architecture provided by the embodiments of the present invention has the same implementation principle and technical effects as those in the foregoing method embodiments. For the sake of brief description, for the parts not mentioned in the system embodiment, reference may be made to the corresponding content in the foregoing method embodiments.

[0064] Embodiment III The present invention also proposes a computer. Please refer to Figure 14 , which shows the computer in the third embodiment of the present invention, including a memory 10, a processor 20, and a computer program 30 stored on the memory 10 and executable on the processor 20. When the processor 20 executes the computer program 30, the above-mentioned method for constructing a communication middleware based on an open architecture is implemented.

[0065] Among them, the memory 10 at least includes one type of readable storage medium, and the readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (such as SD or DX memory, etc.), magnetic memory, magnetic disk, optical disc, etc. The memory 10 can be an internal storage unit of a computer in some embodiments, such as the hard disk of the computer. The memory 10 can also be an external storage device in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Further, the memory 10 can also include both the internal storage unit of the computer and the external storage device. The memory 10 can be used not only to store application software installed in the computer and various types of data, but also to temporarily store data that has been output or will be output.

[0066] Among them, the processor 20 can be an Electronic Control Unit (ECU, also known as a vehicle computer), a Central Processing Unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips in some embodiments, and is used to run the program code stored in the memory 10 or process data, such as executing an access restriction program, etc.

[0067] It should be noted that Figure 14 The structure shown does not constitute a limitation on the computer. In other embodiments, the computer may include fewer or more components than shown in the figure, or combine some components, or have a different component layout.

[0068] An embodiment of the present invention also provides a readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the method for constructing communication middleware based on an open architecture as described above.

[0069] Those skilled in the art can understand that the logic and / or steps represented in the flowchart or described in other ways herein, for example, can be considered as a definite sequence list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in combination with these instruction execution systems, apparatus, or devices. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device.

[0070] More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection (electronic device) having one or more wirings, a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable media can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpretation, or otherwise processing as appropriate, and then storing it in a computer memory.

[0071] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: a discrete logic circuit having logic gate circuits for implementing logical functions on data signals, an application specific integrated circuit having appropriate combinational logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0072] The technical features of the above-described embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as falling within the scope described in this specification.

[0073] The above-described embodiments merely represent several implementation manners of the present application. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the appended claims.

Claims

1. A method for constructing communication middleware based on an open architecture, characterized in that: include: Obtain the open architecture model required to build lightweight communication middleware; Modifying the data communication structure of the lightweight communication middleware into a data communication interface based on the open architecture model, wherein the communication transport layer protocols adopted by the data communication interface include the User Datagram Protocol and the Transmission Control Protocol; The basic data processing and communication functions of the lightweight communication middleware are deployed in the open architecture model, and an upper-level service interface of the lightweight communication middleware in the open architecture model is constructed. The upper-level service interface is used to implement specific calls to software components of the open architecture model, wherein the upper-level service interface includes an initialization service interface and a data publishing service interface of the lightweight communication middleware.

2. The method for constructing communication middleware based on an open architecture according to claim 1, characterized in that: The steps to obtain the open architecture model required to build lightweight communication middleware include: Acquire the corresponding TCP / IP protocol stack based on the open architecture, and configure the unicast address of the TCP / IP protocol stack and its communication interface with the upper layer socket adapter SoAd module; The communication interface between the socket adapter SoAd module and the complex driver module Cdd is configured to obtain a corresponding open architecture model.

3. The method for constructing communication middleware based on an open architecture according to claim 1, characterized in that: The step of modifying the data communication structure of the lightweight communication middleware into a data communication interface based on the open architecture model comprises: Determine the transmission protocol identifier according to the platform type, and convert the data type of the sending data address and length to convert them into the PDU information type required by the SoAd general sending interface; The SoAd universal sending interface is called to pass the PDU information type to the lower layer TCP / IP protocol stack to implement the sending of the interface data of the lightweight communication middleware.

4. The method for constructing communication middleware based on an open architecture according to claim 1, characterized in that: The step of modifying the data communication structure of the lightweight communication middleware into a data communication interface based on the open architecture model comprises: Parse the received PDU data and temporarily store its data start pointer and data length information; Determine whether the initialization of the lightweight communication middleware is completed. If the initialization of the lightweight communication middleware is completed, pass the PDU data to the upper-layer application, and the upper-layer application calls the interface corresponding to the lightweight communication middleware to deserialize the message and extract the service data; If the initialization of the lightweight communication middleware is not completed, the message is read and processed directly in the SoAd transfer interface.

5. The method for constructing communication middleware based on an open architecture according to claim 1, characterized in that: The steps of constructing the upper layer service interface of the lightweight communication middleware in the open architecture model include: Constructing the data to be sent of the lightweight communication middleware according to the subject format, and serializing the data to be sent through a serialization interface to obtain serialized data; The serialized data is placed in an output stream, and a stream push interface of the protocol stack of the communication middleware is called to publish the content of the output stream.

6. A communication middleware construction system based on an open architecture, characterized in that: include: Model building module, used to obtain the open architecture model required to build lightweight communication middleware; An interface modification module, used to modify the data communication structure of the lightweight communication middleware into a data communication interface based on the open architecture model, wherein the communication transport layer protocols adopted by the data communication interface include the User Datagram Protocol and the Transmission Control Protocol; A data processing module is used to deploy the basic data processing and communication functions of the lightweight communication middleware in the open architecture model, and to construct an upper-level service interface of the lightweight communication middleware in the open architecture model, and to use the upper-level service interface to implement specific calls to software components of the open architecture model, wherein the upper-level service interface includes an initialization service interface and a data publishing service interface of the lightweight communication middleware.

7. The communication middleware construction system based on open architecture according to claim 6, characterized in that: The model building module includes: A first interface configuration unit, configured to obtain a corresponding TCP / IP protocol stack based on an open architecture, and configure a unicast address of the TCP / IP protocol stack and a communication interface between the TCP / IP protocol stack and an upper layer socket adapter SoAd module; The second interface configuration unit is used to configure the communication interface between the socket adapter SoAd module and the complex driver module Cdd to obtain a corresponding open architecture model.

8. The communication middleware construction system based on open architecture according to claim 6, characterized in that: The interface modification module includes: A type conversion unit, used to determine the transmission protocol identifier according to the platform type, and perform data type conversion on the address and length of the sent data to convert them into the PDU information type required by the SoAd universal sending interface; The interface calling unit is used to call the SoAd universal sending interface to pass the PDU information type to the lower layer TCP / IP protocol stack to realize the sending of the interface data of the lightweight communication middleware.

9. A readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for constructing communication middleware based on an open architecture as described in any one of claims 1 to 5 is implemented.

10. A computer comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method for constructing communication middleware based on an open architecture as described in any one of claims 1 to 5 is implemented.

Images