WO2022222901A1 - 一种基于autosar实现dds通信的系统架构、通信方法及设备 - Google Patents

一种基于autosar实现dds通信的系统架构、通信方法及设备 Download PDF

Info

Publication number
WO2022222901A1
WO2022222901A1 PCT/CN2022/087550 CN2022087550W WO2022222901A1 WO 2022222901 A1 WO2022222901 A1 WO 2022222901A1 CN 2022087550 W CN2022087550 W CN 2022087550W WO 2022222901 A1 WO2022222901 A1 WO 2022222901A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
message
swc
dds
architecture
Prior art date
Application number
PCT/CN2022/087550
Other languages
English (en)
French (fr)
Inventor
马松君
蒋斌
李振飞
徐艳琴
孔振强
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP22791009.8A priority Critical patent/EP4322483A1/en
Publication of WO2022222901A1 publication Critical patent/WO2022222901A1/zh
Priority to US18/492,446 priority patent/US20240045657A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H04L41/0886—Fully automatic configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/547—Messaging middleware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Definitions

  • the present application relates to the technical field of vehicle management, and in particular, to a system architecture, a communication method and a device for realizing DDS communication based on AUTOSAR.
  • Automotive open system architecture is a set of standard protocols jointly established by major automotive OEMs, component suppliers, and automotive electronics software companies around the world.
  • the protocol specifies an open and standardized software architecture for automotive electronic software development.
  • the formulation of the original AUTOSAR specification only considered the traditional automotive electronic and electrical architecture, and provided certain functions based on scenarios with limited hardware computing power. This is what is usually referred to as Classic AUTOSAR, or CP for short.
  • the "AUTOSAR” mentioned in various technical documents generally refers to CP.
  • CP Currently, most manufacturers in the world develop software based on the AUTOSAR architecture.
  • AP adaptive automotive open system architecture
  • CP devices based on AUTOSAR ie Classic AUTOSAR, CP
  • SOME/IP a communication middleware
  • AP devices based on Adaptive AUTOSAR ie AP
  • DDS also a communication middleware
  • the CP device can only communicate with the application using SOME/IP in the AP device, but cannot communicate with the application using DDS in the AP device.
  • the current solution is to use the data distribution service (data distribution service, The basic functions of DDS) are implemented in CDD in the software architecture of CP.
  • CDD is used to carry functional modules outside the CP specification, but this method breaks the habit of traditional CP users using tools for automatic development, requiring developers to manually develop A lot of codes are added and modified to use various interfaces of DDS, and the service-oriented communication capability with AP devices cannot be achieved.
  • the embodiments of the present application provide a system architecture, a communication method, and a device for realizing DDS communication based on AUTOSAR, which are used to integrate DDS into the BSW in the CP software architecture, so that the DDS is compatible with the CP, so as to achieve a software component (software component, SWC) is unaware of modifications to the underlying software.
  • a software component software component, SWC
  • the embodiments of the present application first provide a system architecture for realizing DDS communication based on AUTOSAR, which can be used in vehicle management technology.
  • the system architecture includes: at least one first integrated module, DDS architecture, AUTOSAR, and the first integrated module is constructed
  • the DDS architecture is deployed in the basic software layer (basic software, BSW) in AUTOSAR.
  • AUTOSAR also includes a runtime environment (RTE) and at least one SWC.
  • the first integration module is used for managing message publishers and/or message subscribers, for example, for managing the automatic discovery process between message publishers and message subscribers, and for example, in one or more
  • the data in the message publisher and/or the message subscriber is managed, and the specific management method is not limited in this application; in AUTOSAR
  • the RTE is used to store the mapping relationship between each first integrated module and its corresponding SWC signal.
  • the SWC signal is a signal sent by the SWC to the RTE and used to provide the DDS architecture.
  • a new system architecture which integrates the DDS into the BSW in the CP software architecture, and manages the message publishers and/or message subscribers through the first integration module , so that DDS is compatible with CP, so that SWC is not aware of the modification of the underlying software.
  • the first integration module may be used to manage the automatic discovery process between the message publisher and the message subscriber.
  • the implementation manner may be that the first integration module is specifically used for: based on The automatic discovery mechanism of the DDS architecture determines the pairing status between at least one message publisher and at least one message subscriber, for example, the pairing status between m message publishers and n message subscribers; In the case where at least one message subscriber is paired, for example, the m message publishers and the n message subscribers are all paired, then the at least one message publisher and/or the at least one message subscriber is further paired. data in the management.
  • the first integration module is used to manage the automatic discovery process between the message subscriber and the message publisher, which is achievable.
  • the first integration module can be used not only to manage the automatic discovery process between the message publisher and the message subscriber, but also to manage the message publisher and the message after the automatic discovery process ends. data between subscribers.
  • the implementation method may be that the first integrated module is specifically used to: first, obtain the target SWC signal from the RTE, and then determine the target message corresponding to the target SWC signal according to the target SWC signal to publish where the target message publisher is one of at least one message publisher, such as one of m message publishers; after that, the target message publisher is instructed to send the first target data from the target SWC (that is, the The data to be sent) is sent to the target message subscriber (that is, the receiving end of the first target data), wherein the target SWC is the SWC corresponding to the target SWC signal, belonging to the SWC deployed on AUTOSAR, and the target message subscriber is at least one message subscription one of the subscribers, eg, one
  • the first integration module can be used not only to manage the automatic discovery process between the message publisher and the message subscriber, but also to manage the message publisher and the message subscription after the automatic discovery process ends.
  • the application specifically describes how the first integration module is used to manage the reply/request-based sending data of the target SWC, with flexibility.
  • the implementation manner may be that the first integration module is further configured to: receive the first instruction sent by the target message subscriber, the first The instruction is used to indicate that the target message subscriber has obtained the second target data sent by the target message publisher (that is, the data sender), and the target message publisher is one of the at least one message publisher, such as m message publishing one of the subscribers, and the target message subscriber is one of the at least one message subscriber, such as one of n message subscribers; after that, instruct the RTE to acquire the second target data based on the first instruction, so that the target The SWC uses the second target data on the RTE.
  • the second target data is not directly sent to the target SWC, but is received by the RTE. When the target SWC wants to use the second target data, it is used by calling.
  • the first integration module can be used not only to manage the automatic discovery process between the message publisher and the message subscriber, but also to manage the message publisher and the message subscription after the automatic discovery process ends.
  • the application specifically describes how the first integration module is used to manage the received data based on the reply/request of the target SWC, with flexibility.
  • the first integration module may be further configured to: after acquiring the first instruction sent by the target message subscriber, subscribe the message corresponding to the target message publisher (eg, Pub3)
  • the identification information of the subscriber eg, Sub3
  • the identification information can be the address of the message subscriber, or the field corresponding to the message subscriber, as long as the information that can uniquely identify the message subscriber can be called
  • the identification information described in this application does not limit the type of identification information here.
  • the first integration module may also be used to: send the identification information to the RTE, and the RTE stores the identification information.
  • the first integration module when the first integration module is used to manage the received data based on the reply/request of the target SWC, the first integration module can be used to The identification information is stored, or the identification information is sent to the RTE, and the RTE stores the identification information.
  • the purpose of storing the identification information is that when the target SWC feeds back data, there is no need to perform a pairing search, and it can directly determine which message subscriber to feed back to, reducing the time extension.
  • the system architecture may further include: a target module (eg, a DDS-SD module), the target module is embedded in a BSW management unit (BSW-M) in the BSW, the The target module is used to manage the corresponding Simple Participant Discovery Protocol (SPDP) messages and/or Simple Endpoint Discovery Protocol (SPDP) messages for each participant (eg, unified management of each Participant behavior, parameters, etc.) discovery protocol, SEDP) message interaction process, wherein, the interaction process is used to realize the automatic discovery mechanism of the DDS architecture.
  • a target module eg, a DDS-SD module
  • BSW-M BSW management unit
  • SPDP Simple Participant Discovery Protocol
  • SPDP Simple Endpoint Discovery Protocol
  • SEDP Simple Endpoint Discovery Protocol
  • the target module is embedded in the BSW-M in the BSW to solve the problem of service discovery, and the automatic discovery of the DDS architecture is realized through the embedded target module, which is achievable.
  • the system architecture may further include: a code generation module, configured to generate code fragments from the SPDP information and/or SEDP information corresponding to each participant, and in the first When the participant is in the automatic discovery process, the code fragments corresponding to the first participant are assembled to form SPDP information and/or SEDP information corresponding to the first participant, and the first participant is the one or more of the participants.
  • a code generation module configured to generate code fragments from the SPDP information and/or SEDP information corresponding to each participant, and in the first When the participant is in the automatic discovery process, the code fragments corresponding to the first participant are assembled to form SPDP information and/or SEDP information corresponding to the first participant, and the first participant is the one or more of the participants.
  • the code generation module generates code fragments in advance with the SPDP information and/or SEDP information corresponding to each participant, and reproduces and assembles them at runtime. This method can reduce the noise floor of the memory and save the memory space. .
  • the code generation module may be further configured to: store the acquired SPDP information and/or SEDP information of the opposite end of the first participant as dynamic information, wherein the dynamic information information for temporary storage.
  • the SPDP information and/or SEDP information sent from the peer end of the first participant needs to be stored as dynamic information, which is achievable.
  • the first SWC when the first SWC has a DDS history cache requirement, the first SWC satisfies the DDS history cache requirement by occupying memory space, and the first SWC is One of the SWCs deployed in this AUTOSAR.
  • the SWC for the SWC that has the DDS historical cache requirement, the SWC is allowed to allocate the memory space on demand by occupying the memory space.
  • the first SWC occupies memory space by using stack space.
  • the memory space is directly occupied by using the stack space, which is flexible.
  • a second aspect of the embodiments of the present application further provides a method for implementing DDS communication based on AUTOSAR.
  • the method is applied to a system architecture, where the system architecture includes at least one first integrated module, DDS architecture, and AUTOSAR, wherein the first integrated module is constructed in In the DDS architecture, the DDS architecture is deployed in the BSW in the AUTOSAR, and the AUTOSAR includes the RTE and the SWC.
  • the method includes: first, the RTE receives the target SWC signal sent by the target SWC deployed in the AUTOSAR, wherein the target SWC signal is the target SWC to the target SWC signal.
  • DDS is integrated into the BSW in the CP software architecture, and the first integration module manages the message publishers and/or message subscribers, so that the DDS is compatible with the CP, thereby realizing the SWC to the bottom layer.
  • Software modifications are imperceptible.
  • the first integration module may be used to manage the automatic discovery process between the message publisher and the message subscriber.
  • the first integration module subscribes to the message publisher and/or the message
  • the process of managing a message publisher may be: the automatic discovery mechanism based on the DDS architecture determines the pairing status between at least one message publisher and at least one message subscriber, for example, the pairing between m message publishers and n message subscribers Status; in the case where at least one message publisher and at least one message subscriber are paired, for example, the m message publishers and the n message subscribers are all paired, then the at least one message publisher is further paired and/or data in the at least one message subscriber.
  • the first integration module manages the automatic discovery process between the message subscriber and the message publisher, which is achievable.
  • the process of the target integration module managing the target message publisher and/or the target message subscriber according to the target SWC signal may be to manage the reply/request-based sending data of the target SWC
  • the specific implementation can be as follows: the target integration module determines a target message publisher corresponding to the target SWC signal according to the target SWC signal, wherein the target message publisher is one of at least one message publisher, such as one of m message publishers Afterwards, the target integration module instructs the target message publisher to send the first target data from the target SWC (that is, the data to be sent of the target SWC) to the target message subscriber (that is, the receiving end of the first target data), wherein the target The SWC is the SWC corresponding to the target SWC signal, belonging to the SWC deployed on AUTOSAR, and the target message subscriber is one of at least one message subscriber, for example, one of n message subscribers.
  • the target integration module may further manage the target message publisher and/or target message subscriber based on the received data of the SWC based on the reply/request, and the specific implementation manner may be: target integration
  • the module receives the first instruction sent by the target message subscriber, and the first instruction is used to indicate that the target message subscriber has obtained the second target data sent by the target message publisher (ie, the sender of the data), and the target message publisher is the One of the at least one message publisher, such as one of m message publishers, and the target message subscriber is one of the at least one message subscriber, such as one of n message subscribers; after that, the target integration
  • the module then instructs the RTE to acquire the second target data based on the first instruction, so that the target SWC uses the second target data on the RTE.
  • the second target data is not directly sent to the target SWC, but is received by the RTE. When the target SWC wants to use the second target data, it is used by calling.
  • the target integration module manages the received data based on the reply/request of the target SWC, which is flexible.
  • the target integration module may integrate the message subscriber (eg, Sub3) corresponding to the target message publisher (eg, Pub3) ), the identification information can be the address of the message subscriber, or it can be the field corresponding to the message subscriber, as long as it is the information that can uniquely identify the message subscriber, it can be called the information described in this application. Identification information, the type of identification information is not limited here.
  • the target integration module may also send the identification information to the RTE, and the RTE stores the identification information.
  • the target integration module when the target integration module is managing the received data based on the reply/request of the target SWC, the target integration module can store the identification information of the message subscriber corresponding to the target message publisher, or The identification information is sent to the RTE and stored by the RTE.
  • the purpose of storing the identification information is that when the target SWC feeds back data, there is no need to perform pairing search, and it can directly determine which message subscriber to feed back to, thereby reducing delay.
  • the automatic discovery mechanism of the DDS architecture is triggered and executed by a target module (eg, a DDS-SD module) in a BSW management unit (BSW-M) embedded in the BSW, and the target module
  • a target module eg, a DDS-SD module
  • BSW-M BSW management unit
  • the interaction process used to manage the corresponding SPDP messages and/or SEDP messages of each participant is used to implement the automatic discovery mechanism of the DDS architecture.
  • the embedded target module is to solve the problem of service discovery, and the automatic discovery of the DDS architecture is realized through the embedded target module, which is achievable.
  • the method may further include: the system architecture generates code snippets from the SPDP information and/or SEDP information corresponding to each participant, and when the first participant is in automatic discovery In the case of the process, the code fragments corresponding to the first participant are assembled to form SPDP information and/or SEDP information corresponding to the first participant, and the first participant is one of the participants or more.
  • the SPDP information and/or SEDP information corresponding to each participant is generated in advance, and the code fragments are reproduced and assembled at runtime, which can reduce the noise floor of the memory and save the memory space.
  • the method may further include: when the target SWC has a DDS history cache requirement, determining that the target SWC satisfies the DDS history cache requirement by occupying memory space.
  • the target SWC if the target SWC has a DDS history cache requirement, the target SWC is allowed to allocate memory space on demand by occupying memory space.
  • the method may further include: in the case that the target SWC has no DDS history cache requirement, determining that the target SWC occupies memory space by using stack space.
  • the target SWC directly occupies the memory space by using the stack space, which is flexible.
  • a third aspect of the embodiments of the present application further provides a method for implementing DDS communication based on AUTOSAR, the method comprising: in a network configuration tool, there are some configuration parameters related to the use of SOME/IP communication, which can be directly SOME/IP design method) to configure network parameters and generate a first configuration file.
  • the network parameter configuration is performed through a network design tool to generate a first configuration file; if the DDS-related parameter configuration is not customized in the first configuration file, the configuration conversion tool can be used in the The default configuration of the DDS is automatically filled in the first configuration file, and the filled first configuration file is obtained.
  • the filled first configuration file is converted into a second configuration file identifiable by the DDS by using a configuration conversion tool.
  • the configuration conversion tool converts SOME/IP-related configurations into DDS-related configurations, in which the related parameters of Event, Method, and Field of SOME/IP are correspondingly converted into DDS service integration parameters, Participant parameters, etc.
  • the port/signal parameters of CP are converted into DDS Pub/Sub/Topic and other related parameters, and various service-oriented IDs are converted into DDS Topic Name and service discovery-related QoS parameters.
  • the DDS-related supplementary configuration contained in the network configuration tool and the AUTOSAR configuration tool will also be considered.
  • a variety of default configurations are stored here, and according to the configuration in the network configuration tool, automatic Fill in the default supplementary configuration, where the filled parameter items can include the DDS QoS parameters at runtime, the mapping relationship between the SWC signal in the RTE and the DDS, etc.
  • the AUTOSAR configuration tool is used to automatically complete the parameter configuration of the ECU related to the DDS in the second configuration file to obtain the completed second configuration file, and generate the BSW code according to the completed second configuration file.
  • the AUTOSAR configuration tool there will be some DDS-related supplementary configurations, as well as the supplementary rules of RTE docking with DDS supplementary rules and BSW. For advanced developers, customized modifications can also be made.
  • the BSW code is used to implement the function of the method of the first aspect or any possible implementation manner of the first aspect.
  • the method further includes: designing the function of the SWC by using the SWC modeling tool, and generating the SWC code.
  • the method further includes: deploying the BSW code and the SWC code on an ECU to run, wherein a multi-protocol interworking device (Gateway) is deployed on the ECU, and the Gateway is used for Realize the intercommunication between SOME/IP and DDS.
  • a multi-protocol interworking device Gateway
  • the generated BSW code and SWC code are deployed on the ECU to run, and the gateway is deployed to realize intercommunication between different protocols.
  • the Gateway monitors the sending ports of all external applications by running an instance therein, and performs message operation control and message forwarding for service discovery messages and user messages.
  • the Gateway Including a message conversion module and a message control module; the message conversion module is used to perform the message format conversion between SOME/IP and DDS on the received message; the message control module is used to carry out SOME/IP and DDS according to the content carried by the message. The conversion of the message sending and receiving process between DDS.
  • the Gateway realizes the interworking between SOME/IP and DDS is described in detail.
  • the Gateway provided by the embodiment of the present application is different from the traditional solution, and does not run the receiving and sending protocols of the two protocols, but Running an instance improves the performance of the system.
  • the method further includes: performing parameter configuration through a design tool, and generating a third configuration file; generating target code according to the third configuration file, where the target code is used to implement the Gateway function.
  • the Gateway can also perform automatic code generation through corresponding design tools, which is flexible.
  • a fourth aspect of the embodiments of the present application provides a computer device, where the computer device has a function of implementing the method of the second aspect or any possible implementation manner of the second aspect.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a fifth aspect of the embodiments of the present application provides a tool system, where the tool system has a function of implementing the method of the third aspect or any possible implementation manner of the third aspect.
  • This function can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • a sixth aspect of an embodiment of the present application provides a computer device, which may include a memory, a processor, and a bus system, wherein the memory is used to store a program, and the processor is used to call the program stored in the memory to execute the second aspect of the embodiment of the present application or any possible implementation method of the second aspect.
  • a seventh aspect of an embodiment of the present application provides a tool system, which may include a memory, a processor, and a bus system, wherein the memory is used to store a program, and the processor is used to call the program stored in the memory to execute the third aspect of the embodiment of the present application or any one of the possible implementations of the third aspect.
  • An eighth aspect of the embodiments of the present application provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, when the computer-readable storage medium runs on a computer, the computer can execute the second aspect or any one of the second aspects.
  • a ninth aspect of an embodiment of the present application provides a computer program, which, when run on a computer, enables the computer to execute the method of the second aspect or any possible implementation manner of the second aspect, or enables the computer to execute the method of the second aspect above.
  • the method of the three aspects or any possible implementation manner of the third aspect is not limited to:
  • a tenth aspect of an embodiment of the present application provides a chip, where the chip includes at least one processor and at least one interface circuit, the interface circuit is coupled to the processor, and the at least one interface circuit is configured to perform a transceiver function and send an instruction to At least one processor, at least one processor is used to run a computer program or instruction, which has the function of implementing the method as described above in the second aspect or any possible implementation manner of the second aspect, or, it has the function of implementing the method as described above in the third aspect or
  • the function of the method in any possible implementation manner may be implemented by hardware, software, or a combination of hardware and software, and the hardware or software includes one or more functions corresponding to the above-mentioned functions. module.
  • FIG. 1 is an example of a service application provided by an embodiment of the present application
  • Fig. 2 is a schematic diagram of the ecology of the AUTOSAR provided by the embodiment of the application;
  • FIG. 3 is a schematic diagram of CP communication provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a SOME/IP service discovery process provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of AP communication provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of a DDS subscription publishing model provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of an automatic discovery process of a DDS service provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of three service-oriented communication forms provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a problem existing in the implementation of intelligent vehicle-as-a-service communication in the existing AUTOSAR specification provided by the embodiment of the present application.
  • FIG. 10 is a schematic diagram of a software running process based on the current technical architecture
  • Fig. 11 is a schematic diagram of integrating DDS in CDD to achieve compatibility
  • Figure 12 is a schematic diagram of the design and operation flow of the CDD implementation scheme
  • FIG. 13 is a schematic diagram of an overall architecture of a system provided by an embodiment of the present application.
  • FIG. 14 is a schematic diagram of a system architecture provided by an embodiment of the present application.
  • 15 is a schematic flowchart of a method for implementing DDS communication based on AUTOSAR provided by an embodiment of the application;
  • 16 is a schematic diagram of a BSW module integrating DDS into a CP provided by an embodiment of the present application;
  • FIG. 17 is another schematic diagram of a BSW module integrating DDS into a CP provided by an embodiment of the present application.
  • FIG. 18 is a schematic diagram of a runtime solution for reducing memory noise floor provided by an embodiment of the present application.
  • 21 is a schematic flowchart of a Gateway implementation solution provided by an embodiment of the present application.
  • Fig. 22 is a schematic flowchart of code generation and code operation in the embodiment of the present application.
  • FIG. 23 is another schematic flowchart of a process for generating BSW codes and SWC codes provided by an embodiment of the present application.
  • 24 is a schematic structural diagram of a tool system provided by an embodiment of the present application.
  • FIG. 25 is a schematic structural diagram of a device provided by an embodiment of the present application.
  • the embodiments of the present application provide a system architecture, a communication method, and a device for realizing DDS communication based on AUTOSAR, which are used to integrate DDS into the BSW in the CP software architecture, so that the DDS is compatible with the CP, so that the SWC can modify the underlying software No perception.
  • FIG. 1 is an example of a service-oriented application provided by the embodiment of the present application.
  • the automatic driving path planning function and the automatic high beam control function are advanced functions that are deployed in the AP architecture and are user-perceivable. , these functions require various services to provide data and control capabilities.
  • Each service may come from a simple capability provided by an ECU, or from an AP device (that is, a device that deploys an AP, generally a CPU board with large computing power).
  • AP device that is, a device that deploys an AP, generally a CPU board with large computing power.
  • Provides complex capabilities such as map services, GPS services, etc.
  • CP and AP Due to the coexistence of CP and AP in the automotive electronic and electrical architecture, as well as the increasingly popular service requirements, the CP specification formulated for traditional vehicles can no longer fully meet the needs of the current vehicle electronic service architecture. Among them, the problem of unified service communication of CP and AP is included, and the present invention will solve this problem.
  • FIG. 2 is a schematic diagram of the ecology of AUTOSAR provided by the embodiment of the application, which includes a software architecture and a tool form, and the top layer in the software architecture is the application layer (Application layer).
  • Layer the application layer deploys several SWCs, and each SWC is used to implement corresponding specific functions.
  • the operation of SWC requires RTE to provide a runtime environment, which implements the communication between internal SWCs and the signal connection and scheduling connection between SWC and BSW.
  • BSW is called the basic software layer, which provides various basic capabilities for the upper-layer software SWC, such as communication capabilities, memory management capabilities, hardware abstraction, and drivers.
  • the SWC realizes the communication of the Ethernet network and needs to interact with the RTE.
  • the RTE sends the signal to the BSW for signal processing, and finally sends it to the network protocol stack to send out.
  • Signal reception is the opposite process to the above, and will not be repeated here.
  • the CDD layer is used to store functional modules outside the CP specification. That is to say, for the capabilities required in the software but not specified by the AUTOSAR protocol, the developed functions can be put into the CDD, and the calling interface can be exposed to the application.
  • a tool is a set of tool software released along with the AUTOSAR software stack.
  • the usage of AUTOSAR is different from that of traditional basic software.
  • Traditional basic software eg, operating system
  • AUTOSAR runs on different hardware devices, each ECU on the vehicle may implement different functions, using different hardware capabilities, software capabilities, and communication capabilities, and each application implements different functions, so AUTOSAR is a highly customized Software Architecture. Companies that develop AUTOSAR will provide supporting tools.
  • the user configures the internal parameters of AUTOSAR and designs the application through the tool, and then the tool generates the code of the application and the AUTOSAR basic software, and the generated code is then deployed to the ECU to run.
  • the tool generates the code of the application and the AUTOSAR basic software, and the generated code is then deployed to the ECU to run.
  • no handwritten code is required at all, or when developing applications, only some uncommon function implementation logic needs to be handwritten.
  • the tools of AUTOSAR can be roughly divided into two categories: SWC modeling tools and AUTOSAR configuration tools.
  • SWC modeling tools are used to model the framework and behavior of applications, and finally generate SWC code;
  • AUTOSAR configuration tools are used for each layer.
  • Configure the parameters and behaviors (such as communication parameter configuration, RTE parameter configuration, scheduling parameter configuration, etc.), and finally generate AUTOSAR basic code, which can be called BSW code.
  • BSW code The combination of the two types of code, plus some static basic AUTOSAR code, can make the ECU function run.
  • FIG. 3 is a schematic diagram of CP communication provided by an embodiment of the present application.
  • the CP Ethernet communication stipulates that SOME/IP protocol is used. It is the SOME/IP sub-module and the CP module involved. In the CP specification, the Ethernet communication uses the SOME/IP protocol.
  • SOME/IP relies on the COM module (usually LDCOM) within the RTE and BSW/PduR module/SoAd The module realizes the connection of the network protocol stack, the search of the service ID and the control of the data sending and receiving logic.
  • FIG. 4 is a schematic diagram of a SOME/IP service discovery process provided by an embodiment of the present application. After the process shown in FIG. 4 , a connection is established between the Server and the Client, and a service communication process can be started.
  • AP is a basic software architecture based on POSIX interface, which provides various functional modules for upper-layer applications, as shown in Figure 5, where ARA: The COM module provides communication service capabilities.
  • the specification stipulates that the Ethernet communication uses SOME/IP and DDS communication middleware. In AP equipment, SOME/IP and DDS are compatible.
  • ARA::COM is based on the automatic discovery and data communication capabilities of the middleware itself, packaged into the ability of service discovery, and carries out the management and control of service-oriented communication.
  • DDS is a new generation of distributed real-time communication middleware technical specifications formulated by Object Management Group (OMG) on the basis of HLA and CORBA standards.
  • OMG Object Management Group
  • DDS adopts a publish/subscribe architecture, emphasizes data-centricity, provides rich QoS service quality policies, ensures real-time, reliable, and flexible data distribution, and can meet the needs of various distributed real-time communication applications.
  • FIG. 6 is a schematic diagram of a DDS subscription and publishing model provided by an embodiment of the present application.
  • the DDS subscription and publishing model shows the operation logic architecture of DDS (DDS is a set of architectural standards, and a participant Participant can be considered as a application, the application Participant needs to run in accordance with DDS standards).
  • the outermost operating entity of DDS is called Participant.
  • One or more message publishers (Publisher, Pub) and message subscribers (Subscriber, Sub) can be deployed in it.
  • Publisher and Subscriber are code logic, which can be regarded as the data sending module and data receiving module in the Participant application.
  • Deploying several Publishers and Subscribers is defined in the network design tool stage.
  • the Publisher's Data Writer and the Subscriber's Data Reader are paired with the same topic name and compatible QoS, so that the message publisher can send messages to the matching message subscribers.
  • Message publishers and message subscribers can have one or more Data Writers and Data Readers. Different Data Writers of each message publisher do not limit their Topic Name or QoS must be consistent, which brings great flexibility to message communication.
  • each Data Writer or Data Reader has its own History Cache.
  • History Cache is used to cache the data to be sent; for Data Reader, History Cache is used to cache received data. to the data.
  • the essence of DDS data transmission is the information transmission between the History Caches at both ends.
  • FIG. 7 is a schematic diagram of an automatic discovery process of DDS services provided by an embodiment of the present application.
  • SPDP data packets are sent and received to perform pairing between Participants, and then SEDP data packets are sent and received between paired Participants. Subscriber) to configure the pair, the paired Data Writer and Data Reader can send and receive data.
  • Node A and Node B in Figure 7 are running instances of two DDSs, that is, two DDS-based Participants.
  • the CP and AP standardize the same service-based communication form, as shown in FIG. 8 , which is a schematic diagram of three service-based communication forms provided by this embodiment of the present application.
  • the Method method is that the Client sends a request message (Request) to the Server, and the Server generates a reply message (Response) according to the request, and sends the reply message to the Client; in the Event method, the Server will periodically/irregularly send the current data to the Client. ;
  • the Field method can be considered as a combination of Event and Method (ie, the method of choosing 1 from 2), which is used to obtain data or set parameters.
  • the CP specification only stipulates the use of SOME/IP for communication, while DDS and SOME/IP can be used in the AP. If some ECUs connected to small devices are allowed to provide service-oriented capabilities for domain computing nodes that carry APs, it can only be provided for applications that use SOME/IP communication in APs. For applications using DDS, the services provided by the ECU cannot be used. Since DDS can provide more than 20 kinds of QoS capabilities, realize reliable multicast data transmission, support large packet transmission, inter-process communication and cross-core communication within the operating system, DDS can meet various communication requirements compared with SOME/IP. need.
  • the corresponding SWC is also developed based on the SOME/IP standard, and the communication with the peer end is also incompatible with the application using DDS in the AP.
  • the car factory also uses a third-party device (such as the 3rd device SWC in Figure 9) to connect to AUTOSAR, since the third-party device is also designed in strict accordance with the CP specification, its corresponding SWC is also developed based on the SOME/IP standard , the user cannot modify it. At this time, there will be problems when the application using DDS communicates with the third-party device, as shown in line segment 2 in Figure 9.
  • DDS itself is based on the data-centric architecture idea, that is, DDS provides the ability to send and receive data to the outside world, while service-oriented software requires basic software to provide service-oriented communication capabilities (currently CP equipment is through SOME/IP, AP equipment This capability is provided through ARA::COM combined with middleware). How to convert the data-centric capability of DDS into service-centric capability in CP is also a technical problem to be solved by this application.
  • Figure 2 shows the software architecture and tool ecosystem of CP.
  • Figure 9 shows the service-oriented communication path between the CP and the AP based on the existing SOME/IP specification. Based on the current technical architecture, Figure 10 shows the specific tool design and software operation process.
  • the AUTOSAR running code (that is, the code of the basic software, generated by the AUTOSAR configuration tool) is generated.
  • the developer uses the SWC modeling tool to design the function of the SWC, and then generates the SWC code (ie, the code of the application software, which is generated by the SWC modeling tool).
  • the SWC modeling can also be carried out in parallel with the previous work, or carried out at the very beginning (the following process can also be done in the same way, and will not be repeated here).
  • SWC transmits signals to RTE, and RTE hands it to each module of BSW layer.
  • the internal functions of SOME/IP are combined with COM and PDU-R modules to transfer the signals of application layer to the modules of BSW layer.
  • SoAd In the form of service, it is sent out through SoAd.
  • Servicing data reception is the reverse process. It should be noted that the data obtained by the CP device through the SWC is service-oriented data.
  • the existing CP specification can satisfy the service-oriented communication between the CP and the AP application or CP application using SOME/IP. However, as mentioned above, it cannot satisfy the service-based communication between the CP and the AP or CP application using DDS.
  • a solution is shown in Figure 11.
  • the CDD is used to carry functional modules other than the CP specification, which is the application layer.
  • a calling interface which implements the basic functions of DDS in CDD.
  • the development mode does not have the ability to communicate with the AP as a service.
  • Fig. 12 is the design and operation flow of the CDD implementation scheme (gray boxes indicate the step differences from the normative scheme in Fig. 10).
  • SWC can only send and receive data, not service request and provision.
  • SWC directly calls the DDS interface and relies on the implementation of the DDS protocol inside the CDD to perform DDS initialization, automatic discovery, data sending and receiving, and data sequence. Serialize/deserialize, and finally send out over Ethernet (receive is the reverse process). In this way, data can only be sent and received with the DDS application of another CP device, rather than service-oriented communication.
  • this implementation scheme has broken the habit of using tools for automatic development and code generation in traditional CP, and has very strong requirements on the knowledge reserve of developers. Developers must master how to use DDS and its internal communication principles. In order to identify network parameter requirements, it also adds a lot of workload to developers. That is to say, for the DDS provider, the implementation is simple, but the complex work is all handed over to the AUTOSAR user. In addition, this method can only realize the sending and receiving of data, and does not realize the service, so it can only communicate with the CP of other ECUs in the form of data, and other forms of intercommunication shown in Figure 12 cannot be realized. Moreover, this implementation has a large noise floor (>200KB), which is unacceptable for embedded ECU devices.
  • the goal of the embodiments of the present application is to realize the unified service-oriented communication capability inside the vehicle, which can be summarized as two points: 1) realize the DDS service-oriented intercommunication between the CP and the AP; 2) the application using DDS is compatible with the existing traditional Compatible with the CP SOME/IP standard, it satisfies the capability of compatible third-party device service communication.
  • the method provided by the embodiment of the present application enables the inter-vehicle communication to achieve inter-communication across communication protocols and inter-domain (AP and CP) inter-communication by combining the functions of existing specifications, and finally achieves a unified service-oriented communication capability within the entire vehicle.
  • FIG. 13 is a schematic diagram of the overall architecture of the system provided by the embodiments of the present application, wherein, The gray bottom frame is different from the existing system architecture, mainly as follows: 1) This application implements the DDS function in the BSW layer, in parallel with the SOME/IP path, and is upward compatible with RTE and downwardly connected to TCP/IP , thin the entire protocol stack implementation, reduce the software process as much as possible, and reduce the transmission delay. At the same time realize the service ability.
  • FIG. 14 is a schematic diagram of the system architecture provided by the implementation of the present application.
  • the system architecture includes: at least one first An integrated module 1401, DDS architecture 1402, AUTOSAR 1403, the first integrated module 1401 is constructed in the DDS architecture 1402, and the DDS architecture 1402 is deployed in the BSW 1404 in the AUTOSAR 1403, in addition, the AUTOSAR 1403 also includes an RTE 1405 and at least one SWC 1406 .
  • the first integration module 1401 is used to manage message publishers and/or message subscribers, for example, for managing the automatic discovery process between message publishers and message subscribers, and for example, in one or more
  • the data in the message publisher and/or the message subscriber is managed, and the specific management method is not limited in this application;
  • AUTOSAR The RTE 1405 in 1403 is used to store the mapping relationship between each first integrated module 1401 and the corresponding SWC signal.
  • the SWC signal is sent by the SWC 1406 to the RTE 1405 and used to provide the DDS architecture. 1402 signal.
  • the first integration module 1401 can either be constructed in a participant (Participant) of the DDS architecture 1402 , or the first integrated module 1401 is an additionally constructed module in the DDS architecture 1402 .
  • constructing the first integrated module 1401 includes but is not limited to the following ways:
  • the first integrated module 1401 is constructed in the participants (Participants) of the DDS architecture 1402, the number of the participants is n, and the number of the first integrated modules 1401 is m, n ⁇ 1, m ⁇ 1 1.
  • DDS is integrated into the BSW module of CP, DDS-R (which may not be further distinguished) realizes basic RTPS capabilities, and connects to RTE upwards, and DDS-T (which may not be further distinguished) downwardly communicates with The network protocol stack is connected, and the History Cache capability is integrated.
  • the logical relationship between Publisher and Subscriber of DDS is managed to realize the service discovery and service communication capabilities of Event, Method and Field.
  • each participant ie Participant A to Participant N
  • the number is less than the number of participants, that is, it can be a first integration module with at least one participant (the corresponding first integration module can be deployed in any one of the multiple participants in its service), and the setting is a first integration module Serve all participants (this first integration module can be deployed on any one of the corresponding multiple participants), which is not specifically limited here.
  • the first integrated module 1401 is additionally constructed in the DDS architecture 1402 as a separate module.
  • the first integrated module 1401 is used as an additional module (not shown in FIG. 14 ), which is constructed in the original DDS architecture 1402 .
  • the benefit of this deployment is that the original DDS architecture 1402 does not need to be changed.
  • the DDS architecture 1402 is deployed in the BSW 1404 in the AUTOSAR 1403, when the first integration module 1401 is constructed in one or more participants of the DDS architecture 1402, then the DDS architecture is Each participant in 1402 (i.e. whether or not the participant deploys the first integration module 1401) is deployed within the BSW 1404 in the AUTOSAR 1403; for another example, when the first integration module 1401 is an additionally built module in the DDS architecture 1402 , then the first integration module 1401 and each original participant in the DDS architecture 1402 are deployed in the BSW 1404 in the AUTOSAR 1403.
  • the first integration module 1401 can be used not only to manage the automatic discovery process between the message publisher and the message subscriber, but also to manage the message publishing after the automatic discovery process ends.
  • the data between the message subscriber and the message subscriber is described below:
  • the first integration module 1401 is used to manage the automatic discovery process between the message publisher and the message subscriber.
  • the implementation may be that the first integration module 1401 is specifically configured to: determine the pairing state between at least one message publisher and at least one message subscriber based on the automatic discovery mechanism of the DDS architecture 1402, for example, m message publishers and The pairing state between n message subscribers; in the case where at least one message publisher and at least one message subscriber are paired, for example, the m message publishers and the n message subscribers are all paired, Then, the data in the at least one message publisher and/or the at least one message subscriber is further managed.
  • the first integration module 1401 is used to manage the data between the message publisher and the message subscriber after the automatic discovery process ends.
  • the first integrated module 1401 may be specifically used to: first, obtain the target SWC signal from the RTE 1405, and then determine the target corresponding to the target SWC signal according to the target SWC signal A message publisher, wherein the target message publisher is one of at least one message publisher, such as one of m message publishers; after that, the target message publisher is instructed to send the first target data from the target SWC (that is, the target The data to be sent of the SWC) is sent to the target message subscriber (that is, the receiving end of the first target data), wherein the target SWC is the SWC corresponding to the target SWC signal, belonging to the SWC deployed on AUTOSAR 1403, and the target message subscriber is at least One of a message subscriber, eg, one of n message subscribers.
  • the implementation can be that the first integration module 1401 is further configured to: receive the first instruction sent by the target message subscriber, where the first instruction is used to indicate that the target message subscriber has obtained the information from the target message subscriber
  • the second target data sent by the message publisher that is, the data sender
  • the target message publisher is one of the at least one message publisher, such as one of m message publishers
  • the target message subscriber is the One of at least one message subscriber, such as one of n message subscribers
  • instruct the RTE 1405 to acquire the second target data based on the first instruction, so that the target SWC performs the second target data on the RTE 1405. use.
  • the second target data is not directly sent to the target SWC, but is received by the RTE 1405. When the target SWC wants to use the second target data, it is used by calling.
  • the first integration module 1401 may also be configured to: after obtaining the first instruction sent by the target message subscriber, to The identification information of the message subscriber (eg, Sub3) is stored, and the identification information can be the address of the message subscriber, or the field corresponding to the message subscriber, as long as it is the information that can uniquely identify the message subscriber. It is called the identification information described in this application, and the type of identification information is not limited here.
  • the first integration module 1401 can also be used to: send the identification information to the RTE 1405, and the RTE 1405 stores the identification information.
  • a target module in order to solve the problem of service discovery, can be further produced, and the target module can be embedded in the BSW-M in the BSW1404 (not shown in FIG. 14 ) , the target module is used to manage the respective Simple Participant Discovery Protocol (SPDP) messages and/or Simple End Node Discovery Protocol ( simple endpoint discovery protocol, SEDP) message interaction process, wherein, the interaction process is used to implement the automatic discovery mechanism of the DDS architecture 1402.
  • the target module is a DDS-SD module, which is embedded in the BSW-M for periodic invocation or trigger invocation by the BSW-M.
  • the system architecture may further include: a code generation module (not shown in FIG. 14 ) for Corresponding SPDP information and/or SEDP information generate code fragments in advance, and then, when the first participant is in the automatic discovery process, assemble the code fragments corresponding to the first participant to form a code fragment corresponding to the first participant.
  • SPDP information and/or SEDP information corresponding to the participant the first participant is one or more of the participants.
  • FIG. 18 is a schematic diagram of a runtime solution for reducing memory noise floor provided by an embodiment of the present application.
  • DDS-Info includes dynamically generated code storage service messages, that is, AUTOSAR configuration.
  • the tool generates the code in advance with the information required for service discovery, and the other part is the dynamic information obtained at runtime.
  • the required information will first be found from the code and assembled on-site at runtime , the advantage of this is that the CP device generally has a small memory, so the method of generating code in advance can save memory space and avoid using a large amount of memory stack space for long-term storage of SPDP messages and/or SEDP messages.
  • DDS-Info may also include dynamic information, that is, the acquired SPDP information and/or SEDP information of the peer end of the first participant will be stored as dynamic information.
  • dynamic information is the peer information obtained by participants during service discovery. If the first participant and the second participant perform service discovery, the first participant sends its SPDP and SEDP to the second participant. For the second participant, this information is the peer's information obtained during the service discovery phase. information, which may change with the online and offline of the peer and changes in parameters, so it is called dynamic information.
  • DDS History Cache requirements which can be called the first SWC, which is any of the SWCs deployed in AUTOSAR
  • the application will be allowed to occupy memory space to meet its DDS History Cache requirements; no such Applications that require DDS History Cache directly use the stack space to temporarily occupy memory.
  • the execution logic of this part is generated by the tool.
  • the communication method provided by the embodiment of the present application involves three parts: 1) modification of the CP basic software, integrating DDS in the CP stack; 2) modification of the tool to integrate DDS; 3) the design of the Gateway , in order to realize the interoperability of different protocols. Based on these three parts, the following descriptions will be made separately.
  • FIG. 15 is a schematic flowchart of a method for implementing DDS communication based on AUTOSAR provided by an embodiment of the present application.
  • the method can be applied to the system architecture corresponding to the above-mentioned FIG. 14 , and the system architecture includes at least one first integrated module.
  • DDS architecture, AUTOSAR the first integrated module is built in DDS architecture
  • DDS architecture is deployed in BSW in AUTOSAR
  • AUTOSAR includes RTE and SWC
  • the method may specifically include the following steps:
  • the RTE receives the target SWC signal sent by the target SWC deployed in AUTOSAR.
  • the RTE receives the target SWC signal sent by the target SWC deployed in AUTOSAR, where the target SWC signal is the signal sent by the target SWC to the RTE and used to provide the DDS architecture.
  • the RTE determines a target integrated module corresponding to the target SWC signal according to the mapping relationship between each first integrated module stored in the RTE and the corresponding SWC signal, and the first integrated module is used for the message publisher and/or Message subscribers are managed.
  • the RTE After the RTE receives the target SWC signal sent by the target SWC deployed in AUTOSAR, the RTE determines the target integration corresponding to the target SWC signal according to the mapping relationship between each first integration module and the corresponding SWC signal stored in the RTE module, wherein the first integration module is used for managing message publishers and/or message subscribers, for example, for managing the automatic discovery process between message publishers and message subscribers, and for example, in one or more When a message publisher is paired with one or more message subscribers, the data in the message publisher and/or the message subscriber is managed, and the specific management method is not limited in this application.
  • the first integration module may be used to manage the automatic discovery process between the message publisher and the message subscriber, and the implementation process may be: the automatic discovery mechanism based on the DDS architecture determines at least one The pairing status between the message publisher and at least one message subscriber, for example, the pairing status between m message publishers and n message subscribers; when at least one message publisher and at least one message subscriber have completed the pairing In a case where, for example, the m message publishers and the n message subscribers are all paired, the data in the at least one message publisher and/or the at least one message subscriber is further managed.
  • the first integration module manages the automatic discovery process between the message subscriber and the message publisher, which is achievable.
  • the RTE sends the target SWC signal to the target integrated module.
  • the RTE After determining the target integrated module corresponding to the target SWC signal according to the mapping relationship between each first integrated module and the corresponding SWC signal stored in the RTE, the RTE sends the target SWC signal to the target integrated module.
  • the target integration module manages the target message publisher and/or the target message subscriber according to the target SWC signal.
  • the target integration module After the target integration module receives the target SWC signal sent by the RTE, the target integration module manages the target message publisher and/or the target message subscriber according to the target SWC signal.
  • the target integration module manages the target message publisher and/or the target message subscriber according to the target SWC signal, which may be to manage the sent data based on the reply/request of the target SWC.
  • the implementation can be: the target integration module determines a target message publisher corresponding to the target SWC signal according to the target SWC signal, wherein the target message publisher is one of at least one message publisher, such as one of m message publishers; After that, the target integration module instructs the target message publisher to send the first target data from the target SWC (that is, the data to be sent from the target SWC) to the target message subscriber (that is, the receiving end of the first target data), wherein the target SWC is the SWC corresponding to the target SWC signal, belonging to the SWC deployed on AUTOSAR, and the target message subscriber is one of at least one message subscriber, for example, one of n message subscribers.
  • the target integration module may also manage the target message publisher and/or target message subscriber based on the received data of the reply/request for the SWC, and the specific implementation manner may be: The target integration module receives the first instruction sent by the target message subscriber, and the first instruction is used to indicate that the target message subscriber has obtained the second target data sent by the target message publisher (ie, the data sender).
  • the target message publisher is one of the at least one message publisher, such as one of m message publishers
  • the target message subscriber is one of the at least one message subscriber, such as one of n message subscribers
  • the target integration module then instructs the RTE to acquire the second target data based on the first instruction, so that the target SWC uses the second target data on the RTE.
  • the second target data is not directly sent to the target SWC, but is received by the RTE.
  • the target SWC wants to use the second target data, it is used by calling.
  • the target integration module may integrate the message subscriber (eg, Pub3) corresponding to the target message publisher (eg, Pub3). , Sub3) identification information is stored, the identification information can be the address of the message subscriber, or the field corresponding to the message subscriber, as long as the information that can uniquely identify the message subscriber can be called the The identification information described above, the type of identification information is not limited here.
  • the target integration module may also send the identification information to the RTE, and the RTE stores the identification information.
  • the target integration module when the target integration module manages the received data based on the reply/request of the target SWC, the target integration module can store the identification information of the message subscriber corresponding to the target message publisher, or store the identification information of the message subscriber corresponding to the target message publisher, or The identification information is sent to the RTE and stored by the RTE.
  • the purpose of storing the identification information is that when the target SWC feeds back data, there is no need to perform pairing search, and it can directly determine which message subscriber to feed back to, thereby reducing delay.
  • the automatic discovery mechanism of the DDS architecture is triggered and executed by a target module (eg, a DDS-SD module) in the BSW management unit (BSW-M) embedded in the BSW.
  • the target module is used to manage the interaction process of the corresponding SPDP messages and/or SEDP messages of each participant (eg, unified management of each Participant behavior, parameters, etc.), and the interaction process is used to realize the automatic discovery mechanism of the DDS architecture.
  • the embedded target module is to solve the problem of service discovery, and the automatic discovery of the DDS architecture is realized through the embedded target module, which is achievable.
  • the target SWC at runtime, if the target SWC has a DDS History Cache requirement, the target SWC is allowed to satisfy its DDS History Cache requirement by occupying memory space; This DDS History Cache requirement allows the target SWC to directly use the stack space to temporarily occupy memory.
  • the execution logic of this part is generated by the tool.
  • FIG. 19 is a schematic flowchart of a method for implementing DDS communication based on AUTOSAR provided by an embodiment of the present application.
  • the method may specifically include the following steps:
  • the network configuration tool there are some configuration parameters related to the use of SOME/IP communication, and the network parameter configuration can be performed directly according to the original method (ie, the design method of SOME/IP) to generate the first configuration file.
  • the network design tool additionally provides DDS-related supplementary configurations, and developers who understand DDS can perform customized network design. The network design tool will eventually generate a first configuration file for the configuration conversion tool to continue designing.
  • the network configuration tool described in this embodiment of the present application adds an optional DDS-related supplementary configuration.
  • DDS-related parameter configuration is not customized in the first configuration file, use a configuration conversion tool to automatically fill in the default configuration of DDS in the first configuration file, to obtain a filled first configuration file.
  • the default configuration of DDS can be automatically filled in the first configuration file by using a configuration conversion tool to obtain the filled first configuration file.
  • the filled first configuration file is converted into a second configuration file identifiable by the DDS through a configuration conversion tool. That is to say, the configuration conversion tool converts SOME/IP-related configurations into DDS-related configurations, in which the related parameters of Event, Method, and Field of SOME/IP are correspondingly converted into DDS service integration parameters, Participant parameters, etc.
  • the port/signal parameters of CP are converted into DDS Pub/Sub/Topic and other related parameters, and various service-oriented IDs are converted into DDS Topic Name and service discovery-related QoS parameters.
  • the DDS-related supplementary configuration contained in the network configuration tool and the AUTOSAR configuration tool will also be considered.
  • a variety of default configurations are stored here, and according to the configuration in the network configuration tool, automatic Fill in the default supplementary configuration, where the filled parameter items can include the DDS QoS parameters at runtime, the mapping relationship between the SWC signal in the RTE and the DDS, etc.
  • this configuration conversion tool is proposed for the first time in this embodiment of the present application, and is used to convert SOME/IP related configurations into DDS related configurations, and automatically fill in the default configuration of DDS.
  • This configuration conversion tool does not exist in existing solutions. .
  • the AUTOSAR configuration tool is used to automatically complete the parameter configuration of the ECU related to the DDS in the second configuration file to obtain the completed second configuration file, and generate the BSW code according to the completed second configuration file. It should be noted that in the AUTOSAR configuration tool, there will be some DDS-related supplementary configurations, as well as the supplementary rules of RTE docking with DDS supplementary rules and BSW. For advanced developers, customized modifications can also be made.
  • the BSW code is used to implement the communication method described in the above-mentioned embodiment corresponding to FIG. 15 .
  • the SWC function can be designed through the SWC modeling tool, and the Generate SWC code. It should be noted here that the process of generating BSW code and generating SWC code can be executed in parallel, or you can first generate the corresponding BSW code through the network configuration tool, configuration conversion tool and AUTOSAR configuration tool, and then generate the SWC code through the SWC modeling tool.
  • the BSW code and the SWC code can be deployed and run on an ECU, wherein a multi-protocol interworking device is deployed on the ECU (Gateway), the Gateway is used to realize the intercommunication between SOME/IP and DDS. How Gateway realizes the interworking between SOME/IP and DDS will be described in the third part below.
  • the traditional Gateway will run the receiving/sending instances of the two protocols respectively.
  • the external transceiver node communicates with the instance in the Gateway, and the two instances in the Gateway convert and transmit the message format through the intermediate conversion device. This method will cause a large number of instances to run inside the system, which will seriously affect the performance of the system.
  • the Gateway provided by the embodiment of the present application is different from the traditional solution. It does not run the receiving and sending protocols of the two protocols, but runs an instance, which monitors the sending ports of all external applications, and performs message transmission for service discovery messages and user messages. Run control and forwarding of messages.
  • the Gateway includes a message conversion module and a message control module, wherein the message conversion module is used to perform the message format conversion between SOME/IP and DDS on the received message; the message control module is used to perform SOME/IP according to the content carried by the message. The conversion of the message sending and receiving process to and from DDS.
  • the function of the Gateway can also be realized by generating corresponding codes based on a configuration tool.
  • parameter configuration can be performed through a design tool, and a third configuration file can be generated, and then according to The third configuration file generates object code, and the object code is used to realize the function of the Gateway.
  • FIG. 21 is a schematic flowchart of a Gateway implementation scheme provided by an embodiment of the present application.
  • There is traditional message conversion logic in the Gateway which performs format conversion on the received message (Payload), and converts it into another message.
  • the message control logic will solve the problem of the different sending and receiving processes of SOME/IP and DDS, and control the sending and receiving sequence and time of its messages, so that the application on each protocol does not perceive that the peer instance communicating with it is. different communication protocols.
  • the SOME/IP service discovery message includes messages such as Find Service, Offer Service, Subscribe, and Subscribe ACK.
  • the automatic discovery messages of the DDS include SPDP messages and SEDP messages, and the running sequence thereof is also as described in the corresponding embodiment of FIG. 4 .
  • the message control logic will parse, integrate, and split the messages according to the content of each message and the content required by the protocol at each stage, and finally combine them into discovery messages identifiable by the peer protocol.
  • DDS has some control messages, and the message control logic also controls these messages. Since the QoS mechanism of DDS requires message caching, the caching capability is added to the Gateway, which is compatible with the DDS caching operation function. For design tools, it will increase the configuration capability of Gateway rules and automatic code generation.
  • FIG. 22 is the code generation method of the embodiment of the present application. and a schematic diagram of the code running, in which the gray bottom process box indicates that there is a difference with the CP standard specification.
  • the configuration conversion tool (the configuration conversion tool is first proposed in this application) to convert the configuration file generated by the network configuration tool into a configuration file identifiable by DDS), and then the generated configuration file Hand over to the AUTOSAR configuration tool for further processing.
  • the configuration conversion tool will configure and complement the DDS-related parameters not covered in the network design tool, and will also configure and complement the DDS-related ECU parameters not covered by the AUTOSAR configuration tool.
  • the configuration conversion tool stores a series of default configurations (that is, designed at the beginning), and it selects the appropriate default configuration to complete according to the communication mode configured in the network design tool. In this way, developers don't need to understand DDS, they just need to design in the original way.
  • the network configuration tool, configuration conversion tool, and AUTOSAR configuration tool are used to generate the underlying software code; the SWC configuration tool is used to generate the SWC code, and the generated SWC code will decide whether to use the DDS channel of the underlying code or the original according to its own needs. SOMEIP channel (i.e. self-match).
  • the SWC modeling tool in FIG. 22 only generates the SWC code corresponding to one SWC at a time in the code generation process, and the underlying software code (ie, the BSW code) above is generated at one time.
  • the parameters required by DDS can be configured in the network design tool, and then converted into the input configuration file of the AUTOSAR configuration tool by the configuration conversion tool.
  • the DDS-related ECU parameter configuration is customized and modified.
  • the modeling and code generation phases of the SWC modeling tool are consistent with the traditional specification process, and developers do not need special operations.
  • the AUTOSAR configuration tool In order to reduce the memory noise of DDS-based service as much as possible, the AUTOSAR configuration tool generates the information required for DDS service discovery as code in advance during code generation, so that at runtime, the DDS automatic discovery data package will be directly from the code. copied and assembled on site. For the History Cache capability of DDS, the AUTOSAR configuration tool also determines whether each communication link needs History Cache according to communication requirements, so as to customize the code generation.
  • the SWC can directly transmit the communication signal (ie, the SWC signal) to the RTE.
  • the communication signal ie, the SWC signal
  • RTE will map the SWC signal with the service management module of DDS (after RTE obtains the SWC signal, it can judge by itself whether to use the DDS channel or the SOMEIP channel).
  • DDS directly connects to the network protocol stack and sends data out (the receiving process is the opposite).
  • BSW-M will also control the service discovery process of DDS.
  • the two protocols are connected through the Gateway, which realizes multi-protocol interworking and satisfies the ability of devices using DDS to use third-party device services. Gateway's internal rules are set and code generated by the design tool.
  • the user first uses the tool to configure various parameters, generate configuration files, change the configuration, generate code (AUTOSAR code except SWC), and then design and generate code for SWC. All the codes are compiled together into a CP running file, and the compiled CP running file is deployed on the ECU. Similarly, Gateway's internal rules are also set through the design tool, and finally the code is generated.
  • the user deploys the Gateway on the device where the AP or CP is located. It runs as a process on the AP and as an SWC on the CP, as shown in Figure 23.
  • the methods of the above embodiments of the present application deeply integrate the DDS and CP standard architectures.
  • the SWC does not need any modification, and at the same time, the service-based communication capability is realized, so that the CP and the AP can achieve complete service-based intercommunication.
  • designers do not need to understand DDS, and the existing SWC and configuration files are designed based on SOME/IP, they can be quickly transplanted to the new ecology; the implementation of Gateway makes The new architecture is also compatible with services from third-party devices.
  • FIG. 24 is a schematic structural diagram of a tool system provided by an embodiment of the present application
  • the tool system 2400 includes: a network design tool 2401, a configuration conversion tool 2402, and AUTOSAR A configuration tool 2403, wherein the network design tool 2401 is used to configure network parameters based on the SOME/IP design method to generate a first configuration file; the configuration conversion tool 2402 is used to not customize in the first configuration file In the case of DDS-related parameter configuration, the default configuration of the DDS is automatically filled in the first configuration file to obtain the filled first configuration file; the configuration conversion tool 2402 is also used for the filled first configuration file.
  • the AUTOSAR configuration tool 2403 is used to automatically complete the parameter configuration of the electronic control unit (ECU) related to the DDS in the second configuration file, and obtain the completed A second configuration file, and a BSW code is generated according to the completed second configuration file, where the BSW code is used to implement the communication method described in the above-mentioned embodiment corresponding to FIG. 15 .
  • the tool system 2400 further includes a SWC modeling tool 2404 for designing the function of the SWC and generating the SWC code.
  • the tool system 2400 further includes a deployment module 2405 for deploying the BSW code and the SWC code to run on an ECU, wherein a multi-protocol interworking device (Gateway) is deployed on the ECU, and the Gateway It is used to realize the intercommunication between SOME/IP and DDS.
  • a deployment module 2405 for deploying the BSW code and the SWC code to run on an ECU, wherein a multi-protocol interworking device (Gateway) is deployed on the ECU, and the Gateway It is used to realize the intercommunication between SOME/IP and DDS.
  • Gateway multi-protocol interworking device
  • the tool system 2400 further includes a design tool 2406 for configuring parameters and generating a third configuration file; Function.
  • FIG. 25 is a schematic structural diagram of a device provided by an embodiment of the present application. For convenience of description, only the part related to the embodiment of the present application is shown. If the specific technical details are not disclosed, please refer to the embodiment of the present application. Methods section.
  • the modules described in the corresponding embodiment of FIG. 14 can be deployed on the device 2500 to realize the functions of the system architecture in the corresponding embodiment of FIG. 14; when the device 2500 is used as a tool system, The modules described in the embodiment corresponding to FIG.
  • the device 2500 is implemented by one or more servers, and the device 2500 may vary greatly due to different configurations or performance, and may include one or more central processing units (CPU) 2522 (for example, one or more one or more central processing units) and memory 2532, one or more storage media 2530 (eg, one or more mass storage devices) that store application programs 2542 or data 2544.
  • the memory 2532 and the storage medium 2530 may be short-term storage or persistent storage.
  • the program stored in the storage medium 2530 may include one or more modules (not shown in the figure), and each module may include a series of instructions to operate on the training device.
  • the central processing unit 2522 may be configured to communicate with the storage medium 2530 to execute a series of instruction operations in the storage medium 2530 on the device 2500.
  • Device 2500 may also include one or more power supplies 2526, one or more wired or wireless network interfaces 2550, one or more input and output interfaces 2558, and/or, one or more operating systems 2541, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.
  • operating systems 2541 such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM and many more.
  • the central processing unit 2522 when the device 2500 is used as a computer device, the central processing unit 2522 is configured to execute the steps in the corresponding embodiment of FIG. 15 .
  • the central processor 2522 can be used to: first, instruct the RTE to receive the target SWC signal sent by the target SWC deployed in AUTOSAR, where the target SWC signal is the signal sent by the target SWC to the RTE and used to provide the DDS architecture; then , instructs the RTE to determine the target integrated module corresponding to the target SWC signal according to the mapping relationship between each first integrated module stored in the RTE and the corresponding SWC signal, wherein the first integrated module is used for message publishers and / or message subscriber management, for example, to manage the automatic discovery process between message publishers and message subscribers, and for example, when one or more message publishers and one or more message subscribers complete the process In the case of pairing, the data in the message publisher and/or the message subscriber is managed, and the specific management method is not limited in this application; finally, the RTE is instructed to send the target
  • central processing unit 2522 may also be used to execute any step in the method embodiment corresponding to FIG. 15 in this application.
  • the central processing unit 2522 may also be used to execute any step in the method embodiment corresponding to FIG. 15 in this application.
  • any step in the method embodiment corresponding to FIG. 15 in this application please refer to the description in the method embodiment shown in the foregoing application, here No longer.
  • the central processing unit 2522 when the device 2500 is used as a tool system, the central processing unit 2522 is configured to execute the steps in the corresponding embodiment of FIG. 19 .
  • the central processing unit 2522 may be used to: perform network parameter configuration through a network design tool based on the SOME/IP design method, and generate the first configuration file. If the DDS-related parameter configuration is not customized in the first configuration file, the default configuration of DDS can be automatically filled in the first configuration file by using a configuration conversion tool to obtain the filled first configuration file. After that, the filled first configuration file is converted into a second configuration file identifiable by the DDS by using a configuration conversion tool.
  • the configuration conversion tool converts SOME/IP-related configurations into DDS-related configurations, in which the related parameters of Event, Method, and Field of SOME/IP are correspondingly converted into DDS service integration parameters, Participant parameters, etc.
  • the port/signal parameters of CP are converted into DDS Pub/Sub/Topic and other related parameters, and various service-oriented IDs are converted into DDS Topic Name and service discovery-related QoS parameters.
  • the DDS-related supplementary configuration contained in the network configuration tool and the AUTOSAR configuration tool will also be considered.
  • a variety of default configurations are stored here, and according to the configuration in the network configuration tool, automatic Fill in the default supplementary configuration, where the filled parameter items can include the DDS QoS parameters at runtime, the mapping relationship between the SWC signal in the RTE and the DDS, etc.
  • central processing unit 2522 can also be used to execute any step in the method embodiment corresponding to FIG. 19 in this application.
  • the central processing unit 2522 can also be used to execute any step in the method embodiment corresponding to FIG. 19 in this application.
  • the device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be A physical unit, which can be located in one place or distributed over multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution in this embodiment.
  • the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be retrieved from a website, computer, training device, or data Transmission from the center to another website site, computer, training facility or data center via wired (eg coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (eg infrared, wireless, microwave, etc.) means.
  • wired eg coaxial cable, fiber optic, digital subscriber line (DSL)
  • wireless eg infrared, wireless, microwave, etc.
  • the computer-readable storage medium may be any available medium that can be stored by a computer, or a data storage device such as a training device, a data center, or the like that includes an integration of one or more available media.
  • the usable media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVD), or semiconductor media (eg, Solid State Disk (SSD)), and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Multimedia (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备，可应用在智能行驶的智能体(如智能汽车、智能网联汽车、自动驾驶汽车)上，该系统架构包括：至少一个第一集成模块、数据分发服务(DDS)架构、汽车开放系统架构(AUTOSAR)，该第一集成模块构建于DDS架构内，DDS架构部署于AUTOSAR中的基础软件层(BSW)内，AUTOSAR包括运行时环境(RTE)以及软件组件(SWC)。其中，第一集成模块用于对消息发布者和/或消息订阅者进行管理，RTE用于存储每个第一集成模块与各自对应的软件组件(SWC)信号之间的映射关系，SWC信号为SWC向RTE发送的并用于提供给DDS架构的信号。本申请将DDS集成在CP软件架构中的BSW内，让DDS与CP兼容，做到SWC对底层软件的修改无感知。

Description

一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备
本申请要求于2021年4月22日提交中国专利局、申请号为202110435762.4、发明名称为“一种基于AUTOSAR实现DDS通信的软件架构设计方法及设备”，和要求于2021年6月25日提交中国专利局、申请号为202110714858.4、发明名称为“一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及车载管理技术领域，尤其涉及一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备。
背景技术
汽车开放系统架构(automotive open system architecture，AUTOSAR)是由全球各大汽车OEM、零部件供应商、汽车电子软件公司联合建立的一套标准协议。该协议规范了一个符合汽车电子软件开发的、开放的以及标准化的软件架构。最初的AUTOSAR规范的制定只考虑传统汽车电子电器架构，基于硬件算力有限场景，提供确定的功能。这就是通常所讲的Classic AUTOSAR，简称CP，各类技术文档所讲的“AUTOSAR”一般也特指CP，当前全世界绝大多数厂商都是基于AUTOSAR架构进行软件开发。
随着车辆当前正快速面向智能化演进，各类智能网联技术、自动驾驶技术快速迭代，车辆上的各类设备也爆发式增长，软件需求日益强大，分布式的汽车电子电气架构逐渐向功能域集中架构或中央集中架构演进，传统的AUTOSAR规范已不适合当前车辆电子的发展。因而汽车开放系统架构自适应平台(adaptive automotive open system architecture，AP)又被演进出来。AP主要用于承载智能化软件模块，部署于算力更强的硬件资源之上。车辆上所部署的各类传感器、执行器或其他功能器件，由于硬件能力有限，部分硬件依然需要CP的软件架构。
基于AUTOSAR(即Classic AUTOSAR，CP)的CP设备只规定使用SOME/IP(一种通信中间件)进行通信，而基于Adaptive AUTOSAR(即AP)的AP设备可以使用DDS(也是一种通信中间件)和SOME/IP进行通信，因此，CP设备只能与AP设备中使用SOME/IP的应用通信，而不能与AP设备中使用DDS的应用通信，目前解决方法是将数据分发服务(data distribution service，DDS)的基本功能实现在CP的软件架构里的CDD内，CDD是用于承载CP规范外的功能模块，但这种方式打破了传统CP使用者使用工具进行自动开发的习惯，需要开发人员手动增加和修改很多代码来使用DDS的各种接口，且无法做到与AP设备的服务化通信能力。
发明内容
本申请实施例提供了一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备，用于将DDS集成在CP软件架构中的BSW内，让DDS与CP兼容，做到软件组件(software  component，SWC)对底层软件的修改无感知。
基于此，本申请实施例提供以下技术方案：
第一方面，本申请实施例首先提供一种基于AUTOSAR实现DDS通信的系统架构，可用于车载管理技术中，该系统架构包括：至少一个第一集成模块、DDS架构、AUTOSAR，第一集成模块构建于DDS架构内，DDS架构部署于AUTOSAR中的基础软件层(basic software，BSW)内，此外，AUTOSAR还包括运行时环境(runtime environment，RTE)以及至少一个SWC。其中，第一集成模块，用于对消息发布者和/或消息订阅者进行管理，例如，用于管理消息发布者与消息订阅者之间的自动发现过程，又例如，在某一个或多个消息发布者与某一个或多个消息订阅者均完成配对的情况下，对该消息发布者和/或该消息订阅者中的数据进行管理，具体本申请对管理的方式不做限定；AUTOSAR中的RTE，用于存储每个第一集成模块与各自对应的SWC信号之间的映射关系，需要说明的是，该SWC信号为SWC向RTE发送的并用于提供给DDS架构的信号。
在本申请上述实施方式中，提供了一种新的系统架构，该系统架构将DDS集成在CP软件架构中的BSW内，并通过第一集成模块对消息发布者和/或消息订阅者进行管理，让DDS与CP兼容，从而实现SWC对底层软件的修改无感知。
在第一方面的一种可能的实现方式中，第一集成模块可用于管理消息发布者与消息订阅者之间的自动发现过程，具体地，实现方式可以是第一集成模块具体用于：基于DDS架构的自动发现机制确定至少一个消息发布者与至少一个消息订阅者之间的配对状态，如，m个消息发布者与n个消息订阅者之间的配对状态；在至少一个消息发布者与至少一个消息订阅者均完成配对的情况下，如，这m个消息发布者与这n个消息订阅者均被配对上，则进一步对该至少一个消息发布者和/或该至少一个消息订阅者中的数据进行管理。
在本申请上述实施方式中，具体阐述的是第一集成模块如何用于管理消息订阅者与消息发布者之间的自动发现过程，具备可实现性。
在第一方面的一种可能的实现方式中，第一集成模块除了可用于管理消息发布者与消息订阅者之间的自动发现过程，也可用于管理在自动发现过程结束后消息发布者与消息订阅者之间的数据。具体地，针对SWC基于回复/请求的发送数据，实现方式可以是第一集成模块具体用于：首先，从RTE获取目标SWC信号，再根据该目标SWC信号确定与目标SWC信号对应的目标消息发布者，其中，目标消息发布者为至少一个消息发布者中的一个，如m个消息发布者中的一个；之后，指示目标消息发布者将来自于目标SWC的第一目标数据(即目标SWC的待发送数据)向目标消息订阅者(即第一目标数据的接收端)发送，其中，目标SWC为与目标SWC信号对应的SWC，属于AUTOSAR上部署的SWC，目标消息订阅者为至少一个消息订阅者中的一个，如，n个消息订阅者中的一个。
在本申请上述实施方式中，具体阐述的是第一集成模块除了可用于管理消息发布者与消息订阅者之间的自动发现过程，也可用于管理在自动发现过程结束后消息发布者与消息订阅者之间的数据，本申请具体阐述了第一集成模块如何用于管理目标SWC的基于回复/请求的发送数据，具备灵活性。
在第一方面的一种可能的实现方式中，针对SWC基于回复/请求的接收数据，实现方 式可以是第一集成模块具体还用于：接收目标消息订阅者发送的第一指令，该第一指令用于表征目标消息订阅者已获取由目标消息发布者(即数据的发送端)发送的第二目标数据，目标消息发布者为所述至少一个消息发布者中的一个，如m个消息发布者中的一个，目标消息订阅者为所述至少一个消息订阅者中的一个如，n个消息订阅者中的一个；之后，再基于第一指令指示RTE获取该第二目标数据，以使得目标SWC对RTE上的第二目标数据进行使用。这里需要注意的是，该第二目标数据并不会直接发送至目标SWC，而是由RTE接收，目标SWC要使用该第二目标数据时，是通过调用使用。
在本申请上述实施方式中，具体阐述的是第一集成模块除了可用于管理消息发布者与消息订阅者之间的自动发现过程，也可用于管理在自动发现过程结束后消息发布者与消息订阅者之间的数据，本申请具体阐述了第一集成模块如何用于管理目标SWC的基于回复/请求的接收数据，具备灵活性。
在第一方面的一种可能的实现方式中，第一集成模块，还可用于：在获取到目标消息订阅者发送的第一指令之后，将目标消息发布者(如，Pub3)对应的消息订阅者(如，Sub3)的标识信息进行存储，该标识信息可以是该消息订阅者的地址，也可以是与消息订阅者对应的字段，只要是可以唯一识别该消息订阅者的信息都可称为本申请所述的标识信息，此处对标识信息的类型不做限定。或者，该第一集成模块也可用于：将该标识信息向RTE发送，由该RTE将标识信息进行存储。
在本申请上述实施方式中，具体阐述了当第一集成模块是用于管理目标SWC的基于回复/请求的接收数据时，第一集成模块可以用于将目标消息发布者对应的消息订阅者的标识信息进行存储，或者将该标识信息发送给RTE，由RTE存储，存储标识信息的目的在于，在目标SWC反馈数据时，无需再进行配对查找，可直接确定向哪个消息订阅者反馈，减少时延。
在第一方面的一种可能的实现方式中，该系统架构还可以包括：目标模块(如，DDS-SD模块)，该目标模块嵌入在该BSW中的BSW管理单元(BSW-M)，该目标模块用于管理每个参与者(如，统一管理每个Participant行为、参数等)各自对应的简单参与者发现协议(simple participant discovery protocol，SPDP)消息和/或简单端节点发现协议(simple endpoint discovery protocol，SEDP)消息的交互过程，其中，该交互过程用于实现DDS架构的自动发现机制。
在本申请上述实施方式中，在BSW中的BSW-M内嵌入目标模块是为了解决服务发现问题，通过嵌入的目标模块实现DDS架构的自动发现，具备可实现性。
在第一方面的一种可能的实现方式中，该系统架构还可以包括：代码生成模块，用于将与每个参与者各自对应的SPDP信息和/或SEDP信息生成代码片段，并且在第一参与者处于自动发现过程中的情况下，将与该第一参与者对应的代码片段进行组装，形成与该第一参与者对应的SPDP信息和/或SEDP信息，该第一参与者为所述参与者中的一个或多个。
在本申请上述实施方式中，代码生成模块将与每个参与者各自对应的SPDP信息和/或SEDP信息事先生成代码片段，在运行时再现组装，这种方式可减少内存底噪，节省内存空间。
在第一方面的一种可能的实现方式中，该代码生成模块，还可用于：将获取到的该第一参与者对端的SPDP信息和/或SEDP信息存储为动态信息，其中，该动态信息为临时存储的信息。
在本申请上述实施方式中，针对第一参与者对端发送过来的SPDP信息和/或SEDP信息，则需存储为动态信息，具备可实现性。
在第一方面的一种可能的实现方式中，在第一SWC有DDS历史缓存(history cache)需求的情况下，该第一SWC通过占用内存空间满足该DDS历史缓存需求，该第一SWC为该AUTOSAR中部署的SWC中的一个。
在本申请上述实施方式中，针对有DDS历史缓存需求SWC，则允许该SWC通过占用内存空间，实现了内存空间的按需分配。
在第一方面的一种可能的实现方式中，在第一SWC没有DDS历史缓存(history cache)需求的情况下，则该第一SWC通过使用栈空间占用内存空间。
在本申请上述实施方式中，针对没有DDS历史缓存需求SWC，则直接通过使用栈空间占用内存空间，具备灵活性。
本申请实施例第二方面还提供一种基于AUTOSAR实现DDS通信的方法，该方法应用于系统架构，该系统架构包括至少一个第一集成模块、DDS架构、AUTOSAR，其中，第一集成模块构建于DDS架构内，DDS架构部署于AUTOSAR中的BSW内，AUTOSAR包括RTE以及SWC，该方法包括：首先，RTE接收由AUTOSAR中部署的目标SWC发送的目标SWC信号，其中，目标SWC信号为目标SWC向RTE发送的并用于提供给DDS架构的信号；之后，RTE根据RTE内存储的每个第一集成模块与各自对应的SWC信号之间的映射关系，确定与目标SWC信号对应的目标集成模块，其中，第一集成模块用于对消息发布者和/或消息订阅者进行管理，例如，用于管理消息发布者与消息订阅者之间的自动发现过程，又例如，在某一个或多个消息发布者与某一个或多个消息订阅者均完成配对的情况下，对该消息发布者和/或该消息订阅者中的数据进行管理，具体本申请对管理的方式不做限定；最后，RTE将目标SWC信号向目标集成模块发送，该目标集成模块再根据该目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理。
在本申请上述实施方式中，将DDS集成在CP软件架构中的BSW内，并通过第一集成模块对消息发布者和/或消息订阅者进行管理，让DDS与CP兼容，从而实现SWC对底层软件的修改无感知。
在第二方面的一种可能的实现方式中，第一集成模块可用于管理消息发布者与消息订阅者之间的自动发现过程，具体地，第一集成模块对消息发布者和/或消息订阅者进行管理的过程可以是：基于DDS架构的自动发现机制确定至少一个消息发布者与至少一个消息订阅者之间的配对状态，如，m个消息发布者与n个消息订阅者之间的配对状态；在至少一个消息发布者与至少一个消息订阅者均完成配对的情况下，如，这m个消息发布者与这n个消息订阅者均被配对上，则进一步对该至少一个消息发布者和/或该至少一个消息订阅者中的数据进行管理。
在本申请上述实施方式中，具体阐述的是第一集成模块如何管理消息订阅者与消息发 布者之间的自动发现过程，具备可实现性。
在第二方面的一种可能的实现方式中，目标集成模块根据目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理的过程可以是管理目标SWC的基于回复/请求的发送数据，具体实现方式可以是：目标集成模块根据目标SWC信号确定与目标SWC信号对应的目标消息发布者，其中，目标消息发布者为至少一个消息发布者中的一个，如m个消息发布者中的一个；之后，目标集成模块指示目标消息发布者将来自于目标SWC的第一目标数据(即目标SWC的待发送数据)向目标消息订阅者(即第一目标数据的接收端)发送，其中，目标SWC为与目标SWC信号对应的SWC，属于AUTOSAR上部署的SWC，目标消息订阅者为至少一个消息订阅者中的一个，如，n个消息订阅者中的一个。
在本申请上述实施方式中，具体阐述了目标集成模块如何管理目标SWC的基于回复/请求的发送数据，具备灵活性。
在第二方面的一种可能的实现方式中，目标集成模块还可以针对SWC基于回复/请求的接收数据对目标消息发布者和/或目标消息订阅者进行管理，具体实现方式可以是：目标集成模块接收目标消息订阅者发送的第一指令，该第一指令用于表征目标消息订阅者已获取由目标消息发布者(即数据的发送端)发送的第二目标数据，目标消息发布者为所述至少一个消息发布者中的一个，如m个消息发布者中的一个，目标消息订阅者为所述至少一个消息订阅者中的一个如，n个消息订阅者中的一个；之后，目标集成模块再基于第一指令指示RTE获取该第二目标数据，以使得目标SWC对RTE上的第二目标数据进行使用。这里需要注意的是，该第二目标数据并不会直接发送至目标SWC，而是由RTE接收，目标SWC要使用该第二目标数据时，是通过调用使用。
在本申请上述实施方式中，具体阐述的是目标集成模块如何管理目标SWC的基于回复/请求的接收数据，具备灵活性。
在第二方面的一种可能的实现方式中，目标集成模块在获取到目标消息订阅者发送的第一指令之后，可以将目标消息发布者(如，Pub3)对应的消息订阅者(如，Sub3)的标识信息进行存储，该标识信息可以是该消息订阅者的地址，也可以是与消息订阅者对应的字段，只要是可唯一识别该消息订阅者的信息都可称为本申请所述的标识信息，此处对标识信息的类型不做限定。或者，目标集成模块在获取到目标消息订阅者发送的第一指令之后，还可以将该标识信息向RTE发送，由该RTE将标识信息进行存储。
在本申请上述实施方式中，具体阐述了当目标集成模块在管理目标SWC的基于回复/请求的接收数据时，目标集成模块可以将目标消息发布者对应的消息订阅者的标识信息进行存储，或者将该标识信息发送给RTE，由RTE存储，存储标识信息的目的在于，在目标SWC反馈数据时，无需再进行配对查找，可直接确定向哪个消息订阅者反馈，减少时延。
在第二方面的一种可能的实现方式中，DDS架构的自动发现机制由嵌入在BSW中的BSW管理单元(BSW-M)内目标模块(如，DDS-SD模块)触发执行，该目标模块用于管理每个参与者(如，统一管理每个Participant行为、参数等)各自对应的SPDP消息和/或SEDP消息的交互过程，该交互过程就用于实现DDS架构的自动发现机制。
在本申请上述实施方式中，嵌入目标模块是为了解决服务发现问题，通过嵌入的目标 模块实现DDS架构的自动发现，具备可实现性。
在第二方面的一种可能的实现方式中，该方法还可以包括：系统架构将与每个参与者各自对应的SPDP信息和/或SEDP信息生成代码片段，并且在第一参与者处于自动发现过程中的情况下，将与该第一参与者对应的代码片段进行组装，形成与该第一参与者对应的SPDP信息和/或SEDP信息，该第一参与者为所述参与者中的一个或多个。
在本申请上述实施方式中，将与每个参与者各自对应的SPDP信息和/或SEDP信息事先生成代码片段，在运行时再现组装，这种方式可减少内存底噪，节省内存空间。
在第二方面的一种可能的实现方式中，该方法还可以包括：在目标SWC有DDS历史缓存(history cache)需求的情况下，确定该目标SWC通过占用内存空间满足该DDS历史缓存需求。
在本申请上述实施方式中，若该目标SWC有DDS历史缓存需求，则允许该目标SWC通过占用内存空间，实现了内存空间的按需分配。
在第二方面的一种可能的实现方式中，该方法还可以包括：在目标SWC没有DDS历史缓存(history cache)需求的情况下，确定该目标SWC通过使用栈空间占用内存空间。
在本申请上述实施方式中，若该目标SWC没有DDS历史缓存需求，则该目标SWC直接通过使用栈空间占用内存空间，具备灵活性。
本申请实施例第三方面还提供一种基于AUTOSAR实现DDS通信的方法，该方法包括：在网络配置工具中，已有关于使用SOME/IP通信的一些配置参数，可直接按原来的方式(即SOME/IP的设计方式)进行网络参数配置，生成第一配置文件。具体地，基于SOME/IP的设计方式，通过网络设计工具进行网络参数配置，生成第一配置文件；在第一配置文件中未自定义DDS相关参数配置的情况下，则可通过配置转换工具在第一配置文件中自动填充DDS的默认配置，得到填充后的第一配置文件。之后，通过配置转换工具将填充后的第一配置文件转换为DDS可识别的第二配置文件。也就是说，配置转换工具是将SOME/IP相关配置转成DDS相关配置，其中，会将SOME/IP的Event、Method、Field的相关参数对应转化成DDS的服务集成参数、Participant参数等，将CP的Port/信号等参数转换成DDS Pub/Sub/Topic等相关参数，将各类服务化的ID转成DDS的Topic Name以及服务发现相关QoS等参数。在配置转换工具中，还会考虑网络配置工具和AUTOSAR配置工具中所含的DDS相关补充配置，这里存储了多种默认配置(已事先配置好)，并根据网络配置工具中的配置，自动化的填充默认的补充配置，其中填充的参数项可包含运行时的DDS QoS参数、RTE中SWC信号与DDS的映射关系等。最后，再通过AUTOSAR配置工具在第二配置文件中自动补齐与DDS相关的ECU的参数配置，得到补齐后的第二配置文件，并根据补齐后的第二配置文件生成BSW代码。需要注意的是，AUTOSAR配置工具中，将会有一些DDS相关补充配置，以及RTE对接DDS补充规则和BSW的补充规则，对于高级开发者，也可进行定制化的修改。该BSW代码用于实现上述第一方面或第一方面任意一种可能实现方式的方法的功能。
在本申请上述实施方式中，具体阐述了如何通过一系列工具生成BSW代码，这一系列工具集成了DDS相关的补充配置参数，使得生成的BSW代码就可用于实现上述第二方面 或第二方面任意一种可能实现方式的方法的功能，具备可实现性。
在第三方面的一种可能的实现方式中，该方法还包括：通过SWC建模工具对SWC的功能进行设计，并生成SWC代码。
在本申请上述实施方式中，除了需要通过网络配置工具、配置转换工具以及AUTOSAR配置工具生成对应的BSW代码外，还需要生成SWC代码，具备完备性。
在第三方面的一种可能的实现方式中，该方法还包括：将该BSW代码与该SWC代码部署于ECU上运行，其中，该ECU上部署多协议互通装置(Gateway)，该Gateway用于实现SOME/IP与DDS之间的互通。
在本申请上述实施方式中，具体阐述了生成的BSW代码与SWC代码部署在ECU上进行运行，并且通过部署Gateway，以实现不同协议之间的互通。
在第三方面的一种可能的实现方式中，Gateway通过在其中运行一个实例监听外部所有应用的发送端口，对服务发现消息、用户消息进行消息的运行控制以及消息的转发，具体地，该Gateway包括消息转换模块以及消息控制模块；该消息转换模块用于对接收到的消息进行SOME/IP与DDS之间的消息格式转换；该消息控制模块用于根据该消息承载的内容进行SOME/IP与DDS之间消息收发流程的转换。
在本申请上述实施方式中，具体阐述了Gateway如何实现SOME/IP与DDS之间的互通，本申请实施例提供的Gateway有别于传统的方案，不运行两种协议的接收发送协议，而是运行一个实例，提高了系统的运行性能。
在第三方面的一种可能的实现方式中，该方法还包括：通过设计工具进行参数配置，并生成第三配置文件；根据该第三配置文件生成目标代码，该目标代码用于实现该Gateway的功能。
在本申请上述实施方式中，具体阐述了Gateway也可通过对应设计工具进行自动代码的生成，具备灵活性。
本申请实施例第四方面提供一种计算机设备，该计算机设备具有实现上述第二方面或第二方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第五方面提供一种工具系统，该工具系统具有实现上述第三方面或第三方面任意一种可能实现方式的方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
本申请实施例第六方面提供一种计算机设备，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第二方面或第二方面任意一种可能实现方式的方法。
本申请实施例第七方面提供一种工具系统，可以包括存储器、处理器以及总线系统，其中，存储器用于存储程序，处理器用于调用该存储器中存储的程序以执行本申请实施例第三方面或第三方面任意一种可能实现方式的方法。
本申请实施例第八方面提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机可以执行上述第二方面或第二方面任意一种 可能实现方式的方法，或，使得计算机可以执行上述第三方面或第三方面任意一种可能实现方式的方法。
本申请实施例第九方面提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述第二方面或第二方面任意一种可能实现方式的方法，或，使得计算机可以执行上述第三方面或第三方面任意一种可能实现方式的方法。
本申请实施例第十方面提供了一种芯片，该芯片包括至少一个处理器和至少一个接口电路，该接口电路和该处理器耦合，至少一个接口电路用于执行收发功能，并将指令发送给至少一个处理器，至少一个处理器用于运行计算机程序或指令，其具有实现如上述第二方面或第二方面任意一种可能实现方式的方法的功能，或，其具有实现如上述第三方面或第三方面任意一种可能实现方式的方法的功能，该功能可以通过硬件实现，也可以通过软件实现，还可以通过硬件和软件组合实现，该硬件或软件包括一个或多个与上述功能相对应的模块。
附图说明
图1为本申请实施例提供的一个服务化应用的示例；
图2为本申请实施例提供的AUTOSAR的生态的一个示意图；
图3为本申请实施例提供的CP通信的一个示意图；
图4为本申请实施例提供的SOME/IP服务发现过程的一个示意图；
图5为本申请实施例提供的AP通信的一个示意图；
图6为本申请实施例提供的DDS订阅发布模型的一个示意图；
图7为本申请实施例提供的DDS服务自动发现过程的一个示意图；
图8为本申请实施例提供的三种服务化通信形式的示意图；
图9为本申请实施例提供的AUTOSAR现有规范在智能车服务化通信实现上存在的问题的一个示意图；
图10为基于当前技术架构的一个软件运行流程示意图；
图11为在CDD中集成DDS实现兼容的一个示意图；
图12为CDD实现方案的设计和运行流程示意图；
图13为本申请实施例提供的系统的整体架构的一个示意图；
图14为本申请实施例提供的系统架构的一个示意图；
图15为本申请实施例提供的基于AUTOSAR实现DDS通信的方法的一个流程示意图；
图16为本申请实施例提供的将DDS集成进CP的BSW模块的一个示意图；
图17为本申请实施例提供的将DDS集成进CP的BSW模块的另一示意图；
图18为本申请实施例提供的为减少内存底噪的运行时方案的一个示意图；
图19为本申请实施例提供的基于AUTOSAR实现DDS通信的方法的一个流程示意图；
图20为本申请实施例提供的生成BSW代码以及SWC代码的过程的一个流程示意图；
图21为本申请实施例提供的Gateway实现方案的一个流程示意图；
图22为本申请实施例代码生成和代码运行的一个流程示意图；
图23为本申请实施例提供的生成BSW代码以及SWC代码的过程的另一流程示意图；
图24为本申请实施例提供的一种工具系统的结构示意图；
图25是本申请实施例提供的设备一种结构示意图。
具体实施方式
本申请实施例提供了一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备，用于将DDS集成在CP软件架构中的BSW内，让DDS与CP兼容，做到SWC对底层软件的修改无感知。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。
本申请实施例涉及了许多关于CP、AP的相关知识，为了更好地理解本申请实施例的方案，下面先对本申请实施例可能涉及的相关术语和概念进行介绍，具体请参阅表1。应理解的是，相关的概念解释可能会因为本申请实施例的具体情况有所限制，但并不代表本申请仅能局限于该具体情况，在不同实施例的具体情况可能也会存在差异，具体此处不做限定。
表1、相关术语和概念介绍
Figure PCTCN2022087550-appb-000001
Figure PCTCN2022087550-appb-000002
Figure PCTCN2022087550-appb-000003
智能化的演进让软件在智能车的重要性有了巨大的提升，催生出了“软件定义汽车”的概念，相应地，也对SOA这个原本在IT领域中的概念有了强烈的需求，成为了当前汽车行业十分热门的话题。它要求汽车软件以一种“服务的”思想进行架构设计。也就是将车内软件、硬件所能提供的能力(如传感器数据、执行器功能)，以服务的形式提供出来，智能车上的高级功能软件，请求这些服务，将所获取的信息，用于高级功能的实现(如，路径规划功能)，或请求执行器执行某个动作(如，远光灯控制)。这种架构将有助于做到松耦合的服务架构，每个服务或功能模块，互不干涉，也可更加容易地将功能迁移至不同的硬件、软件平台上，方便独立开发。
为便于理解，可参阅图1，图1为本申请实施例提供的一个服务化应用的示例，自动驾驶路径规划功能、远光灯自动控制功能为在AP架构下部署的用户可感知的高级功能，这些功能需要各项服务提供数据和控制能力，每个服务可能来自于一个ECU提供的简单能力，也可能来自于AP设备(即部署AP的设备，一般为大算力的CPU单板)上提供的诸如地图服务、GPS服务等复杂能力。这些服务通过服务化通信中间件(service middleware)，与所述的高级功能互相沟通，最终达成功能的实现。
由于汽车电子电器架构中CP和AP共存的现状，以及越来越热门的服务化需求，早先为传统汽车制定的CP规范已经无法完全适应当前车辆电子服务化架构的需求。其中包括了CP和AP统一服务化通信的问题，本发明将就此问题进行解决。
在介绍本申请实施例提供的基于AUTOSAR实现DDS通信的方法之前，首先对CP生态进行介绍，然后介绍AP和CP中使用的通信协议，最后指出当前CP和AP规范，在实现服务化所面临的问题。
首先，对CP生态进行介绍，具体请参阅图2，图2为本申请实施例提供的AUTOSAR的生态的一个示意图，其中包含了软件架构和工具形态，该软件架构中最上层为应用层 (Application Layer)，应用层部署了若干个SWC，每个SWC用于实现对应的具体功能。SWC的运行，需要RTE提供运行时环境，它实现了内部SWC之间的通信以及SWC和BSW之间的信号连接和调度连接。BSW被称为基础软件层，为上层软件SWC提供各项基础能力，如，通信能力、内存管理能力、硬件抽象、驱动等。SWC实现以太网络的通信，需要与RTE进行交互，RTE将信号交给BSW进行信号的处理，最终交给网络协议栈向外发送。信号接收则是与前述相反的过程，此处不予赘述。此外，CDD层用来存放CP规范之外的功能模块。也就是说，对于软件中所需但AUTOSAR协议没有规定的能力，可以将开发好的功能，放入CDD中，对应用暴露调用接口。
工具是伴随AUTOSAR软件栈配套发布的一组工具软件，AUTOSAR的使用方式与传统基础软件使用方式相异。传统基础软件(如，操作系统)为厂商发布软件，用户下载安装，然后用户编写应用代码，调用基础软件的各项能力，最终将软件部署在技术软件上运行。但是AUTOSAR由于运行在不同的硬件设备上，车上每个ECU，可能实现不同的功能，使用不同的硬件能力、软件能力、通信能力，每个应用实现功能不同，所以AUTOSAR是一个高度定制化的软件架构。开发AUTOSAR的企业，会给出配套的工具。用户通过工具，进行AUTOSAR内部参数的配置以及应用的设计，然后工具生成应用和AUTOSAR基础软件的代码，生成的代码再部署到ECU上运行。其中可以完全不用手写代码，或者在开发应用时，仅需要手写一些不常见的功能实现逻辑。
AUTOSAR的工具大体可分为SWC建模工具和AUTOSAR配置工具两类，其中，SWC建模工具用于对应用进行框架建模、行为建模，最后生成SWC代码；AUTOSAR配置工具用于对各层的参数、行为进行配置(如，通信参数配置、RTE参数配置、调度参数配置等多项配置)，最终生成AUTOSAR基础代码，可称为BSW代码。两类代码结合，再加上一些静态的基础AUTOSAR代码，即可使得ECU功能运行起来。
接下来对CP的通信协议进行介绍，请参阅图3，图3为本申请实施例提供的CP通信的一个示意图，CP以太网通信规定使用SOME/IP协议，图3中粗虚线框包围的部分为SOME/IP子模块及所涉及的CP模块，在CP的规范中，以太网的通信使用SOME/IP协议，SOME/IP依赖RTE、BSW内部的COM模块(一般是LDCOM)/PduR模块/SoAd模块实现网络协议栈的对接、服务ID的查找和数据收发逻辑的控制。对于服务发现(也就是SOME/IP Server(即SOMEIP应用作为server)和SOME/IP Client(即SOME/IP应用作为client)互相找到对方或确认对方的在线状态，从而开始提供服务和请求服务)，在BSW-M(Manager)中进行服务发现的功能的控制。图4为本申请实施例提供的SOME/IP服务发现过程的一个示意图，经过图4中所示的过程，Server和Client建立起连接，可以开始服务通信过程。
下面对AP的通信协议进行介绍，请参阅图5，AP是一种基于POSIX接口的基础软件架构，其内部提供各种功能模块，供上层应用使用，如图5所示，其中ARA：：COM模块提供通信服务能力。规范规定以太通信使用SOME/IP和DDS通信中间件，在AP设备中，SOME/IP和DDS是兼容的。ARA：：COM基于中间件本身的自动发现、数据通信能力，包装成服务发现的能力，并进行服务化通信的管控。
DDS是对象管理组织(object management group，OMG)在HLA及CORBA等标准的基础上制定的新一代分布式实时通信中间件技术规范。DDS采用发布/订阅体系架构，强调以数据为中心，提供丰富的QoS服务质量策略，能保障数据进行实时、可靠、灵活地分发，可满足各种分布式实时通信应用需求。如图6所示，图6为本申请实施例提供的DDS订阅发布模型的一个示意图，该DDS订阅发布模式展示了DDS的运行逻辑架构(DDS是一套架构标准，参与者Participant可以认为是一个应用，该应用Participant需要按照DDS的标准运行)。DDS最外层的运行实体被称为参与者(Participant)。其内可部署一个、多个消息发布者(Publisher，Pub)和消息订阅者(Subscriber，Sub)，其中，Publisher和Subscriber是代码逻辑，可看作是Participant应用中的数据发送模块和数据接收模块。部署几个Publisher和Subscriber在网络设计工具阶段定义好。Publisher的Data Writer与Subscriber的Data Reader通过相同的主题名称Topic Name和相兼容的QoS进行配对，从而消息发布者可以向匹配的消息订阅者发送消息。消息发布者、消息订阅者可以有一个或多个Data Writer、Data Reader。每个消息发布者的不同Data Writer不限制其Topic Name或QoS必须一致，这给消息通信带来了极大的灵活性。
需要说明的是，每一个Data Writer或Data Reader，都有其自己的历史缓存(History Cache)，对于Data Writer，History Cache用来缓存需要发送的数据；对于Data Reader，History Cache用来缓存已接收到的数据。DDS数据传输的本质，就是收/发两端History Cache之间的信息传输。
图7为本申请实施例提供的DDS服务自动发现过程的一个示意图，首先收发SPDP数据包进行Participant之间的配对，然后配对的Participant之间收发SEDP数据包，将Participant内部的实体(即Publisher或Subscriber)进行配置对，配对的Data Writer和Data Reader即可进行数据的发送和接收。其中，图7中的Node A和Node B是两个DDS的运行实例，也就是两个基于DDS的Participant。
由此可见，SOMEIP和DDS节点配对方式迥异，在数据收发上，DDS还多出各种QoS能力，并依赖History Cache。
CP和AP规范相同的服务化通信形式，具体如图8所示，图8为本申请实施例提供的三种服务化通信形式的示意图。其中，Method方式是Client向Server发送请求消息(Request)，Server根据请求生成回复信息(Response)，并将回复消息发送给Client；Event方式中，Server会定期/不定期地将当前数据发送给Client；Field方式可认为是Event和Method的结合(即2选1的方式)，用于获取数据或设置参数。
CP规范只规定使用SOME/IP进行通信，而AP中可以使用DDS和SOME/IP。如果让一些接入小型器件的ECU为载有AP的域计算节点提供服务化能力，那只能为AP中使用SOME/IP通信的应用来提供。对于使用DDS的应用，则无法使用ECU提供的服务。由于DDS能提供多达20多种的QoS能力，实现可靠性多播数据发送，支持大包发送，操作系统内进程间通信和跨核通信，DDS相比SOME/IP能够满足各种不同的通信需求。因而越来越多的车厂有使用DDS的强烈诉求，这就出现了CP与AP服务化互通的障碍，具体可如图9中的线段1所示，图9为本申请实施例提供的AUTOSAR现有规范在智能车服务化通 信实现上存在的问题的一个示意图。如果CP设备接入了一个CAN通信的传感器，传感数据通过CP的CAN处理路径向上交给SWC，由SWC进行服务化转换，于是经过CP内的SOME/IP通路，将服务化数据传递出去，这种方式，只能与对端使用SOMEIP的应用进行通信，而不能与DDS应用互通。2)紫线。若接入一个第三方开发的设备，其对应的SWC也是基于SOME/IP标准进行开发的，与对端的通信，也存在AP中使用DDS的应用无法兼容的问题。此外，如果车厂还使用了第三方器件(如图9中的3 rd设备SWC)接入到AUTOSAR中，由于第三方器件也是严格按照CP规范设计，其对应的SWC也是基于SOME/IP标准进行开发的，用户无法对其修改，这时使用DDS的应用与第三方设备互通时也会存在问题，具体可如图9中的线段2所示。
由于DDS本身是以数据为中心的架构思想，也就是DDS向外提供的是数据收发的能力，而服务化要求基础软件要提供服务化通信的能力(当前CP设备是通过SOME/IP、AP设备是通过ARA::COM结合中间件提供此能力)，如何在CP中将DDS的以数据为中心的能力转换为以服务为中心的能力，也是本申请要解决的技术问题。
如前面所述，图2展示了CP的软件架构和工具生态。图9给出了CP基于现有SOME/IP规范与AP服务化互通的路径。基于当前技术架构，图10给出了具体的工具设计和软件运行流程。
在设计阶段，开发者进行通信网络的设计，这时候开发者需要考虑网络拓扑、网络地址分配等基础参数，此外还需考虑SOME/IP服务通信相关的各项参数的设计，如各类服务化的ID。由网络配置工具配置完成后生成配置文件导入到AUTOSAR配置工具(也可称为ECU配置工具，在本申请实施例中，统称为AUTOSAR配置工具，以下不予赘述)中，网络设计中的各项参数，也会在此AUTOSAR配置工具中体现，对应于RTE和BSW的相关参数。然后开发者在该工具中可继续进行其他参数的配置。最终生成AUTOSAR运行代码(即基础软件的代码，由AUTOSAR配置工具生成)。下一步，开发者使用SWC建模工具，对SWC的功能进行设计，然后生成SWC代码(即应用软件的代码，由SWC建模工具生成)。需说明的是，SWC建模也可以与前面的工作并行进行，或在最开始进行(后文的流程也可以这样，不再赘述)。
在运行阶段，这里以服务化数据发送为例，SWC将信号传递给RTE，RTE交给BSW层的各模块，SOME/IP内部各功能结合COM和PDU-R模块，将应用层的信号，转成服务化的形式，通过SoAd发送出去。服务化数据接收为相反过程。需要注意的是，CP设备通过SWC获取到的数据都是服务化的数据。
现有CP规范可满足CP与使用SOME/IP的AP应用或CP应用进行服务化通信。但是，正如前面所提的，其无法满足CP与使用DDS的AP或CP应用进行服务化通信。
为解决CP应用能与使用DDS的AP或CP应用进行服务化通信的问题，一种解决的方式如图11所示，如前面所述CDD用于承载CP规范之外的功能模块，为应用层提供调用接口，该方式将DDS的基本功能实现于CDD中，对于供应商来说，这种实现起来比较方便，但是却把更多繁杂的工作交给SWC开发者，无法使用对用户友好的工具开发模式，同时也没有做到与AP的服务化通信能力。如图12所示，图12为CDD实现方案的设计和 运行流程(灰色框表示与图10的规范方案的步骤差异)。由于DDS的加入，在网络设计中，需要额外为DDS的功能分配诸如Socket ID、IP地址等网络参数。AUTOSAR配置中的过程则与图10中的基本一致。对于SWC的设计，该方案打破了传统CP使用工具进行自动开发的习惯，需要开发人员手动增加和修改很多代码，来使用DDS的各种接口。开发人员需要书写SWC代码时需考虑的操作包括但不限于如下内容：1)DDS各个实例的创建，也包含各种参数的输入；2)DDS自动发现接口调用，及其流程的管控；3)数据发送、接收接口调用，运行任务的手动分配；4)序列化、反序列化代码的编写，及其调用。此外，在运行阶段，SWC只能进行数据的收发，而非服务的请求和提供，SWC直接调用DDS接口，依赖CDD内部的DDS协议实现，进行DDS的初始化、自动发现、数据收发和数据的序列化/反序列化，最后通过以太网发送出去(接收是相反的过程)。这种方式，只能与另外一个CP设备的使用DDS的应用进行数据的收发，而非服务化通信。
由上述内容可知，这种实现方案已经打破了传统CP使用工具自动开发与生成代码的习惯，对于开发人员的知识储备有非常强的要求，开发者要掌握DDS如何使用，以及其内部的通信原理以识别网络参数需求，而且也给开发者增加了大量的工作量。也就是说对于DDS提供商来说，实现简便，但是把复杂的工作全都交给了AUTOSAR的用户。此外这种方式只能实现数据的收发，没有实现服务化，因而只能以数据的形式同其他ECU的CP进行数据通信，图12所示的其他互通形式均无法实现。而且，这种实现方式底噪较大(>200KB)，对于嵌入式ECU设备，是难以接受的。
基于上述所述，本申请实施例目标在于实现整车内部统一的服务化通信能力，可概括为两点：1)实现CP与AP的DDS服务化互通；2)使用DDS的应用与现有传统的CP SOME/IP标准兼容，满足兼容第三方设备服务通信的能力。本申请实施例提供的方法通过结合已有规范的功能，让车内通信做到跨通信协议互通、跨域(AP与CP)互通，最终达到全车内部统一的服务化通信能力。
在介绍本申请实施例提供的基于AUTOSAR实现DDS通信的方法之前，首先介绍本申请的整体架构，具体请参阅图13，图13为本申请实施例提供的系统的整体架构的一个示意图，其中，灰底框为与现有系统架构不同的地方，主要为：1)本申请将DDS功能实现在BSW层中，与SOME/IP的路径并行，并做到向上兼容RTE，向下对接TCP/IP，做薄整个协议栈实现，尽可能的减少软件流程，降低传输时延。同时实现服务化能力。2)在设备中部署多协议互通Gateway，以实现不同通信协议(即SOME/IP协议与DDS协议)之间的互通。此外，在工具链(也可称为工具系统)中，将原有工具链进行功能的增加，使得工具支持DDS。
下面基于图13所述的整体架构，对本申请实施例提供的系统架构进行详细阐述，具体请参阅图14，图14为本申请实施提供的系统架构的一个示意图，该系统架构包括：至少一个第一集成模块1401、DDS架构1402、AUTOSAR 1403，第一集成模块1401构建于DDS架构1402内，DDS架构1402部署于AUTOSAR 1403中的BSW 1404内，此外，AUTOSAR 1403还包括RTE 1405以及至少一个SWC 1406。其中，第一集成模块1401，用于对消息发布者和/或消息订阅者进行管理，例如，用于管理消息发布者与消息订阅者之间的自动发 现过程，又例如，在某一个或多个消息发布者与某一个或多个消息订阅者均完成配对的情况下，对该消息发布者和/或该消息订阅者中的数据进行管理，具体本申请对管理的方式不做限定；AUTOSAR 1403中的RTE 1405，用于存储每个第一集成模块1401与各自对应的SWC信号之间的映射关系，需要说明的是，该SWC信号为SWC 1406向RTE 1405发送的并用于提供给DDS架构1402的信号。
这里需要注意的是，该第一集成模块1401既可以构建于DDS架构1402的参与者(Participant)内，或，该第一集成模块1401为DDS架构1402中额外构建的模块。具体地，构建第一集成模块1401包括但不限于如下方式：
1)将第一集成模块1401构建于DDS架构1402的参与者(Participant)内。
在这种情况下，是在DDS架构1402的参与者(Participant)内构建第一集成模块1401，该参与者的数量为n，该第一集成模块1401的数量为m，n≥1，m≥1。如图16所示，DDS被集成进CP的BSW模块中，DDS-R(也可不进行进一步区分)实现基本的RTPS能力，向上与RTE对接，DDS-T(也可不进行进一步区分)向下与网络协议栈对接，同时集成了History Cache能力。服务集成中，将DDS的Publisher、Subscriber的逻辑关系进行管理，实现Event、Method、Field的服务发现与服务通信能力。RTE的S2S映射功能(信号向服务)，将SWC信号与DDS的服务集成对接。这样，DDS提供了服务能力，并且将传统CP定义的SWC信号与DDS服务关联起来，实现了完整的服务化通信路径。需要注意的是，在图16中，示意的是每个参与者(即Participant A至Participant N)中至少部署有一个第一集成模块，在另一些实施例中，也可以是第一集成模块的数量少于参与者的数量，即可以是一个第一集成模块至少与一个参与者(对应的第一集成模块可部署于其服务的多个参与者的任意一个)，设置是一个第一集成模块服务所有的参与者(这一个第一集成模块可部署于对应的多个参与者的任意一个)，具体此处不做限定。
2)第一集成模块1401作为单独的模块，额外构建于DDS架构1402中。
在这种情况下，是将第一集成模块1401作为额外增加的一个模块(图14中未示出)，构建于原本的DDS架构1402中。这种部署的好处在于，不用更改原本的DDS架构1402。
这里需要注意的是，由于该DDS架构1402是部署于AUTOSAR 1403中的BSW 1404内，因此，当第一集成模块1401是构建于DDS架构1402的一个或多个参与者内，那么就是将DDS架构1402中的每个参与者(即无论该参与者是否部署有第一集成模块1401)部署在AUTOSAR 1403中的BSW 1404内；又例如，当第一集成模块1401是DDS架构1402中额外构建的模块，那么就将该第一集成模块1401以及DDS架构1402中原本的每个参与者部署在AUTOSAR 1403中的BSW 1404内。
需要说明的是，在本申请的一些实施方式中，第一集成模块1401既可用于管理消息发布者与消息订阅者之间的自动发现过程，也可以用于管理在自动发现过程结束后消息发布者与消息订阅者之间的数据，下面分别进行阐述：
(1)第一集成模块1401用于管理消息发布者与消息订阅者之间的自动发现过程。
具体地，实现方式可以是第一集成模块1401具体用于：基于DDS架构1402的自动发现机制确定至少一个消息发布者与至少一个消息订阅者之间的配对状态，如，m个消息发 布者与n个消息订阅者之间的配对状态；在至少一个消息发布者与至少一个消息订阅者均完成配对的情况下，如，这m个消息发布者与这n个消息订阅者均被配对上，则进一步对该至少一个消息发布者和/或该至少一个消息订阅者中的数据进行管理。
(2)第一集成模块1401用于管理在自动发现过程结束后消息发布者与消息订阅者之间的数据。
具体地，针对SWC基于回复/请求的发送数据，实现方式可以是第一集成模块1401具体用于：首先，从RTE 1405获取目标SWC信号，再根据该目标SWC信号确定与目标SWC信号对应的目标消息发布者，其中，目标消息发布者为至少一个消息发布者中的一个，如m个消息发布者中的一个；之后，指示目标消息发布者将来自于目标SWC的第一目标数据(即目标SWC的待发送数据)向目标消息订阅者(即第一目标数据的接收端)发送，其中，目标SWC为与目标SWC信号对应的SWC，属于AUTOSAR 1403上部署的SWC，目标消息订阅者为至少一个消息订阅者中的一个，如，n个消息订阅者中的一个。
针对SWC基于回复/请求的接收数据，实现方式可以是第一集成模块1401具体还用于：接收目标消息订阅者发送的第一指令，该第一指令用于表征目标消息订阅者已获取由目标消息发布者(即数据的发送端)发送的第二目标数据，目标消息发布者为所述至少一个消息发布者中的一个，如m个消息发布者中的一个，目标消息订阅者为所述至少一个消息订阅者中的一个如，n个消息订阅者中的一个；之后，再基于第一指令指示RTE 1405获取该第二目标数据，以使得目标SWC对RTE 1405上的第二目标数据进行使用。这里需要注意的是，该第二目标数据并不会直接发送至目标SWC，而是由RTE 1405接收，目标SWC要使用该第二目标数据时，是通过调用使用。
还需要说明的是，在本申请的一些实施方式中，第一集成模块1401还可用于：在获取到目标消息订阅者发送的第一指令之后，将目标消息发布者(如，Pub3)对应的消息订阅者(如，Sub3)的标识信息进行存储，该标识信息可以是该消息订阅者的地址，也可以是与消息订阅者对应的字段，只要是可唯一识别该消息订阅者的信息都可称为本申请所述的标识信息，此处对标识信息的类型不做限定。或者，该第一集成模块1401也可用于：将该标识信息向RTE 1405发送，由该RTE 1405将标识信息进行存储。
还需要说明的是，在本申请的一些实施方式中，为了解决服务发现问题，还可以进一步制作目标模块，并将该目标模块嵌入到BSW1404中的BSW-M中(图14中未示意出)，该目标模块用于管理每个参与者(如，统一管理每个Participant行为、参数等)各自对应的简单参与者发现协议(simple participant discovery protocol，SPDP)消息和/或简单端节点发现协议(simple endpoint discovery protocol，SEDP)消息的交互过程，其中，该交互过程用于实现DDS架构1402的自动发现机制。如图17所示，该目标模块为DDS-SD模块，该DDS-SD模块嵌入到BSW-M中，供BSW-M周期性调用或触发调用。
还需要说明的是，在本申请的另一些实施方式中，为了减少内存底噪，该系统架构还可以包括：代码生成模块(图14中未示意出)，用于将与每个参与者各自对应的SPDP信息和/或SEDP信息事先生成代码片段，之后，在第一参与者处于自动发现过程中的情况下，将与该第一参与者对应的代码片段进行组装，形成与该第一参与者对应的SPDP信息和/或 SEDP信息，该第一参与者为所述参与者中的一个或多个。为便于理解，下面举例进行说明，请参阅图18，图18为本申请实施例提供的为减少内存底噪的运行时方案的一个示意图，DDS-Info包括动态生成代码存储服务消息，即AUTOSAR配置工具将服务发现所需的信息提前生成的代码，另一部分是运行时所获取的动态信息。在服务发现时，对于某些Participant(如，图18中的DDS Participant A和DDS Participant B)所需发送的SPDP消息和/或SEDP消息，将首先从代码中寻找所需信息，运行时现场组装，这样做的好处在于：CP设备一般内存较小，这样提前生成代码的方式可节约内存空间，可以避免使用大量的内存栈空间长期存储SPDP消息和/或SEDP消息。
还需要说明的是，在本申请的另一些实施方式中，DDS-Info还可以包括动态信息，也就是对于获取到的第一参与者对端的SPDP信息和/或SEDP信息将存放为动态信息中。这里需要注意的是，动态信息是参与者在服务发现时获取的对端的信息。如第一参与者与第二参与者进行服务发现，第一参与者将自己的SPDP和SEDP发送给第二参与者，这些信息对于第二参与者来讲，是服务发现阶段获取到的对端的信息，该信息可能随着对端的上下线、参数改变而改变，因此称为动态信息。
此外，在运行时，对于有DDS History Cache需求的应用(可称为第一SWC，是AUTOSAR中部署的SWC中的任意一个)，将允许该应用占用内存空间满足其DDS History Cache需求；无此DDS History Cache需求的应用，则直接使用栈空间临时占用内存。这部分的运行逻辑由工具进行代码生成。
具体地，本申请实施例提供的通信方法涉及了三部分内容：1)对CP基础软件的改造，在CP栈内集成DDS；2)对工具的改造，以融合DDS；3)对Gateway的设计，以实现不同协议的互通。下面基于这三部分内容，分别进行阐述。
一、对CP基础软件进行改造，在CP栈内集成DDS
具体请参阅图15，图15为本申请实施例提供的基于AUTOSAR实现DDS通信的方法的一个流程示意图，该方法可应用于上述图14对应的系统架构，该系统架构包括至少一个第一集成模块、DDS架构、AUTOSAR，第一集成模块构建于DDS架构内，DDS架构部署于AUTOSAR中的BSW内，AUTOSAR包括RTE以及SWC，该方法具体可以包括如下步骤：
1501、RTE接收由AUTOSAR中部署的目标SWC发送的目标SWC信号。
首先，RTE接收由AUTOSAR中部署的目标SWC发送的目标SWC信号，其中，目标SWC信号为目标SWC向RTE发送的并用于提供给DDS架构的信号。
1502、RTE根据RTE内存储的每个第一集成模块与各自对应的SWC信号之间的映射关系，确定与目标SWC信号对应的目标集成模块，第一集成模块用于对消息发布者和/或消息订阅者进行管理。
RTE在接收由AUTOSAR中部署的目标SWC发送的目标SWC信号之后，RTE根据RTE内存储的每个第一集成模块与各自对应的SWC信号之间的映射关系，确定与目标SWC信号对应的目标集成模块，其中，第一集成模块用于对消息发布者和/或消息订阅者进行管理，例如，用于管理消息发布者与消息订阅者之间的自动发现过程，又例如，在某一个或 多个消息发布者与某一个或多个消息订阅者均完成配对的情况下，对该消息发布者和/或该消息订阅者中的数据进行管理，具体本申请对管理的方式不做限定。
需要说明的是，在本申请的一些实施方式中，第一集成模块可用于管理消息发布者与消息订阅者之间的自动发现过程，实现过程可以是：基于DDS架构的自动发现机制确定至少一个消息发布者与至少一个消息订阅者之间的配对状态，如，m个消息发布者与n个消息订阅者之间的配对状态；在至少一个消息发布者与至少一个消息订阅者均完成配对的情况下，如，这m个消息发布者与这n个消息订阅者均被配对上，则进一步对该至少一个消息发布者和/或该至少一个消息订阅者中的数据进行管理。
在本申请上述实施方式中，具体阐述的是第一集成模块如何管理消息订阅者与消息发布者之间的自动发现过程，具备可实现性。
1503、RTE将目标SWC信号向目标集成模块发送。
RTE在根据RTE内存储的每个第一集成模块与各自对应的SWC信号之间的映射关系确定了与目标SWC信号对应的目标集成模块之后，会将目标SWC信号向目标集成模块发送。
1504、目标集成模块根据目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理。
目标集成模块接收到由RTE发送的目标SWC信号之后，该目标集成模块再根据该目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理。
需要说明的是，在本申请的一些实施方式中，目标集成模块根据目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理可以是管理目标SWC的基于回复/请求的发送数据，具体实现方式可以是：目标集成模块根据目标SWC信号确定与目标SWC信号对应的目标消息发布者，其中，目标消息发布者为至少一个消息发布者中的一个，如m个消息发布者中的一个；之后，目标集成模块指示目标消息发布者将来自于目标SWC的第一目标数据(即目标SWC的待发送数据)向目标消息订阅者(即第一目标数据的接收端)发送，其中，目标SWC为与目标SWC信号对应的SWC，属于AUTOSAR上部署的SWC，目标消息订阅者为至少一个消息订阅者中的一个，如，n个消息订阅者中的一个。
还需要说明的是，在本申请另一些实施方式中，目标集成模块还可以针对SWC基于回复/请求的接收数据对目标消息发布者和/或目标消息订阅者进行管理，具体实现方式可以是：目标集成模块接收目标消息订阅者发送的第一指令，该第一指令用于表征目标消息订阅者已获取由目标消息发布者(即数据的发送端)发送的第二目标数据，目标消息发布者为所述至少一个消息发布者中的一个，如m个消息发布者中的一个，目标消息订阅者为所述至少一个消息订阅者中的一个如，n个消息订阅者中的一个；之后，目标集成模块再基于第一指令指示RTE获取该第二目标数据，以使得目标SWC对RTE上的第二目标数据进行使用。这里需要注意的是，该第二目标数据并不会直接发送至目标SWC，而是由RTE接收，目标SWC要使用该第二目标数据时，是通过调用使用。
还需要说明的是，在本申请另一些实施方式中，目标集成模块在获取到目标消息订阅者发送的第一指令之后，可以将目标消息发布者(如，Pub3)对应的消息订阅者(如，Sub3) 的标识信息进行存储，该标识信息可以是该消息订阅者的地址，也可以是与消息订阅者对应的字段，只要是可唯一识别该消息订阅者的信息都可称为本申请所述的标识信息，此处对标识信息的类型不做限定。或者，目标集成模块在获取到目标消息订阅者发送的第一指令之后，还可以将该标识信息向RTE发送，由该RTE将标识信息进行存储。在本申请实施例中，具体阐述了当目标集成模块在管理目标SWC的基于回复/请求的接收数据时，目标集成模块可以将目标消息发布者对应的消息订阅者的标识信息进行存储，或者将该标识信息发送给RTE，由RTE存储，存储标识信息的目的在于，在目标SWC反馈数据时，无需再进行配对查找，可直接确定向哪个消息订阅者反馈，减少时延。
还需要说明的是，在本申请另一些实施方式中，DDS架构的自动发现机制由嵌入在BSW中的BSW管理单元(BSW-M)内目标模块(如，DDS-SD模块)触发执行，该目标模块用于管理每个参与者(如，统一管理每个Participant行为、参数等)各自对应的SPDP消息和/或SEDP消息的交互过程，该交互过程就用于实现DDS架构的自动发现机制。在本申请实施例中，嵌入目标模块是为了解决服务发现问题，通过嵌入的目标模块实现DDS架构的自动发现，具备可实现性。
还需要说明的是，在本申请另一些实施方式中，在运行时，若该目标SWC有DDS History Cache需求，则允许该目标SWC通过占用内存空间满足其DDS History Cache需求；若该目标SWC无此DDS History Cache需求，则允许该目标SWC直接使用栈空间临时占用内存。这部分的运行逻辑由工具进行代码生成。
二、对工具进行改造，以融合DDS
具体请参阅图19，图19为本申请实施例提供的基于AUTOSAR实现DDS通信的方法的一个流程示意图，该方法具体可以包括如下步骤：
1901、基于SOME/IP的设计方式，通过网络设计工具进行网络参数配置，生成第一配置文件。
在网络配置工具中，已有关于使用SOME/IP通信的一些配置参数，可直接按原来的方式(即SOME/IP的设计方式)进行网络参数配置，生成第一配置文件。需要注意的是，在本申请的一些实施例中，该网络设计工具还额外提供了DDS相关补充配置，了解DDS的开发者可进行定制化的网络设计。该网络设计工具最终将生成第一配置文件，供配置转换工具继续设计。
需要注意的是，相比于现有的网络配置工具，本申请实施例所述的网络配置工具增加了DDS相关补充配置的可选项。
1902、在第一配置文件中未自定义DDS相关参数配置的情况下，通过配置转换工具在第一配置文件中自动填充DDS的默认配置，得到填充后的第一配置文件。
在第一配置文件中未自定义DDS相关参数配置的情况下，则可通过配置转换工具在第一配置文件中自动填充DDS的默认配置，得到填充后的第一配置文件。
1903、通过配置转换工具将填充后的第一配置文件转换为DDS可识别的第二配置文件。
之后，通过配置转换工具将填充后的第一配置文件转换为DDS可识别的第二配置文 件。也就是说，配置转换工具是将SOME/IP相关配置转成DDS相关配置，其中，会将SOME/IP的Event、Method、Field的相关参数对应转化成DDS的服务集成参数、Participant参数等，将CP的Port/信号等参数转换成DDS Pub/Sub/Topic等相关参数，将各类服务化的ID转成DDS的Topic Name以及服务发现相关QoS等参数。在配置转换工具中，还会考虑网络配置工具和AUTOSAR配置工具中所含的DDS相关补充配置，这里存储了多种默认配置(已事先配置好)，并根据网络配置工具中的配置，自动化的填充默认的补充配置，其中填充的参数项可包含运行时的DDS QoS参数、RTE中SWC信号与DDS的映射关系等。
需要注意的是，该配置转换工具是本申请实施例首次提出来的，用于SOME/IP相关配置转成DDS相关配置，并自动填充DDS的默认配置，已有方案中不存在该配置转换工具。
1904、通过AUTOSAR配置工具在第二配置文件中自动补齐与DDS相关的电子控制单元(ECU)的参数配置，得到补齐后的第二配置文件，并根据补齐后的第二配置文件生成BSW代码。
最后，再通过AUTOSAR配置工具在第二配置文件中自动补齐与DDS相关的ECU的参数配置，得到补齐后的第二配置文件，并根据补齐后的第二配置文件生成BSW代码。需要注意的是，AUTOSAR配置工具中，将会有一些DDS相关补充配置，以及RTE对接DDS补充规则和BSW的补充规则，对于高级开发者，也可进行定制化的修改。
需要说明的是，在本申请实施例中，BSW代码就是用于实现上述图15对应实施例所述的通信方法。
还需要说明的是，除了需要通过网络配置工具、配置转换工具以及AUTOSAR配置工具生成对应的BSW代码外，还需要生成SWC代码，具体地，可通过SWC建模工具对SWC的功能进行设计，并生成SWC代码。这里需要注意的是，生成BSW代码与生成SWC代码的过程可以并行执行，也可以先通过网络配置工具、配置转换工具以及AUTOSAR配置工具生成对应的BSW代码，再通过SWC建模工具生成SWC代码，还可以先通过SWC建模工具生成SWC代码，再通过网络配置工具、配置转换工具以及AUTOSAR配置工具生成对应的BSW代码，具体本申请对此不做限定。上述生成BSW代码以及SWC代码的过程具体可参阅图20所示过程。
还需要说明的是，在本申请的一些实施方式中，BSW代码和SWC代码生成后，就可将该BSW代码与所述SWC代码部署于ECU上运行，其中，该ECU上部署多协议互通装置(Gateway)，该Gateway用于实现SOME/IP与DDS之间的互通。Gateway如何实现SOME/IP与DDS之间的互通将在下面第三部分阐述。
三、对Gateway进行设计，以实现多协议互通
对于Gateway，传统的Gateway会分别运行两种协议的接收/发送实例，外部的收发节点与Gateway中的实例通信，Gateway中的两个实例通过中间的转换装置将消息进行格式转换与传递。这种方式将会使得系统内部运行了大量的实例，严重影响系统的运行性能。而本申请实施例提供的Gateway有别于传统的方案，不运行两种协议的接收发送协议，而是运行一个实例，其监听外部所有应用的发送端口，对服务发现消息、用户消息进行消息的运行控制以及消息的转发。该Gateway包括消息转换模块以及消息控制模块，其中，消 息转换模块用于对接收到的消息进行SOME/IP与DDS之间的消息格式转换；消息控制模块用于根据消息承载的内容进行SOME/IP与DDS之间消息收发流程的转换。
需要说明的是，在本申请的一些实施方式中，该Gateway的功能也是可以基于配置工具生成对应的代码实现的，具体地，可以通过设计工具进行参数配置，并生成第三配置文件，之后根据该第三配置文件生成目标代码，该目标代码用于实现所述Gateway的功能。
为便于理解，可参阅图21，图21为本申请实施例提供的Gateway实现方案的一个流程示意图，Gateway中有传统的消息转换逻辑，对接收到的消息(Payload)进行格式转换，转换为另一种协议的消息格式并进行转发。消息控制逻辑将会解决SOME/IP和DDS两种不同的消息收发流程不同的问题，对其消息的收发顺序、时间进行控制，让每个协议上的应用不感知与之通信的对端实例是不同的通信协议。例如，SOME/IP服务发现消息包含了发现服务(Find Service)、提供服务(Offer Service)、订阅(Subscribe)，订阅确定消息(Subscribe ACK)等消息，其运行顺序如前图4对应实施例所述，DDS的自动发现消息有SPDP消息和SEDP消息，其运行顺序也如前图4对应实施例所述。消息控制逻辑将会根据每个消息所传递的内容，以及协议在每个阶段所需内容，对消息进行解析、整合、拆分，最终组合成对端协议可识别的发现消息。此外，DDS还有一些控制类的消息，消息控制逻辑也对这些消息进行控制。由于DDS的QoS机制对消息缓存有需求，因而在Gateway中增加缓存能力，兼容DDS的缓存运行功能。对于设计工具来讲，将会增加Gateway规则的配置能力以及代码自动生成。
下面从整个设计阶段和运行阶段对本申请实施例提供的基于AUTOSAR实现DDS通信的方法以及基于AUTOSAR实现DDS通信的软件代码生成方法进行说明，具体请参阅图22，图22为本申请实施例代码生成和代码运行的一个流程示意图，其中灰底流程框表示与CP标准规范存在差异。
(1)设计阶段
网络设计时，对于开发人员，可以用原有的基于SOME/IP的设计方式进行参数配置，开发者无需关注DDS的功能。由网络配置工具生成配置文件后，交给配置转换工具(配置转换工具是本申请首次提出来的)将网络配置工具生成的配置文件转换为DDS可识别的配置文件)，再将生成的配置文件交给AUTOSAR配置工具做进一步处理。其中，在一些实施方式中，配置转换工具会对网络设计工具中未覆盖的DDS相关参数进行配置的补齐，也会对AUTOSAR配置工具中未覆盖的DDS相关的ECU参数进行配置的补齐。配置转换工具存储了一系列的默认配置(即一开始就设计好的)，它根据网络设计工具中配置的通信模式，选择合适的默认配置进行补齐。这样开发人员无需懂DDS，只需按照原有的方式进行设计。网络配置工具、配置转换工具、AUTOSAR配置工具是用来生成底层软件代码的；SWC配置工具是用来生成SWC代码的，生成好的SWC代码会根据自身需求决定走底层代码的DDS通道还是原来的SOMEIP通道(即自行匹配)。图22中的SWC建模工具进行与代码生成过程每次只生成一个SWC对应的SWC代码，上面的底层软件代码(即BSW代码)则是一次性生成。
可选地，如果开发人员对DDS有一定的了解，则可以在网络设计工具中，对DDS所 需的参数进行配置，然后再由配置转换工具一起转换成AUTOSAR配置工具的输入配置文件，开发人员在AUTOSAR配置工具中对DDS相关的ECU参数配置再进行定制化的修改。
SWC建模工具进行建模与代码生成阶段与传统的规范过程一致，开发人员无需特殊操作。
为了尽可能的降低基于DDS实现服务化的内存底噪，AUTOSAR配置工具在代码生成时，将DDS服务发现所需信息作为代码提前生成，这样在运行时，DDS的自动发现数据包将直接从代码中拷贝并现场组装。对于DDS的History Cache能力，AUTOSAR配置工具也是根据通信需求决定每条通信链路是否需要History Cache，从而进行代码的定制化生成。
(2)运行阶段
SWC可以直接将通信信号(即SWC信号)，传递给RTE。在BSW DDS实现中，将有模块负责服务化管理，因此RTE将SWC信号与DDS的服务化管理模块进行映射对接(RTE获取到SWC信号后，可自行判断是走DDS通道还是SOMEIP通道)。DDS直接对接网络协议栈，将数据发送出去(接收过程则与之相反)。此外BSW-M中也会进行DDS的服务发现流程的管控。
如果对端是与当前所使用的通信协议不同，则通过Gateway将两个协议进行连接，这样实现了多协议互通，满足使用DDS的设备使用第三方设备服务的能力。Gateway的内部规则，则由设计工具进行设置以及代码生成。
对于用户来说，用户首先使用工具进行各项参数的配置、生成配置文件、更改配置、生成代码(除SWC外的AUTOSAR代码)，然后对SWC设计、生成代码。所有代码一起编译成CP运行文件，编译得到的CP运行文件被部署于ECU上。同样地，Gateway的内部规则也通过设计工具进行设置，最后生成代码。用户将Gateway部署于AP或CP所在设备上，在AP以进程的方式运行，在CP以SWC的方式运行，具体如图23所示。
综上所述，本申请上述实施例方法将DDS与CP标准架构深入融合在一起，对于用户来说，SWC无需任何修改，同时实现了服务化通信能力，使得CP和AP实现完整的服务化互通，同时降低了内存底噪；在工具的使用上，无需设计人员懂DDS，而且存量的SWC和配置文件基于SOME/IP进行设计，它们都可被快速移植到新生态上来；Gateway的实现，使得新的架构也能兼容来自第三方设备提供的服务。
本申请实施例还提供一种工具系统，请参阅图24，图24为本申请实施例提供的一种工具系统的结构示意图，该工具系统2400包括：网络设计工具2401、配置转换工具2402以及AUTOSAR配置工具2403，其中，该网络设计工具2401，用于基于SOME/IP的设计方式进行网络参数配置，生成第一配置文件；该配置转换工具2402，用于在该第一配置文件中未自定义DDS相关参数配置的情况下，在该第一配置文件中自动填充该DDS的默认配置，得到填充后的第一配置文件；该配置转换工具2402，还用于将该填充后的第一配置文件转换为该DDS可识别的第二配置文件；该AUTOSAR配置工具2403，用于在该第二配置文件中自动补齐与该DDS相关的电子控制单元(ECU)的参数配置，得到补齐后的第二配置文件，并根据该补齐后的第二配置文件生成BSW代码，该BSW代码用于实现如上述图15对应实施例所述的通信方法。
在一种可能的设计中，该工具系统2400还包括SWC建模工具2404，用于对SWC的功能进行设计，并生成SWC代码。
在一种可能的设计中，该工具系统2400还包括部署模块2405，用于将该BSW代码与该SWC代码部署于ECU上运行，其中，该ECU上部署多协议互通装置(Gateway)，该Gateway用于实现SOME/IP与DDS之间的互通。
在一种可能的设计中，该工具系统2400还包括设计工具2406，用于进行参数配置，并生成第三配置文件；根据该第三配置文件生成目标代码，该目标代码用于实现该Gateway的功能。
需要说明的是，工具系统2400中各模块/单元之间的信息交互、执行过程等内容，与本申请中图19对应的方法实施例基于同一构思，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
本申请实施例还提供了一种设备，该设备可以作为计算机设备，也可以作为工具系统，具体此处不做限定。请参阅图25，图25是本申请实施例提供的设备一种结构示意图，为便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。当该设备2500作为计算机设备时，该设备2500上可以部署有图14对应实施例中所描述的模块，用于实现图14对应实施例中系统架构的功能；当该设备2500作为工具系统时，该设备2500上可以部署有图24对应实施例中所描述的模块，用于实现图24对应实施例中工具系统2400的功能。具体的，设备2500由一个或多个服务器实现，设备2500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)2522(例如，一个或一个以上中央处理器)和存储器2532，一个或一个以上存储应用程序2542或数据2544的存储介质2530(例如一个或一个以上海量存储设备)。其中，存储器2532和存储介质2530可以是短暂存储或持久存储。存储在存储介质2530的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对训练设备中的一系列指令操作。更进一步地，中央处理器2522可以设置为与存储介质2530通信，在设备2500上执行存储介质2530中的一系列指令操作。
设备2500还可以包括一个或一个以上电源2526，一个或一个以上有线或无线网络接口2550，一个或一个以上输入输出接口2558，和/或，一个或一个以上操作系统2541，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。
本申请实施例中，当设备2500作为计算机设备时，中央处理器2522用于执行图15对应实施例中的步骤。例如，中央处理器2522可以用于：首先，指示RTE接收由AUTOSAR中部署的目标SWC发送的目标SWC信号，其中，目标SWC信号为目标SWC向RTE发送的并用于提供给DDS架构的信号；之后，指示RTE根据RTE内存储的每个第一集成模块与各自对应的SWC信号之间的映射关系，确定与目标SWC信号对应的目标集成模块，其中，第一集成模块用于对消息发布者和/或消息订阅者进行管理，例如，用于管理消息发布者与消息订阅者之间的自动发现过程，又例如，在某一个或多个消息发布者与某一个或多个消息订阅者均完成配对的情况下，对该消息发布者和/或该消息订阅者中的数据进行管理，具体本申请对管理的方式不做限定；最后，指示RTE将目标SWC信号向目标集成模 块发送，再指示该目标集成模块再根据该目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理。
需要说明的是，中央处理器2522还可以用于执行与本申请中图15对应的方法实施例中的任意一个步骤，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
本申请实施例中，当设备2500作为工具系统时，中央处理器2522用于执行图19对应实施例中的步骤。例如，中央处理器2522可以用于：基于SOME/IP的设计方式，通过网络设计工具进行网络参数配置，生成第一配置文件。在第一配置文件中未自定义DDS相关参数配置的情况下，则可通过配置转换工具在第一配置文件中自动填充DDS的默认配置，得到填充后的第一配置文件。之后，通过配置转换工具将填充后的第一配置文件转换为DDS可识别的第二配置文件。也就是说，配置转换工具是将SOME/IP相关配置转成DDS相关配置，其中，会将SOME/IP的Event、Method、Field的相关参数对应转化成DDS的服务集成参数、Participant参数等，将CP的Port/信号等参数转换成DDS Pub/Sub/Topic等相关参数，将各类服务化的ID转成DDS的Topic Name以及服务发现相关QoS等参数。在配置转换工具中，还会考虑网络配置工具和AUTOSAR配置工具中所含的DDS相关补充配置，这里存储了多种默认配置(已事先配置好)，并根据网络配置工具中的配置，自动化的填充默认的补充配置，其中填充的参数项可包含运行时的DDS QoS参数、RTE中SWC信号与DDS的映射关系等。
需要说明的是，中央处理器2522还可以用于执行与本申请中图19对应的方法实施例中的任意一个步骤，具体内容可参见本申请前述所示的方法实施例中的叙述，此处不再赘述。
另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。

