asp文件怎么做网站,东莞做网站哪个公司好,长沙网络营销外包哪家好,在国外做网站摘要#xff1a;
SOA#xff08;面向服务的架构#xff09;的软件设计原则之一是模块化。 前言 SOA#xff08;面向服务的架构#xff09;的软件设计原则之一是模块化。模块化可以提高软件系统的可维护性和代码重用性#xff0c;并且能够隔离故障。举例来说#xff0c;…摘要
SOA面向服务的架构的软件设计原则之一是模块化。 前言 SOA面向服务的架构的软件设计原则之一是模块化。模块化可以提高软件系统的可维护性和代码重用性并且能够隔离故障。举例来说自动驾驶系统可以分解为特定的任务模块如数据采集、状态估计和任务规划等。为了完成各自的任务这些模块需要相互交换信息。在现代操作系统中将单个模块映射到独立的软件进程非常方便这些进程可以位于同一计算设备上也可以位于物理上独立的计算设备上。这使得进程间通信成为一个深入研究的问题因为信息交换是通过进程间的通信来实现的。
一. 通信中间件 在软件定义汽车中应用程序之间的跨进程或跨核通信是一个需要解决的问题。模块化架构为开发人员提供了便利但也引入了对通信中间件的需求。 在没有使用通信中间件的情况下开发人员需要自己定义数据的格式、发送方和接收方。然而使用基于服务/数据的发布和订阅模式如SOME/IP和DDS开发人员只需要明确需要什么样的数据以及数据应该传递到哪里而无需关注数据的发送方和发送方式。 以数据为中心是相对于传统的以消息为中心而言的其本质区别在于通信中间件知道存储了什么数据并能够控制如何共享这些数据。对于传统的以消息为中心的中间件程序员必须为发送消息编写代码而对于以数据为中心的中间件程序员只需为如何共享数据编写代码然后可以直接共享数据值。 通信中间件可以采用点对点、消息队列和发布/订阅三种工作模式SOME/IP和DDS都采用了发布/订阅模式。 在发布/订阅模型中发布者和订阅者通过主题进行关联双方不需要知道对方在何处也不需要同时在线。这实现了通信双方在时间、空间和数据通信上的多维松耦合。 此外与面向信号的CAN相比DDS和SOME/IP都是面向服务的通信协议。两者的区别在于面向信号的数据传输始终循环发送而面向服务的通信方式不同只有在客户端请求或服务器通知特定订阅者时才在客户端-服务器配置中交换数据。这确保了永远不会浪费带宽并且仅在需要的时间和地点进行数据通信/交换。因此面向服务的通信协议可以大大减少网络负载提高通信效率。 在软件定义汽车时代车内的所有可调用功能都被视为服务并提供不同类型的调用接口这些接口可以按以下方式分类 1、API接口提供各类函数的调用接口使应用程序能够调用系统内部的功能实现函数。应用程序可以通过调用相关的API接口来提供和使用功能服务。 2、文件方式以配置文件或设备文件的形式提供系统内部的调用能力。这些文件可以通过配置自动生成包含有效的配置信息并且可以在运行环境中被特定的程序读取和识别实现特定的服务。 3、系统原生服务操作系统和基础类库提供的可操作能力包括对系统CPU和内存的监测、应用程序的监控、系统资源的划分等。此外还可以调用C、boost等基础类库。 4、IPC接口各种IPC机制提供系统内进程间的调用能力包括使用套接字socket、共享内存等进程间通信方式以及使用特定的跨核通信方式如IPCF。 5、协议栈接口通过网络协议栈提供跨平台的调用能力包括SOME/IP、DDS、MQTT、HTTP等网络协议的调度服务、接口封装和协议转换等。 尽管在互联网领域中SOA面向服务的架构已经被应用了很长时间但在汽车行业中它算是相对较新的概念。在Adaptive AutoSAR框架中通信管理模块包括进程间通信和网络协议栈。 鉴于汽车应用场景和通信需求的特殊性许多互联网的SOA技术并不能直接应用于汽车领域。一般来说SOA通信中间件系统的各个层面需要满足以下要求 1、本地服务和远程服务之间的通信应该使用统一的接口描述语言IDL定义的文件作为契约。IDL是一种中立的接口描述语言与具体的操作系统和编程语言无关。 2、SOA框架的底层核心功能应具备以下特点服务发现、消息序列化、内部事件/消息处理和传输功能。应用程序、服务和操作系统之间可以通过标准的通信协议或服务接口相互通信或访问特别是要满足传感数据的大数据吞吐传输需求。必须支持典型的车内通信协议如SOME/IP协议、DDS规范等。服务发现功能应具备访问控制功能以防止未经授权的用户进行窃听和侵入传输功能应具备数据加密和签名等功能以确保通信数据的安全性。 在未来汽车将与更多的基础设施进行连接为了实现与它们的连接将需要使用不同的通信协议。 汽车SOA 通信架构 HTTP、MQTT、SOME/IP和DDS等协议都用于实现SOA架构中的通信只是在不同的场景下承担不同的责任。例如SOME/IP协议用于车内节点之间的服务通信而HTTP和MQTT用于与互联网模块进行通信。尽管它们在实现机制上有些许差异但它们可以相互切换使用。
MQTT、DDS、AMQP、REST和CoAP等协议都已被广泛应用并且每种协议都至少有10种不同的代码实现。它们都宣称支持实时的发布/订阅物联网协议。然而在具体的系统架构设计中需要考虑实际场景中的通信需求并选择适合的协议。各种协议的特点如表所示。 二、SOME/IP 介绍 2011年宝马设计并提出了SOME/IPScalable Service-oriented Middleware over IP协议。SOME/IP采用服务器-客户端的服务通信模式并且具备高度可扩展性。SOME/IP协议是一种应用层协议运行在TCP/UDP传输协议之上车载以太网第四层以上。它作为以太网通信的中间件实现应用层与IP层之间的数据交互使其不依赖于操作系统并且兼容AUTOSAR和非AUTOSAR平台。因此SOME/IP可以独立于硬件平台、操作系统和编程语言。 SOME/IP 协议架构 SOME/IP具备满足车用需求的特性主要包括以下几个方面基于服务的通信方式占用空间小与AUTOSAR兼容其他中间件不具备兼容性可伸缩性适用于小型和大型平台以及兼容性可适用于车辆使用的各种操作系统如AUTOSAR、OSEK、QNX和Linux。 SOME/IP支持AUTOSAR CP、AUTOSAR AP以及非AUTOSAR平台之间的通信交互。宝马设计SOME/IP协议后它被AUTOSAR纳入正式标准并随着CP规范的发布而被广泛应用于车载以太网因此可以说是AUTOSAR CP推动了SOME/IP的广泛使用。
在AUTOSAR架构中SOME/IP-SD模块位于AUTOSAR BSW Mode Manager模块BswM和AUTOSAR Socket Adaptor模块SoAd之间。BswM模块提供了通用模式请求和服务请求之间的连接而SoAd模块处理以太网堆栈和SD模块之间的服务请求。通过配置SoAd中的Socket Connection表可以接收其他ECU的SD模块发送的单播和多播报文。 借助SOME/IP协议的高度平台扩展性可以实现不同平台之间的数据交互而统一的SOME/IP通信机制是不同平台通信的前提。为了在不同软件平台上运行SOME/IP实现整车以太网上的SOA架构通信机制AP规范中也同步引入了SOME/IP因此在AUTOSAR系统中CP和AP之间实现SOME/IP通信相对容易。 为了促进非AUTOSAR软件平台与车内CP和APECU之间的交互GENIVI系统同样开发了一套开源的vSOME/IP软件源码以便与CP/AP进行交互。然而由于vSOME/IP是开源的性能可能略有差异因此需要统一的规范进行约束以进行深度的二次开发。目前全球最大的商用SOME/IP产品供应商是Vector而开源版的vSOME/IP由GENIVI协会维护。 三、DDS 介绍 DDSData Distribution Service是由OMGObject Management Group发布的分布式通信规范。OMG成立于1989年是一个国际性、开放性、非营利性的技术标准联盟由供应商、终端用户、学术机构和政府机构推动。OMG工作组致力于制定企业集成标准和开发可为数千个垂直行业提供现实价值的技术标准其中包括统一建模语言SYSML、UML以及中间件标准CORBA、DDS等。 DDS最早应用于美国海军系统用于解决在军舰系统复杂网络环境中进行大量软件升级时的兼容性问题。随着DDS被ROS2和AUTOSAR引入目前它已经广泛应用于航空、航天、船舶、国防、金融、通信、汽车等领域。 DDS的特点 1、数据中心Data Centricity DDS最重要的特性是以数据为中心这与其他许多通信中间件不同。DDS的数据共享以Topic为单元应用程序能够通过Topic判断包含的数据类型而不必依赖其他上下文信息。同时DDS能够按照用户定义的方式自动地存储、发布或订阅数据使应用程序能够像访问本地数据一样进行数据的写入或读取。 DDS 数据中心 2、全局数据空间Global Data space DDS实现的数据共享可以被理解为一个抽象的全局数据空间无论应用程序是用哪种开发语言编写或者在哪种操作系统上运行都可以以相同的方式访问这个全局数据空间就像访问本地存储空间一样。当然全局数据空间只是一个抽象概念在实际实现中数据仍然被分别存储在每个应用程序的本地空间中。在系统运行时数据是按需传输或存储的数据的发布者只发送订阅者需要的数据而订阅者只接收并存储本地应用程序当前所需的数据。 全局数据空间 3、服务质量Quality of service DDS还提供了高度灵活的QoSQuality of Service策略以满足用户对数据共享方式的不同需求例如可靠性和故障处理等。对于对数据安全性要求较高的系统DDS还提供了精细的数据安全控制包括应用程序身份认证、权限控制和数据加密等。 4、动态发现Dynamic Discovery 类似于SOME/IP-SDDDS提供了数据发布者和订阅者的动态发现机制这意味着用户无需手动配置通信节点的地址或其他属性信息因为它们在运行过程中会自动发现对方并自动完成相关配置实现了即插即用的功能。 5、可扩展架构Scalable Architecture DDS可应用于边缘计算、雾计算和云计算领域。在边缘计算中DDS可以实现高速实时的设备间通信。在中间系统中DDS提供健壮可靠的QoS和内容感知的信息流。DDS提供可扩展的信息访问和数据分发手段用于集成信息系统将各系统接入云端。 OMG DDS的适用范围广泛涵盖了从小型设备到云计算系统等超大型系统。DDS能够以超高速传输数据并同时管理数千个数据对象提供极高的可用性和安全性非常适用于物联网。通过提供一个标准的通信层DDS屏蔽了底层复杂性简化了分布式系统的开发。 可扩展架构 6、安全Security DDS为关键任务的工业物联网环境提供了全面的安全保护机制跨系统、跨供应商覆盖从边缘设备到云端的安全性需求。 DDS提供了身份验证、访问控制、数据加密和数据完整性等安全机制以确保数据分发的安全性。这些安全机制是在点对点对等架构上实现的不会影响实时通信的性能。 目前DDS已被多个车载中间件平台引入。AUTOSAR AP已完整地集成了DDS标准的网络绑定。另外虽然AUTOSAR CP的标准规范本身不支持DDS但通过一些变通方法也可以在CP上集成DDS。ROS2和CyberRT的底层都使用了开源的DDS作为最重要的通信机制。针对自动驾驶领域的SOC芯片如Xavier和Orin也都预留了DDS接口。RTI作为OMG组织董事会的成员领导了DDS标准的制定并开发了名为Connext的DDS品牌因此也被称为Connext DDS。 开源DDS相对于商用的RTI DDS等来说是根据OMG官方标准开发的但源代码是开放的主要包括Fast DDS和Open DDS等。 在自动驾驶领域由RTI原核心团队成员在欧洲创办的eProsima公司推出了影响力较大的开源DDS名为Fast DDS。在eProsima将Fast DDS的源代码开放后用户可以直接在GitHub上免费下载。使用Fast DDS需要向eProsima支付费用以获得支持。 Open DDS由位于圣路易斯和凤凰城的Object Computing的ACE/TAO团队开发与Fast DDS有一定的相似性两者都基于RTPS实现都是面向数据的通信框架并遵循同一标准。这类框架的典型特征是去中心化、支持QoS机制和实时通信并通常与序列化工具如protobuf进行绑定。 尽管开源DDS对RTI的商用DDS形成一定的竞争但开源DDS也存在一些不足之处开源DDS的使用门槛较高例如RTI DDS的服务策略有50多个而开源DDS只有23个完整性远不及前者RTI的DDS已通过了ASIL-D认证而开源DDS尚未达到这一认证水平。
四、SOME/IP 与 DDS 对比 SOME/IP和DDS是目前在域控最常用的两类通信中间件它们都是面向服务的通信协议并采用以数据为中心的发布/订阅模式。 然而SOME/IP和DDS在许多方面也存在差异主要区别如下 1、主要应用领域不同SOME/IP专为汽车领域开发针对汽车领域的需求定义了一套通信标准并在汽车领域深耕已久而DDS是一个工业级别的强实时通信标准适应性较强但在应用于汽车/自动驾驶领域时需要进行专门的裁剪。 2、灵活性和可伸缩性不同相比SOME/IPDDS引入了许多标准内置特性如基于内容和时间的过滤、与传输无关的可靠性、持久性、存活性、延迟/截止时间监视、可扩展类型等。当AUTOSAR AP与DDS一起构建通信框架时该框架不仅与现有API和应用程序兼容还在可靠性、性能、灵活性和可伸缩性等方面提供重要的好处。 3、订阅方和发布方的耦合程度不同在SOME/IP中订阅方在正常数据传输之前需要与发布方建立网络连接并询问发布方是否提供所需服务从这个角度看节点之间仍然存在一定的耦合性。而在DDS标准下每个订阅方或发布方只需要在自己的程序中订阅或发布传感器数据无需关心任何连接。因此在DDS中服务的订阅方和发布方更加彻底地解耦。 4、服务策略不同良好的服务质量QoS是DDS标准相对于SOME/IP最重要的特征。SOME/IP只有一个QoS而RTI DDS和开源DDS分别提供了50多个和20多个QoS这些QoS基本上涵盖了大多数可预见的智能驾驶场景。 5、应用场景不同从应用场景的角度来看SOME/IP更适用于车载网络并且只能在基于IP类型的网络环境中使用而DDS在传输方式上没有特别的限制可以支持基于非IP类型的网络例如共享内存、跨核通信、PCIe等。此外DDS还提供了完备的车联网解决方案其独有的DDS Security和DDS Web功能为用户提供了一站式的“车-云-移动端”解决方案。 在商业落地中SOME/IP和DDS之间存在直接的竞争关系但由于它们在应用领域、灵活性和服务策略等方面存在差异整车厂可以根据需求选择适合的通信中间件甚至可以同时使用二者。这也是为什么AUTOSAR AP既支持SOME/IP也支持DDS的原因。 来源 | 车端
