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

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

Info

Publication number
CN115242565B
CN115242565B CN202110714858.4A CN202110714858A CN115242565B CN 115242565 B CN115242565 B CN 115242565B CN 202110714858 A CN202110714858 A CN 202110714858A CN 115242565 B CN115242565 B CN 115242565B
Authority
CN
China
Prior art keywords
target
swc
message
dds
architecture
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN202110714858.4A
Other languages
English (en)
Other versions
CN115242565A (zh
Inventor
马松君
蒋斌
李振飞
徐艳琴
孔振强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Yinwang Intelligent Technology Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to PCT/CN2022/087550 priority Critical patent/WO2022222901A1/zh
Priority to EP22791009.8A priority patent/EP4322483A4/en
Publication of CN115242565A publication Critical patent/CN115242565A/zh
Priority to US18/492,446 priority patent/US12498997B2/en
Application granted granted Critical
Publication of CN115242565B publication Critical patent/CN115242565B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • 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
    • G05—CONTROLLING; REGULATING
    • G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/20—Control system inputs
    • G05D1/22—Command input arrangements
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H04L12/2827—Reporting to a device within the home network; wherein the reception of the information reported automatically triggers the execution of a home appliance functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/4013—Management of data rate on the bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (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通信的软件架构设计方法及设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及车载管理技术领域，尤其涉及一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备。
背景技术
汽车开放系统架构(automotive open system architecture，AUTOSAR)是由全球各大汽车OEM、零部件供应商、汽车电子软件公司联合建立的一套标准协议。该协议规范了一个符合汽车电子软件开发的、开放的以及标准化的软件架构。最初的AUTOSAR规范的制定只考虑传统汽车电子电器架构，基于硬件算力有限场景，提供确定的功能。这就是通常所讲的Classic AUTOSAR，简称CP，各类技术文档所讲的“AUTOSAR”一般也特指CP，当前全世界绝大多数厂商都是基于AUTOSAR架构进行软件开发。
随着车辆当前正快速面向智能化演进，各类智能网联技术、自动驾驶技术快速迭代，车辆上的各类设备也爆发式增长，软件需求日益强大，分布式的汽车电子电气架构逐渐向功能域集中架构或中央集中架构演进，传统的AUTOSAR规范已不适合当前车辆电子的发展。因而汽车开放系统架构自适应平台(adaptive automotive open systemarchitecture，AP)又被演进出来。AP主要用于承载智能化软件模块，部署于算力更强的硬件资源之上。车辆上所部署的各类传感器、执行器或其他功能器件，由于硬件能力有限，部分硬件依然需要CP的软件架构。
基于AUTOSAR(即Classic AUTOSAR，CP)的CP设备只规定使用SOME/IP(一种通信中间件)进行通信，而基于Adaptive AUTOSAR(即AP)的AP设备可以使用DDS(也是一种通信中间件)和SOME/IP进行通信，因此，CP设备只能与AP设备中使用SOME/IP的应用通信，而不能与AP设备中使用DDS的应用通信，目前解决方法是将数据分发服务(data distributionservice，DDS)的基本功能实现在CP的软件架构里的CDD内，CDD是用于承载CP规范外的功能模块，但这种方式打破了传统CP使用者使用工具进行自动开发的习惯，需要开发人员手动增加和修改很多代码来使用DDS的各种接口，且无法做到与AP设备的服务化通信能力。
发明内容
本申请实施例提供了一种基于AUTOSAR实现DDS通信的系统架构、通信方法及设备，用于将DDS集成在CP软件架构中的BSW内，让DDS与CP兼容，做到软件组件(softwarecomponent，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历史缓存(historycache)需求的情况下，该第一SWC通过占用内存空间满足该DDS历史缓存需求，该第一SWC为该AUTOSAR中部署的SWC中的一个。
在本申请上述实施方式中，针对有DDS历史缓存需求SWC，则允许该SWC通过占用内存空间，实现了内存空间的按需分配。
在第一方面的一种可能的实现方式中，在第一SWC没有DDS历史缓存(historycache)需求的情况下，则该第一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、相关术语和概念介绍
智能化的演进让软件在智能车的重要性有了巨大的提升，催生出了“软件定义汽车”的概念，相应地，也对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的DataReader通过相同的主题名称Topic Name和相兼容的QoS进行配对，从而消息发布者可以向匹配的消息订阅者发送消息。消息发布者、消息订阅者可以有一个或多个Data Writer、Data Reader。每个消息发布者的不同Data Writer不限制其Topic Name或QoS必须一致，这给消息通信带来了极大的灵活性。
需要说明的是，每一个Data Writer或Data Reader，都有其自己的历史缓存(History Cache)，对于Data Writer，History Cache用来缓存需要发送的数据；对于DataReader，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中的3rd设备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还包括RTE1405以及至少一个SWC 1406。其中，第一集成模块1401，用于对消息发布者和/或消息订阅者进行管理，例如，用于管理消息发布者与消息订阅者之间的自动发现过程，又例如，在某一个或多个消息发布者与某一个或多个消息订阅者均完成配对的情况下，对该消息发布者和/或该消息订阅者中的数据进行管理，具体本申请对管理的方式不做限定；AUTOSAR 1403中的RTE 1405，用于存储每个第一集成模块1401与各自对应的SWC信号之间的映射关系，需要说明的是，该SWC信号为SWC 1406向RTE1405发送的并用于提供给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)部署在AUTOSAR1403中的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 HistoryCache需求；无此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有DDSHistory 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)，订阅确定消息(SubscribeACK)等消息，其运行顺序如前图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可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(centralprocessing 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 (31)

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-5中任一项所述的架构，其特征在于，
在第一SWC有DDS历史缓存（history cache）需求的情况下，所述第一SWC通过占用内存空间满足所述DDS历史缓存需求，所述第一SWC为所述AUTOSAR中部署的SWC中的一个。
9.根据权利要求1-5中任一项所述的架构，其特征在于，
在第一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-12中任一项所述的方法，其特征在于，
所述DDS架构的自动发现机制由嵌入在所述BSW中的BSW管理单元（BSW-M）内的目标模块触发执行，所述目标模块用于管理每个参与者（Participant）各自对应的简单参与者发现协议（SPDP）消息和/或简单端节点发现协议（SEDP）消息的交互过程，所述交互过程用于实现所述DDS架构的自动发现机制。
16.根据权利要求15所述的方法，其特征在于，所述方法还包括：
所述系统架构将与每个参与者各自对应的SPDP信息和/或SEDP信息生成代码片段；
在第一参与者处于自动发现过程中的情况下，所述系统架构将与所述第一参与者对应的代码片段进行组装，形成与所述第一参与者对应的SPDP信息和/或SEDP信息，所述第一参与者为所述参与者中的一个或多个。
17.根据权利要求10-12中任一项所述的方法，其特征在于，所述方法还包括：
在所述目标SWC有DDS历史缓存（history cache）需求的情况下，确定所述目标SWC通过占用内存空间满足所述DDS历史缓存需求。
18.根据权利要求10-12中任一项所述的方法，其特征在于，所述方法还包括：
在所述目标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上部署多协议互通装置，所述多协议互通装置用于实现SOME/IP与DDS之间的互通。
22.根据权利要求21所述的方法，其特征在于，
所述多协议互通装置包括消息转换模块以及消息控制模块；
所述消息转换模块用于对接收到的消息进行SOME/IP与DDS之间的消息格式转换；
所述消息控制模块用于根据所述消息承载的内容进行SOME/IP与DDS之间消息收发流程的转换。
23.根据权利要求21-22中任一项所述的方法，其特征在于，所述方法还包括：
通过设计工具进行参数配置，并生成第三配置文件；
根据所述第三配置文件生成目标代码，所述目标代码用于实现所述多协议互通装置的功能。
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上部署多协议互通装置，所述多协议互通装置用于实现SOME/IP与DDS之间的互通。
27.根据权利要求26所述的系统，其特征在于，所述系统还包括设计工具，用于：
进行参数配置，并生成第三配置文件；
根据所述第三配置文件生成目标代码，所述目标代码用于实现所述多协议互通装置的功能。
28.一种计算机设备，包括处理器和存储器，所述处理器与所述存储器耦合，其特征在于，
所述存储器，用于存储程序；
所述处理器，用于执行所述存储器中的程序，使得所述计算机设备执行如权利要求10-18中任一项所述的方法。
29.一种工具系统，包括处理器和存储器，所述处理器与所述存储器耦合，其特征在于，
所述存储器，用于存储程序；
所述处理器，用于执行所述存储器中的程序，使得所述工具系统执行如权利要求19-23中任一项所述的方法。
30.一种计算机可读存储介质，包括程序，当其在计算机上运行时，使得计算机执行如权利要求10-23中任一项所述的方法。
31.一种芯片，所述芯片包括处理器与数据接口，所述处理器通过所述数据接口读取存储器上存储的指令，执行如权利要求10-23中任一项所述的方法。
CN202110714858.4A 2021-04-22 2021-06-25 一种基于autosar实现dds通信的系统架构、通信方法及设备 Active CN115242565B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/CN2022/087550 WO2022222901A1 (zh) 2021-04-22 2022-04-19 一种基于autosar实现dds通信的系统架构、通信方法及设备
EP22791009.8A EP4322483A4 (en) 2022-04-19 System architecture for implementing dds communication on basis of autosar, communication method, and device
US18/492,446 US12498997B2 (en) 2021-04-22 2023-10-23 System architecture for implementing DDS communication based on AUTOSAR, communication method, and device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2021104357624 2021-04-22
CN202110435762 2021-04-22

Publications (2)

Publication Number Publication Date
CN115242565A CN115242565A (zh) 2022-10-25
CN115242565B true CN115242565B (zh) 2023-12-15

Family

ID=83666594

Family Applications (1)

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

Country Status (3)

Country Link
US (1) US12498997B2 (zh)
CN (1) CN115242565B (zh)
WO (1) WO2022222901A1 (zh)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7663010B2 (ja) * 2021-03-31 2025-04-16 株式会社オートネットワーク技術研究所 車載中継装置、車載通信システムおよび通信制御方法
CN115766915B (zh) * 2022-11-01 2025-12-05 长城汽车股份有限公司 汽车开放系统架构、数据处理方法、介质及车载设备
CN115842855A (zh) * 2022-11-01 2023-03-24 长城汽车股份有限公司 一种dds通讯方法、装置、电子设备及车辆
CN118034725A (zh) * 2022-11-08 2024-05-14 华为技术有限公司 数据同步方法、存储介质和电子设备
CN120283221A (zh) * 2022-11-30 2025-07-08 深圳引望智能技术有限公司 通信模型中的通信节点的校验方法与装置
CN115834375B (zh) * 2022-11-30 2025-01-10 重庆长安汽车股份有限公司 一种车端服务通信配置方法、系统、设备及存储介质
CN116028065B (zh) * 2022-12-30 2026-02-17 国科础石(重庆)软件有限公司 节点的部署方法、装置、设备和存储介质
KR20250129748A (ko) * 2023-01-03 2025-08-29 엘지전자 주식회사 차량의 신호 처리 장치 및 이를 구비하는 차량
CN116192895A (zh) * 2023-02-01 2023-05-30 东风悦享科技有限公司 一种基于时间同步优化配置的智能驾驶平台
CN116155716B (zh) * 2023-02-28 2025-05-16 重庆长安汽车股份有限公司 一种基于mcu的dds部署方法、装置、电子设备和存储介质
CN116301801A (zh) * 2023-03-01 2023-06-23 中汽创智科技有限公司 用于实现车辆软件的程序生成方法、相关设备及存储介质
CN116684487A (zh) * 2023-04-28 2023-09-01 重庆长安汽车股份有限公司 一种基于mcu的dds协议发现阶段优化方法、存储介质、电子设备、通信方法及汽车
US12511113B2 (en) * 2023-05-24 2025-12-30 Fca Us Llc Systems and methods for automated driving high performance computing
CN116634013A (zh) * 2023-06-05 2023-08-22 上汽通用汽车有限公司 信号与服务的转换系统及车辆
CN117032723B (zh) * 2023-08-21 2025-12-30 阿维塔科技(重庆)有限公司 基于汽车电控单元的信号处理方法、装置、设备及介质
CN117608530B (zh) * 2023-11-14 2025-03-18 东风商用车有限公司 基于autosar架构的应用层信息管理系统和方法
CN117632364B (zh) * 2023-11-29 2025-03-28 赛力斯汽车有限公司 Autosar虚拟化平台、应用方法、设备和介质
CN117692271B (zh) * 2023-12-12 2025-05-30 东风汽车集团股份有限公司 一种Autosar架构下自动生成多车型Can通讯及路由配置的方法
DE102023212765A1 (de) * 2023-12-15 2025-06-18 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Überwachen einer Anwendung zur Bereitstellung wenigstens einer sicherheitskritischen Funktion für ein Fahrzeug
CN117440446B (zh) * 2023-12-20 2024-05-31 商飞智能技术有限公司 一种基于数据分发服务的数据传输方法和装置
CN118827566A (zh) * 2023-12-27 2024-10-22 比亚迪股份有限公司 Autosar上的通信架构、通信方法、设备、介质
CN118138621A (zh) * 2024-03-06 2024-06-04 小米汽车科技有限公司 信号到服务的转换方法、装置、电子设备以及存储介质
CN120144145A (zh) * 2024-03-08 2025-06-13 深圳引望智能技术有限公司 一种开发方法、软件产品、装置、车辆及存储介质
CN118175201A (zh) * 2024-03-12 2024-06-11 奥特酷智能科技(南京)有限公司 一种mpu应用与mcu实现dds通信的系统及方法
CN118075309B (zh) * 2024-03-14 2025-04-08 同济大学 轻量化DDS中间件及其在AUTOSAR Classic平台下的应用
US20250379909A1 (en) * 2024-06-11 2025-12-11 Ford Global Technologies, Llc Service-oriented architecture in a vehicle
CN119150310B (zh) * 2024-07-30 2025-12-16 岚图汽车科技股份有限公司 一种面向服务架构的系统、服务方法、装置、设备、介质
CN118784706B (zh) * 2024-09-11 2024-11-22 成都赛力斯科技有限公司 通信方法和通信装置
CN121029137A (zh) * 2024-09-11 2025-11-28 深圳引望智能技术有限公司 一种代码开发方法及相关装置
CN119961198B (zh) * 2025-04-10 2025-07-08 湖北芯擎科技有限公司 一种soa应用实现方法、装置及设备
CN120151398A (zh) * 2025-05-15 2025-06-13 南昌智能新能源汽车研究院 基于开放式架构的通信中间件构建方法及其系统

Citations (5)

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

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1849093A2 (en) * 2005-01-06 2007-10-31 Tervela Inc. Hardware-based messaging appliance
CN102385530B (zh) * 2011-08-11 2013-09-25 浙江大学 一种应用于rte代码生成的os资源分配冲突解决方法
US20130054863A1 (en) * 2011-08-30 2013-02-28 Allure Energy, Inc. Resource Manager, System And Method For Communicating Resource Management Information For Smart Energy And Media Resources
WO2013123057A1 (en) * 2012-02-13 2013-08-22 Intertrust Technologies Corporation Trusted connected vehicle systems and methods
DE102015215480A1 (de) * 2015-08-13 2017-02-16 Robert Bosch Gmbh Verfahren und Vorrichtung zum Übertragen einer Nachricht in einem Fahrzeug
US10785170B2 (en) * 2018-12-28 2020-09-22 Beijing Voyager Technology Co., Ltd. Reading messages in a shared memory architecture for a vehicle
CN110209514B (zh) 2019-08-01 2019-11-15 奥特酷智能科技(南京)有限公司 在嵌入式传感器接入平台实现dds服务的方法
CN113228576B (zh) * 2019-08-06 2022-10-04 华为技术有限公司 一种处理网络中的数据的方法及装置
CN112104536B (zh) * 2020-11-02 2021-02-12 奥特酷智能科技(南京)有限公司 基于dds协议的汽车以太网总线设计方法

Patent Citations (5)

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

Also Published As

Publication number Publication date
US20240045657A1 (en) 2024-02-08
WO2022222901A1 (zh) 2022-10-27
EP4322483A1 (en) 2024-02-14
CN115242565A (zh) 2022-10-25
US12498997B2 (en) 2025-12-16

Similar Documents

Publication Publication Date Title
CN115242565B (zh) 一种基于autosar实现dds通信的系统架构、通信方法及设备
CN114553873A (zh) 基于soa的车云协同控制系统、方法及可读存储介质
US10681184B2 (en) Method and device for transmitting a message in a vehicle
JP2023544123A (ja) データ送信システム、データ送信方法、インテリジェント車両、及び装置
JP4778692B2 (ja) 異種ネットワークに接続された装置間の制御方法及びかかる方法を実施する装置
CN112740642A (zh) 通信方法及多接入边缘计算服务器
WO2024093731A1 (zh) 汽车开放系统架构、数据处理方法及车载设备
CN118450354B (zh) 基于面向服务架构的ota升级方法、装置、电子设备及介质
CN107508884B (zh) 一种基于soa的仿真模型的共享方法
CN112714146B (zh) 一种资源调度方法、装置、设备及计算机可读存储介质
CN116319983B (zh) 一种面向服务通讯的中间件
CN115913809B (zh) 数据分发通信方法、系统、计算机设备及存储介质
CN115174687B (zh) 服务调用方法、装置、电子设备及存储介质
Weckemann et al. Lessons from a Minimal Middleware for IP-based In-car Communication
Wagner et al. Towards runtime adaptation in AUTOSAR: Adding Service-orientation to automotive software architecture
CN116709265A (zh) 车载通信方法、装置、设备和存储介质
JP7703002B2 (ja) ネットワーク装置、タイムセンシティブ型ネットワークシステム及びその自動構成方法
EP3702920A1 (en) Heterogeneous execution engines in a network centric process control system
CN118250325B (zh) 一种边缘算网主机组网交互系统及数据实时交互方法
JP4239910B2 (ja) オブジェクト配備システム及び方法
CN111200533A (zh) 基于OpenDDS的分布式网络配置部署方法
CN121357201A (zh) 基于autosar实现dds通信的系统、方法及设备
CN121125707A (zh) 算力资源提供方法、装置、电子设备及存储介质
CN121486427A (zh) 一种基于代理swc的以太网soa通信接口预留与动态适配方法和相关设备
Bocquet et al. Multi-model architecture for ITS software design improvements

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20241108

Address after: 518129 Huawei Headquarters Office Building 101, Wankecheng Community, Bantian Street, Longgang District, Shenzhen, Guangdong

Patentee after: Shenzhen Yinwang Intelligent Technology Co.,Ltd.

Country or region after: China

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.

Country or region before: China