Claims (32)

  1. 一种基于AUTOSAR实现DDS通信的系统架构，其特征在于，包括：
    至少一个第一集成模块、数据分发服务(DDS)架构、汽车开放系统架构(AUTOSAR)，所述第一集成模块构建于所述DDS架构内，所述DDS架构部署于所述AUTOSAR中的基础软件层(BSW)内；
    所述AUTOSAR包括运行时环境(RTE)以及软件组件(SWC)；
    所述第一集成模块，用于对消息发布者和/或消息订阅者进行管理；
    所述RTE，用于存储每个第一集成模块与各自对应的软件组件(SWC)信号之间的映射关系，所述SWC信号为所述SWC向所述RTE发送的并用于提供给所述DDS架构的信号。
  2. 根据权利要求1所述的架构，其特征在于，所述第一集成模块，具体用于：
    基于所述DDS架构的自动发现机制确定至少一个消息发布者与至少一个消息订阅者之间的配对状态；
    在所述至少一个消息发布者与所述至少一个消息订阅者均完成配对的情况下，对所述至少一个消息发布者和/或所述至少一个消息订阅者中的数据进行管理。
  3. 根据权利要求2所述的架构，其特征在于，所述第一集成模块，具体还用于：
    从所述RTE获取目标SWC信号；
    根据所述目标SWC信号确定与所述目标SWC信号对应的目标消息发布者，所述目标消息发布者为所述至少一个消息发布者中的一个；
    指示所述目标消息发布者将来自于目标SWC的第一目标数据向目标消息订阅者发送，所述目标SWC为与所述目标SWC信号对应的SWC，所述目标消息订阅者为所述至少一个消息订阅者中的一个。
  4. 根据权利要求2所述的架构，其特征在于，所述第一集成模块，具体还用于：
    接收目标消息订阅者发送的第一指令，所述第一指令用于表征所述目标消息订阅者已获取由目标消息发布者发送的第二目标数据，所述目标消息发布者为所述至少一个消息发布者中的一个，所述目标消息订阅者为所述至少一个消息订阅者中的一个；
    基于所述第一指令指示所述RTE获取所述第二目标数据，以使得目标SWC对所述RTE上的所述第二目标数据进行使用。
  5. 根据权利要求4所述的架构，其特征在于，所述第一集成模块，还用于：
    在获取到所述目标消息订阅者发送的所述第一指令之后，将所述目标消息发布者对应的消息订阅者的标识信息进行存储；
    或，
    将所述标识信息向所述RTE发送，以使得所述RTE将所述标识信息存储。
  6. 根据权利要求2-5中任一项所述的架构，其特征在于，所述架构还包括：
    目标模块，所述目标模块嵌入在所述BSW中的BSW管理单元(BSW-M)内，所述目标模块用于管理每个参与者(Participant)各自对应的简单参与者发现协议(SPDP)消息和/或简单端节点发现协议(SEDP)消息的交互过程，所述交互过程用于实现所述DDS架 构的自动发现机制。
  7. 根据权利要求6所述的架构，其特征在于，所述架构还包括：
    代码生成模块，用于将与每个参与者各自对应的SPDP信息和/或SEDP信息生成代码片段；
    所述代码生成模块，还用于在第一参与者处于自动发现过程中的情况下，将与所述第一参与者对应的代码片段进行组装，形成与所述第一参与者对应的SPDP信息和/或SEDP信息，所述第一参与者为所述参与者中的一个或多个。
  8. 根据权利要求1-7中任一项所述的架构，其特征在于，
    在第一SWC有DDS历史缓存(history cache)需求的情况下，所述第一SWC通过占用内存空间满足所述DDS历史缓存需求，所述第一SWC为所述AUTOSAR中部署的SWC中的一个。
  9. 根据权利要求1-7中任一项所述的架构，其特征在于，
    在第一SWC没有DDS历史缓存(history cache)需求的情况下，所述第一SWC通过使用栈空间占用内存空间。
  10. 一种基于AUTOSAR实现DDS通信的方法，其特征在于，所述方法应用于系统架构，所述系统架构包括至少一个第一集成模块、数据分发服务(DDS)架构、汽车开放系统架构(AUTOSAR)，所述第一集成模块构建于所述DDS架构内，所述DDS架构部署于所述AUTOSAR中的基础软件层(BSW)内，所述AUTOSAR包括运行时环境(RTE)以及软件组件(SWC)，所述方法包括：
    所述RTE接收由所述AUTOSAR中部署的目标SWC发送的目标SWC信号，所述目标SWC信号为所述目标SWC向所述RTE发送的并用于提供给所述数据分发服务(DDS)架构的信号；
    所述RTE根据所述RTE内存储的每个第一集成模块与各自对应的SWC信号之间的映射关系，确定与所述目标SWC信号对应的目标集成模块，所述第一集成模块用于对消息发布者和/或消息订阅者进行管理；
    所述RTE将所述目标SWC信号向所述目标集成模块发送；
    所述目标集成模块根据所述目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理。
  11. 根据权利要求10所述的方法，其特征在于，所述对消息发布者和/或消息订阅者进行管理包括：
    基于所述DDS架构的自动发现机制确定至少一个消息发布者与至少一个消息订阅者之间的配对状态；
    在所述至少一个消息发布者与所述至少一个消息订阅者均完成配对的情况下，对所述至少一个消息发布者和/或所述至少一个消息订阅者中的数据进行管理。
  12. 根据权利要求11所述的方法，其特征在于，所述目标集成模块根据所述目标SWC信号对目标消息发布者和/或目标消息订阅者进行管理包括：
    所述目标集成模块根据所述目标SWC信号确定与所述目标SWC信号对应的目标消息 发布者，所述目标消息发布者为所述至少一个消息发布者中的一个；
    所述目标集成模块指示所述目标消息发布者将来自于所述目标SWC的第一目标数据向目标消息订阅者发送，所述目标消息订阅者为所述至少一个消息订阅者中的一个。
  13. 根据权利要求11-12中任一项所述的方法，其特征在于，所述方法还包括：
    所述目标集成模块接收目标消息订阅者发送的第一指令，所第一指令用于表征所述目标消息订阅者已获取由目标消息发布者发送的第二目标数据，所述目标消息发布者为所述至少一个消息发布者中的一个，所述目标消息订阅者为所述至少一个消息订阅者中的一个；
    所述目标集成模块基于所述第一指令指示所述RTE获取所述第二目标数据，以使得所述目标SWC对所述RTE上的所述第二目标数据进行使用。
  14. 根据权利要求13所述的方法，其特征在于，在所述目标集成模块接收目标消息订阅者发送的第一指令之后，所述方法还包括：
    所述目标集成模块将所述目标消息发布者对应的消息订阅者的标识信息进行存储；
    或，
    所述目标集成模块将所述标识信息向所述RTE发送，以使得所述RTE将所述标识信息存储。
  15. 根据权利要求11-14中任一项所述的方法，其特征在于，
    所述DDS架构的自动发现机制由嵌入在所述BSW中的BSW管理单元(BSW-M)内目标模块触发执行，所述目标模块用于管理每个参与者(Participant)各自对应的简单参与者发现协议(SPDP)消息和/或简单端节点发现协议(SEDP)消息的交互过程，所述交互过程用于实现所述DDS架构的自动发现机制。
  16. 根据权利要求15所述的方法，其特征在于，所述方法还包括：
    所述系统架构将与每个参与者各自对应的SPDP信息和/或SEDP信息生成代码片段；
    在第一参与者处于自动发现过程中的情况下，所述系统架构将与所述第一参与者对应的代码片段进行组装，形成与所述第一参与者对应的SPDP信息和/或SEDP信息，所述第一参与者为所述参与者中的一个或多个。
  17. 根据权利要求10-16中任一项所述的方法，其特征在于，所述方法还包括：
    在所述目标SWC有DDS历史缓存(history cache)需求的情况下，确定所述目标SWC通过占用内存空间满足所述DDS历史缓存需求。
  18. 根据权利要求10-16中任一项所述的方法，其特征在于，所述方法还包括：
    在所述目标SWC没有DDS历史缓存(history cache)需求的情况下，确定所述目标SWC通过使用栈空间占用内存空间。
  19. 一种基于AUTOSAR实现DDS通信的方法，其特征在于，包括：
    基于SOME/IP的设计方式，通过网络设计工具进行网络参数配置，生成第一配置文件；
    在所述第一配置文件中未自定义DDS相关参数配置的情况下，通过配置转换工具在所述第一配置文件中自动填充所述DDS的默认配置，得到填充后的第一配置文件；
    通过所述配置转换工具将所述填充后的第一配置文件转换为所述DDS可识别的第二配置文件；
    通过AUTOSAR配置工具在所述第二配置文件中自动补齐与所述DDS相关的电子控制单元(ECU)的参数配置，得到补齐后的第二配置文件，并根据所述补齐后的第二配置文件生成BSW代码，所述BSW代码用于实现如权利要求10-18中任一项所述的方法。
  20. 根据权利要求19所述的方法，其特征在于，所述方法还包括：
    通过SWC建模工具对SWC的功能进行设计，并生成SWC代码。
  21. 根据权利要求20所述的方法，其特征在于，所述方法还包括：
    将所述BSW代码与所述SWC代码部署于ECU上运行，其中，所述ECU上部署多协议互通装置(Gateway)，所述Gateway用于实现SOME/IP与DDS之间的互通。
  22. 根据权利要求21所述的方法，其特征在于，
    所述Gateway包括消息转换模块以及消息控制模块；
    所述消息转换模块用于对接收到的消息进行SOME/IP与DDS之间的消息格式转换；
    所述消息控制模块用于根据所述消息承载的内容进行SOME/IP与DDS之间消息收发流程的转换。
  23. 根据权利要求21-22中任一项所述的方法，其特征在于，所述方法还包括：
    通过设计工具进行参数配置，并生成第三配置文件；
    根据所述第三配置文件生成目标代码，所述目标代码用于实现所述Gateway的功能。
  24. 一种工具系统，其特征在于，所述工具系统包括：
    网络设计工具、配置转换工具以及AUTOSAR配置工具；
    所述网络设计工具，用于基于SOME/IP的设计方式进行网络参数配置，生成第一配置文件；
    所述配置转换工具，用于在所述第一配置文件中未自定义DDS相关参数配置的情况下，在所述第一配置文件中自动填充所述DDS的默认配置，得到填充后的第一配置文件；
    所述配置转换工具，还用于将所述填充后的第一配置文件转换为所述DDS可识别的第二配置文件；
    所述AUTOSAR配置工具，用于在所述第二配置文件中自动补齐与所述DDS相关的电子控制单元(ECU)的参数配置，得到补齐后的第二配置文件，并根据所述补齐后的第二配置文件生成BSW代码，所述BSW代码用于实现如权利要求10-18中任一项所述的方法。
  25. 根据权利要求24所述的系统，其特征在于，所述系统还包括SWC建模工具，用于：
    对SWC的功能进行设计，并生成SWC代码。
  26. 根据权利要求25所述的系统，其特征在于，所述系统还包括部署模块，用于：
    将所述BSW代码与所述SWC代码部署于ECU上运行，其中，所述ECU上部署多协议互通装置(Gateway)，所述Gateway用于实现SOME/IP与DDS之间的互通。
  27. 根据权利要求26所述的系统，其特征在于，所述系统还包括设计工具，用于：
    进行参数配置，并生成第三配置文件；
    根据所述第三配置文件生成目标代码，所述目标代码用于实现所述Gateway的功能。
  28. 一种计算机设备，包括处理器和存储器，所述处理器与所述存储器耦合，其特征 在于，
    所述存储器，用于存储程序；
    所述处理器，用于执行所述存储器中的程序，使得所述计算机设备执行如权利要求10-18中任一项所述的方法。
  29. 一种工具系统，包括处理器和存储器，所述处理器与所述存储器耦合，其特征在于，
    所述存储器，用于存储程序；
    所述处理器，用于执行所述存储器中的程序，使得所述工具系统执行如权利要求19-23中任一项所述的方法。
  30. 一种计算机可读存储介质，包括程序，当其在计算机上运行时，使得计算机执行如权利要求10-23中任一项所述的方法。
  31. 一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如权利要求10-23中任一项所述的方法。
  32. 一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行如权利要求10-23中任一项所述的方法。
PCT/CN2022/087550 2021-04-22 2022-04-19 一种基于autosar实现dds通信的系统架构、通信方法及设备 WO2022222901A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22791009.8A EP4322483A1 (en) 2021-04-22 2022-04-19 System architecture for implementing dds communication on basis of autosar, communication method, and device
US18/492,446 US20240045657A1 (en) 2021-04-22 2023-10-23 System architecture for implementing dds communication based on autosar, communication method, and device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202110435762 2021-04-22
CN202110435762.4 2021-04-22
CN202110714858.4A CN115242565B (zh) 2021-04-22 2021-06-25 一种基于autosar实现dds通信的系统架构、通信方法及设备
CN202110714858.4 2021-06-25

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/492,446 Continuation US20240045657A1 (en) 2021-04-22 2023-10-23 System architecture for implementing dds communication based on autosar, communication method, and device

Publications (1)

Publication Number Publication Date
WO2022222901A1 true WO2022222901A1 (zh) 2022-10-27

Family

ID=83666594

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/087550 WO2022222901A1 (zh) 2021-04-22 2022-04-19 一种基于autosar实现dds通信的系统架构、通信方法及设备

Country Status (4)

Country Link
US (1) US20240045657A1 (zh)
EP (1) EP4322483A1 (zh)
CN (1) CN115242565B (zh)
WO (1) WO2022222901A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117440446A (zh) * 2023-12-20 2024-01-23 商飞智能技术有限公司 一种基于数据分发服务的数据传输方法和装置
CN118138621A (zh) * 2024-03-06 2024-06-04 小米汽车科技有限公司 信号到服务的转换方法、装置、电子设备以及存储介质
WO2024147372A1 (ko) * 2023-01-03 2024-07-11 엘지전자 주식회사 차량의 신호 처리 장치 및 이를 구비하는 차량

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115766915A (zh) * 2022-11-01 2023-03-07 长城汽车股份有限公司 汽车开放系统架构、数据处理方法、介质及车载设备
CN118034725A (zh) * 2022-11-08 2024-05-14 华为技术有限公司 数据同步方法、存储介质和电子设备
WO2024113273A1 (zh) * 2022-11-30 2024-06-06 华为技术有限公司 通信模型中的通信节点的校验方法与装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102385530A (zh) * 2011-08-11 2012-03-21 浙江大学 一种应用于rte代码生成的os资源分配冲突解决方法
US20170048359A1 (en) * 2015-08-13 2017-02-16 Robert Bosch Gmbh Method and device for transmitting a message in a vehicle
CN112104536A (zh) * 2020-11-02 2020-12-18 奥特酷智能科技(南京)有限公司 基于dds协议的汽车以太网总线设计方法
CN112230630A (zh) * 2020-12-09 2021-01-15 奥特酷智能科技(南京)有限公司 基于dds协议在自动驾驶中实现诊断的方法
WO2021023379A1 (en) * 2019-08-06 2021-02-11 Huawei Technologies Co., Ltd. Method and appartaus for processing data in a network

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6461784B2 (ja) * 2015-12-28 2019-01-30 川崎重工業株式会社 航空機搭載システム
CN109117121B (zh) * 2018-05-08 2022-05-27 宁波央腾汽车电子有限公司 一种autosar软件架构实现方法
CN110086891B (zh) * 2019-06-25 2019-09-27 奥特酷智能科技(南京)有限公司 基于dds协议在自动驾驶中实现分布式通信的方法
CN112513814B (zh) * 2020-04-01 2021-11-30 华为技术有限公司 任务调度方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102385530A (zh) * 2011-08-11 2012-03-21 浙江大学 一种应用于rte代码生成的os资源分配冲突解决方法
US20170048359A1 (en) * 2015-08-13 2017-02-16 Robert Bosch Gmbh Method and device for transmitting a message in a vehicle
WO2021023379A1 (en) * 2019-08-06 2021-02-11 Huawei Technologies Co., Ltd. Method and appartaus for processing data in a network
CN112104536A (zh) * 2020-11-02 2020-12-18 奥特酷智能科技(南京)有限公司 基于dds协议的汽车以太网总线设计方法
CN112230630A (zh) * 2020-12-09 2021-01-15 奥特酷智能科技(南京)有限公司 基于dds协议在自动驾驶中实现诊断的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PARMAR NAVRATTAN, RANGA VIRENDER, SIMHACHALAM NAIDU B.: "Syntactic Interoperability in Real-Time Systems, ROS 2, and Adaptive AUTOSAR Using Data Distribution Services: An Approach", INVENTIVE COMMUNICATION AND COMPUTATIONAL TECHNOLOGIES : PROCEEDINGS OF ICICCT 2019; APRIL 29-30, 2019, SPRINGER SINGAPORE, SINGAPORE, vol. 89, 31 January 2020 (2020-01-31) - 30 April 2019 (2019-04-30), Singapore, pages 257 - 274, XP009540839, ISBN: 978-981-15-0145-6, DOI: 10.1007/978-981-15-0146-3_25 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024147372A1 (ko) * 2023-01-03 2024-07-11 엘지전자 주식회사 차량의 신호 처리 장치 및 이를 구비하는 차량
CN117440446A (zh) * 2023-12-20 2024-01-23 商飞智能技术有限公司 一种基于数据分发服务的数据传输方法和装置
CN117440446B (zh) * 2023-12-20 2024-05-31 商飞智能技术有限公司 一种基于数据分发服务的数据传输方法和装置
CN118138621A (zh) * 2024-03-06 2024-06-04 小米汽车科技有限公司 信号到服务的转换方法、装置、电子设备以及存储介质

Also Published As

Publication number Publication date
CN115242565B (zh) 2023-12-15
EP4322483A1 (en) 2024-02-14
US20240045657A1 (en) 2024-02-08
CN115242565A (zh) 2022-10-25

Similar Documents

Publication Publication Date Title
WO2022222901A1 (zh) 一种基于autosar实现dds通信的系统架构、通信方法及设备
Dobrev et al. Device and service discovery in home networks with OSGi
JP4909591B2 (ja) コンポーネントベースの無線アプリケーションを作成して同アプリケーションと通信するためのシステム及び方法
EP1511218B1 (en) A method to realize dynamic networking and resource sharing among equipments
Gupta et al. Jini home networking: a step toward pervasive computing
CN108494817B (zh) 数据传输方法、相关装置及系统
Bouloukakis et al. Automated synthesis of mediators for middleware-layer protocol interoperability in the IoT
WO2005083934A1 (en) System and method for communicating asynchronously with web services using message set definitions
JP4778692B2 (ja) 異種ネットワークに接続された装置間の制御方法及びかかる方法を実施する装置
JP2006236354A (ja) ホームネットワークのサービスフレームワーク及びその制御方法
EP1542404B1 (en) Sharing services on a network
Ferscha et al. A light-weight component model for peer-to-peer applications
Bottaro et al. Home SOA- facing protocol heterogeneity in pervasive applications
Park et al. InterX: A service interoperability gateway for heterogeneous smart objects
US7908387B2 (en) Lookup service system in JINI-based home network supporting IEEE1394 and TCP/IP
JP2005322222A (ja) 通信機能付加方法、プログラム、記録媒体及び通信装置
Weckemann et al. Lessons from a Minimal Middleware for IP-based In-car Communication
US7685303B2 (en) Object-oriented discovery framework
Steele et al. XML-based mobile agents
Pagel et al. Ambient control: A mobile framework for dynamically remixing the internet of things
CN115913809B (zh) 数据分发通信方法、系统、计算机设备及存储介质
Davy Components of a smart device and smart device interactions
Taherkordi et al. A component-based approach for service distribution in sensor networks
CN115174687B (zh) 服务调用方法、装置、电子设备及存储介质
CN118250325A (zh) 一种边缘算网主机组网交互系统及数据实时交互方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22791009

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022791009

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022791009

Country of ref document: EP

Effective date: 20231108

NENP Non-entry into the national phase

Ref country code: DE