精华内容
下载资源
问答
  • 中间件(middleware)是基础软件的一大类,属于可复用软件的范畴。顾名思义,中间件处于操作系统软件与用户的应用软件的中间。中间件在操 作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的...
    中间件(middleware)是基础软件的一大类,属于可复用软件的范畴。顾名思义,中间件处于操作系统软件与用户的应用软件的中间。中间件在操 作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。

      在众多关于中间件的定义中,比较普遍被接受的是IDC表述的:中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源,中间件位于客户机服务器的操作系统之上,管理计算资源和网络通信。

      IDC对中间件的定义表明,中间件是一类软件,而非一种软件;中间件不仅仅实现互连,还要实现应用之间的互操作;中间件是基于分布式处理的软件,最突出的特点是其网络通信功能。

      中科院软件所研究员仲萃豪形象地把中间件定义为:平台+通信。这个定义限定了只有用于分布式系统中的此类软件才能被称为 中间件,同时此定义还可以把中间件与支撑软件和实用软件区分开来。

      目前,中间件发展很快,已经与操作系统、数据库并列为三大基础软件。中间件主要分为以下几类:

    1.通信处理(消息)中间件

    此类中间件能在不同平台之间通信,实现分布式系统中可靠的、高效的、实时的跨平台数据传输(如Tong LINK、BEAe Link、IBM的MQ Series等)。这是中间件中唯一不可缺少的,是销售额最大的中间件产品。

    2.交易中间件

    在分布式事务处理系统中要处理大量事务,常常在系统中要同时做上万笔事务。例如在北京市就要设置各种运载汽车,完成日常的运载,同时要随时监视汽车运 行,出现故障时,要有排除措施,发生堵塞时要进行调度。在联机事务处理系统(OLTP)中,每笔事务常常要多台服务器上的程序顺序地协调完成,一旦中间发 生某种故障时,不但要完成恢复工作,而且要自动切换系统,达到系统永不停机,实现高可靠性运行;同时要使大量事务在多台应用服务器能实时并发运行,并进行 负载平衡地调度,实现昂贵的可靠性机和大型计算机系统同等的功能,为了实现这个目标,要求系统具有监视和调度整个系统的功能。BEA的Tuxedo由此而 著名,它成为增长率最高的厂商。一个事务处理平台,根据X/OPEN的参数模型规定,应由事务处理中间件、通信处理中间件以及数据存取管理中间件三部分组 成。东方通科技公司的Tong LINK和TongEASY实现了这个参考模型规定。

    3.数据存取管理中间件

    在分布式系统中,重要的数据都集中存放在数据服务器中,它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型,或者是经过加密或压缩存放的,该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。

    中间件简史

    最早具有中间件技术思想及功能的软件是IBM的CICS,但由于CICS不是分布式环境的产物,因此人们一般把Tuxedo作为第一个严格意义上的中间 件产品。Tuxedo是1984年在当时属于AT&&T的贝尔实验室开发完成的,但由于分布式处理当时并没有在商业应用上获得像今天一样 的成功,Tuxedo在很长一段时期里只是实验室产品,后来被Novell收购,在经过Novell并不成功的商业推广之后,1995年被现在的BEA公 司收购。

      尽管中间件的概念很早就已经产生,但中间件技术的广泛运用却是在最近10年之中。BEA公司1995年成立后收购 Tuxedo才成为一个真正的中间件厂商,IBM的中间件MQSeries也是90年代的产品,其它许多中间件产品也都是最近几年才成熟起来。国内在中间 件领域的起步阶段正是整个世界范围内中间件的初创时期。东方通科技早在1992年就开始中间件的研究与开发,1993年推出第一个产品 TongLINK/Q。而中科院软件所、国防科技大学等研究机构也对中间件技术进行了同步研究。可以说,在中间件领域,国内的起步时间并不比国外晚多少。

      在j2ee中就是tomcat 和 weblogic 等服务器软件
    计算机技术迅速发展。从硬件技术看,CPU速度越来越高,处理能力越来越强;从软件技术看,应用程序的规模不断扩大,特别是Internet及WWW的出 现,使计算机的应用范围更为广阔,许多应用程序需在网络环境的异构平台上运行。这一切都对新一代的软件开发提出了新的需求。在这种分布异构环境中,通常存 在多种硬件系统平台(如PC,工作站,小型机等),在这些硬件平台上又存在各种各样的系统软件(如不同的操作系统、数据库、语言编译器等),以及多种风格 各异的用户界面,这些硬件系统平台还可能采用不同的网络协议和网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难的问题。

    转载于:https://www.cnblogs.com/seebook/archive/2007/07/02/803534.html

    展开全文
  • Autosar 软件中间件

    2020-10-09 10:47:06
    我们都知道手机,电脑啥的在应用之下,硬件之上,还有一个东西叫操作... 中间件(middleware)是基础软件的一大类,在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发

    我们都知道手机,电脑啥的在应用之下,硬件之上,还有一个东西叫操作系统,车辆里也有类似的东西。

    操作系统,中间件,应用软件-各司其职分工不同

    • 操作系统--我负责对硬件,提供线程创建等服务,其他我不管
    • 中间件--我负责和不同操作系统对接,并给上面应用提供通讯,资源管理等服务,其他我不管
    • 应用软件--嗯,剩下都我的事,我管功能,不同系统,不同硬件的事我不管。

      中间件(middleware)是基础软件的一大类,在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。在不同的技术之间共享资源并管理计算资源和网络通信。

    另外中间件的定位不是操作系统,而是一套软件框架,虽然包括了RTOS,MCAL,服务通信层等协议和服务。两者看着很接近,但没有多少竞争关系。

    操作系统的话题,我们另外一篇文章再聊,今天关注软件定义汽车的话题中心-中间件。

    什么是汽车软件中间件?

    随着汽车应用要求的不断提高,软件总量也随之迅速增长,这导致了系统的复杂性和成本的剧增,为了提高软件的管理性、移植性、裁剪性和质量,需要定义一套架构( Architecture );方法学( Methodology )和应用接口( Application Interface )。从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。

    目前在汽车控制领域有多种总线标准,各侧重点有所不同。尽管总线通信速度越来越高,但是还没有通信网络可以完全满足未来汽车的所有成本和性能要求,因此需要兼容多种总线和底层协议的通信协议和规范。

    中间件的核心思想在于“统一标准、分散实现、集中配置”

    统一标准才能给各个厂商提供一个通用的开放的平台;分散实现则要求软件系统层次化、模块化,并且降低应用与平台之间的耦合度;不同模块来自不同的厂商,它们之间存在复杂的相互联系,要想将其整合成一个完善的系统,必须要求将所有模块的配置信息以统一的格式集中管理起来,集中配置生成系统。

    这个架构还需要具备如下功能:

    解决汽车功能的可用性和安全性需求;保持汽车电子系统一定的冗余;可以移植到不同汽车的不同平台上;实现标准的基本系统功能作为汽车供应商的标准软件模块;通过网络共享软件功能;集成多个开发商提供的软件模块;在产品生命期内更好地进行软件维护;更充分地利用硬件平台的处理能力;可实现汽车电子软件的更新和升级等。

    汽车软件中间件有什么好处?

    所有把标准统一后的服务的优势都大同小异,总结主要几点

    • 跨配置,跨车型,跨平台,跨硬件适应

    • 提高了效率,软件开发聚焦差异化

    • 软件认证有标准可依

    • 方便行业软件互换,降低进入门槛

    • 更简单的集成已有工具链,支持从设计到代码全流程

       

    对于Autosar,说实话,最有利的是OEM和基础软件公司,OEM可以标准化接口,自己做应用层或找软件公司开发应用,基础软件公司可以多卖软件。最不愿意的是tier1,因为增加了成本,还逐步可能沦为硬件生产商。但这个也不能说是autosar的锅,软件定义汽车下这个趋势的发展是必然的。

    汽车软件中间件有什么缺点?

    老实讲,这块大家讲的很少,都说这个很美好,但实际操作过程中,我觉得是软硬件一体设计上的阻碍。

    值得注意的像Tesla这样的新兴企业并没有使用autosar这是为什么?所有平台性的软件,都有一个弊病,就是为了兼容一致性,会对软硬件协作的效率带来影响,autosar也不例外。

    从商业和成本角度看

    Autosar设计上已经有些落后,代码臃肿,对成本影响很大。使用Autosar的工具链和代码臃肿带来的升级MCU开销远大于节省的这部分开发成本。细分Autosar的成本:

    1.开发成本:首先需要购买autosar,本身就是成本,autosar包含的模块多,肯定要贵,但不一定所有的都会被用上。其次是人力投入,对于一个原来就有其他平台的新的第一个项目转换到autosar是增加人力的,对于新公司,购买autosar是降低人力的,很多模块不用自己开发了。对于建立平台以后的项目,实际差不多。

    2.生产成本:首先是硬件成本,现在MCU越来越便宜,用不用autosar基本没区别,如果说存储空间特别小的MCU,比如防夹模块,本来也没要求autosar。其次是软件成本,这个才是问题,跟以前基础软件不同autosar现在收量产license费。

    从技术角度看

    关于autosar的应用,autosar之前定义的主要就是BCM、TCU、EMS、ESP等要求实时控制的ECU。不是针对娱乐系统,自动驾驶MPU的,当然这些控制器里也有MCU,可以用运行autosar的MCU。autosar现在最擅长的是16bit MCU以及不太复杂的32bitMCU。32bit以上的MCU,需要RTOS支持,比如自动驾驶软件。车的中控也不可能基于autosar,也是因为没有一个强有力的RTOS, 在越来越强调security的软件开发中,AUTOSAR也没有进程隔离的概念。前景难料.

    中间件的明星方案-AUTOSAR

    所有中间件方案中,最著名的是AUTOSAR, 其是由各大整车厂商和零部件厂商开始着手联合制定软件的标准化接口。AUTOSAR(AUTomotive Open System ARchitecture)是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业(如BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等)共同制定的汽车开放式系统架构标准。

    2003年7月,由宝马、博世、大陆、戴姆勒-克莱斯勒、西门子VDO和大众联合成立AUTOSAR发展联盟,为汽车E/E架构建立了一种开放式的行业标准。

    2003年11月,福特公司作为核心伙伴加入,12月标致雪铁龙和丰田汽车加入。接下来的11月通用汽车也作为核心伙伴加入。自从西门子VDO被大陆在2008年2月收购后,它就不再作为AUTOSAR的独立核心伙伴。

    • 第一阶段(2004-2006):标准基本开发时期(版本1.0.2.0和2.1)

    • 第二阶段(2007-2009):体系和方法相关方面扩展(版本3.0,3.1和4.0)

    • 第三阶段(2010-2013):可维护性和可选择性的改进(版本3.2,4.1和4.2)

    在2013年,AUTOSAR联盟进入一种持续改进模式,主要用来维持标准和提供所选择的改进,往后实际上,autosar更新就很少了,开始转向AUTOSAR-Adaptive。

    AUTOSAR-Adaptive拯救AUTOSAR

    对于用于实现典型动力总成和底盘功能的深度嵌入式系统,AUTOSAR经典平台仍将是首选。在低成本硬件上运行时,对安全性、实时性和确定性要求较高。同时,AUTOSAR为这些应用程序提供了一个经过良好验证的成熟软件平台,包括一个广泛使用的方法,它支持当今所有的协作模型。而为了支持客户应用程序的动态部署,并为需要高端计算能力的应用程序提供环境,AUTOSAR在2017年推出了第二个软件平台,即AUTOSAR Adaptive platform。这个想法是尽可能从其他领域(如消费电子产品)的发展中获益,同时仍然考虑汽车的特定要求,如功能安全。

    Adaptive需要支持,未来E/E架构的两个关键特征是:

    1) 异构软件平台的集成,当今汽车的网络架构可以聚集成不同的领域,用于信息娱乐和连接、底盘、动力系统等。虽然infotainment ECUs通常使用Linux、QNX或其他通用操作系统,但AUTOSAR Classic平台是深度嵌入式控制单元的标准。随着新的用例和对计算能力的深入嵌入式应用程序不断增长的需求,第三种ecu将出现,它具有不同的特性,必须集成到现有的E/E体系结构中。

    2) 面向服务和基于信号的通信,传统的汽车通信仍然是基于ecu向其他ecu提供信号广播的思想。这种范式非常适合于有限大小的控制数据,这些数据必须循环地进行通信。先进的应用程序,如高自动化驾驶与更高的负载要求,例如交换对象列表检测到的一组传感器和以太网作为一个通信系统需要更复杂的协议。面向服务通信的概念是基于在通信系统上提供服务的应用程序和订阅此服务的其他应用程序。然后数据只发送给订阅服务器。

    面向服务的通信与现有的基于信号的范式的结合是未来E/E体系结构的第二个关键方面,从这个角度来看,这是一个艰巨的挑战。

    为了解决AUTOSAR僵化的问题,Adaptive希望可以找到一种中间过程平台

    ADAPTIVE为承载这些功能的软件基础设施增加了新的需求。除了现有的需求(如功能安全和安全性),软件架构还必须支持硬件(如具有高端计算能力的硬件)、空中更新、与后端系统的通信应用程序的动态部署

    AUTOSAR Adaptive扩展了AUTOSAR平台,以满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。因此,它在许多方面改变了已建立的E/E开发过程。最重要的变化是,基于信号的通信被面向服务的设计所取代。c++取代了C语言作为自适应应用程序的编程语言,以及基于posix的操作系统(如Linux用于自适应电子控制单元)是进一步的突破性转变。

    AUTOSAR Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议,IPC等),同时提供代理(Proxy)-骨架(Skeleton)模型,该模型以C++ 面向对象语言描述,方便上层应用开发人员调用标准服务接口(API)进行开发。

    Application Design Model是该模型另一种可配置的呈现,开发人员通过使用相应的配置工具对Application Design Model进行描述和配置,即可实现基于SOA服务架构的软件落地和部署。联合电子使用AUTOSAR Adaptive组件完成SOA服务架构软件的开发

    可以看到,自适应Autosar又找到了延续自己生命的另外一个理由,提供了一种由现在信号导向的架构往SOA架构的标准。未来由于控制器数量大幅度降低, 类似特斯拉这样的车企多半是不理会自适应AutosarAdaptive

    与此同时,更多的相关配套供应商也在加快与AUTOSAR自适应平台的对接。去年11月,Real-Time Innovations(RTI)宣布,AUTOSAR最新版本的自适应平台(版本18-10),已经具有数据分发服务(DDS)标准的完整网络绑定。这意味着汽车制造商现在可以使用DDS实现AUTOSAR自适应框架,并开发高度自动驾驶系统,如4级和5级。DDS允许AUTOSAR完全支持高度自动驾驶系统,并提供“量产级通信框架”,保证这些复杂系统所需的可靠性、可伸缩性和性能。比如,在AUTOSAR中完全指定了DDS之后,汽车行业现在可以使用RTI Connext和DDS开发高性能应用程序,比如传感器融合应用程序。

    AUTOSAR版本18-10有助于解决OEM软件开发团队在支持不同价格区间车型时所面临的各种安全和连接性挑战。此外,允许开发人员“动态配置平台”,以支持每个车型平台的各种操作模式和硬件功能。

    技术细节-AUTOSAR的分层设计

    架构层面: AUTOSAR定义一个软件分层架构以支持汽车电子系统的集成。其体系架构从上至下依次为:

    • 应用层
    • 运行环境层(RTE)
    • 以及基础软件层(BSW)

     

    接着再复杂一些,BSW再分为复杂驱动模块, 微控制器抽象层、ECU抽象层、系统服务层

    (1)应用层。包括应用软件组件、传感器和执行器软件组件,都位于应用层。该层的软件组件通过RTE进行内部通讯和访问ECU资源。应用层的软件实现独立于微控制器、ECU。

    (2)RTE层。RTE层为应用层提供通讯服务。RTE层的实现与ECU和具体应用相关,必须为每个ECU分别实现,AUTOSAR软件组件之间通信需要通过RTE。

    (3)服务层。包含RTOS、通信与网络管理、内存管理、诊断服务、状态管理、程序监控等服务。它为应用和基础软件模块提供基本服务,包括:操作系统服务、汽车网络通讯和管理服务、存储服务、诊断服务和ECU状态管理。服务层的实现部分与微控制器、ECU和具体应用相关。

    (4)ECU抽象层。ECU抽象层抽象出ECU结构,如外设与ECU的联接方式等.虽然该层与ECU平台相关,但是与微控制器是无关的。这种无关性是由微控制器抽象层来实现的。其中封装了微控制器层及外围设备的驱动,并对微控制器内外设的访问进行了统一,实现了软件应用层与硬件系统的分离

    (5)微控制器的抽象层(microcontroller abstraction layer,MCAL)。位于基础软件的最底层,包含了访问微控制器的驱动(如I/O驱动、ADC驱动等),做到了上层软件与微控制器的分离,以便应用的后续的移植复用。微控制器的抽象层是实现不同硬件接口统一化的特殊层,通过微控制器的抽象层可将硬件封装起来,避免了高层软件直接与微控制器的寄存器打交道。MCAL提供消息机制,并以此将指令、响应和信息分离成不同的过程。微控制器抽象层包括微控制器相关的驱动,它负责管理微控制器的外部设备,并将微控制器的信号提供给基础软件的元件。

    (6)复杂驱动层,由于其严格的时序为应用层通过RTE访问硬件提供支持。

    再复杂一些

    再再复杂一些

     

    -------------接着我们从RTE层往上看-------------

    运行时环境( RTE )是应用软件和基础软件通信的桥梁,无论通信发生在 ECU之间( 如通过CAN、LIN、FlexRay、MOST等网络) ,还是在ECU内部,RTE均通过提供一致的接口和服务来实现SWC之间的通信抽象,其最终实现会因ECU的不同而有所差异。

    一般情况下,每一层只能使用下一层的接口,并向上一层提供服务接口。

    应用层中的功能由各软件组件(SWC)实现,组件中封装了部分或者全部汽车电子功能,包括对其具体功能的实现以及对应描述,如控制大灯,空调等部件的运作,但与汽车硬件系统没有连接。

    在设计开发阶段中,软件组件通信层面引入了一个新的概念,虚拟功能总线VFB(Virtual Functional Bus),它是对AUTOSAR所有通信机制的抽象,利用VFB,开发工程师将软件组件的通信细节抽象只需要通过AUTOSAR所定义的接口进行描述,即能够实现软件组件与其他组件以及硬件之间的通信,甚至ECU内部或者是与其他ECU之间的数据传输。

    因此软件组件只需向VFB发送输出信号,VFB将信息传输给目标组建的输入端口,这样的方式使得在硬件定义之前,即可完成功能软件的验证,而不需要依赖于传统的硬件系统。

    中间件RTE与面向对象OO(object oriented)的编程思想非常接近,所有ECU所对应的RTE都是特定的,它负责着软件构件间以及软件构件与基础软件之间的通信。对于软件构件来说,基础软件不能够直接访问,必须通过RTE进入。因而RTE也被理解成是VFB的接口实现。

     

    而构件之间及构件与基础软件的通信关系如图所示:

     

    AUTOSAR软件构件无法直接访问基础软件中的操作系统OS,因而在应用程序中就不存在「task」的概念,且不能动态创建线程,因此并行的任务由RTE直接管理调入的「构件运行实体」来实现。每个软件构件也许会有一个或者多个运行实体,但是一个运行实体只对应一个入口。

    方法学层面

    「AUTOSAR方法论」是指在汽车电子系统开发的某些步骤中所需要的通用技术方法。

    1、 但AUTOSAR方法既非完整的过程描述也不是商业模式,也没有定义「角色」和「责任」。

    2、 方法论仅是一个work-product flow,并定义了其中的依赖关系。

    根据AUTOSAR方法论,完整的基于AUTOSAR规范的配置生成过程分为以上图示两部分,即系统配置过程及ECU配置过程。两者之间并无先后关系,系统配置过程中的输入包内含有ECU配置的相关模块,ECU配置也会反馈于系统配置。

    系统配置过程:

    系统配置输入(System Configuration Input)必须被定义好,AUTOSAR倾向于通过信息交换格式(软件构件、ECU资源、系统限制)以及模版来减少这些厨师系统设计决定的正式描述。模板包含三部分:

    • 软件构件的描述:定义每个需要的软件构件的接口内容,如数据类型、端口、接口等

    • 系统约束描述:如总线信号的定义、拓扑结构与软件构件之间的映射关系

    • ECU资源描述:定义每个ECU的资源需求,如处理器、外部设备、存储器、传感器以及执行器

    配置步骤如下

    输入的系统配置文件借助配置系统(configure-system)将软件构件映射到资源与计时要求相关的ECU上,所得到的文件就是系统配置描述文件(system configuration description)。其中包含了软件构件与ECU映射时所需注意的限制条件,以及通信矩阵(Communication-Matrix),矩阵中描述了整车网络结构中的数据包内容及其时序关系。

    ECU配置过程

    系统配置完成后,生成了系统配置描述文件,作为ECU配置过程的输入。

    Extract ECU-Specific Information会负责从系统配置文件中剥离出各ECU相关的系统配置信息,如通信矩阵、拓扑结构、顶级功能组合,生成到ECU Extract of System Configuration中。

    Configure ECU的是生成包含了特定ECU局部信息的ECU Configuration Description,而这些信息可以构件该特定ECU的可执行软件。

    Generate Executable根据从ECU Configuration Description中得到的信息生成可执行程序。

     

    AUTOSAR 的特性使得当ECU底层硬件配置升级时,也并不一定要牵动其他软件系统,正因其统一的标准规范,越来越多的企业将会加入到其中,这也为未来汽车电子行业内高效管理以及复用愈加复杂的汽车软件系统奠定了基础。

    • AUTOSAR 中SWC(Software Component Description)包含下列信息: 该SWC用到或被用到的Operation和Data,SWC对基础构架(网络)和对硬件(延迟时间,定时等)的要求,SWC使用的资源 (存储器, CPU时间等),运行机制(重复率),SWC软件接口。

    • AUTOSAR中ECU Resource Description包含下列信息:描述使用到的硬件:传感器,执行器,存储器,处理器,通信外部设备(如收发器),引脚分配。

    • AUTOSAR中System Constraint Description中包含下列信息:网络拓扑,限制,协议,通信矩阵,波特率,定时,ECU映射。

    系统配置主要是将端口数据映射到通信矩阵,将SWC映射到ECU。ECU配置主要是将runnable(可运行实体)映射到task(任务)中。对以上各项内容角色分工

    接口层面:

    AUTOSAR各层软件的交互通过三类接口实现,分别是标准接口、AUTOSAR接口和AUTOSAR标准接口。其中,标准接口用于BSW各个模块之间的交互,已用C语言定义,如void Adc_Init (const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于软件构件(Software Component, SW-C)之间的交互或者软件构件和ECU硬件(IO硬件抽象、复杂设备驱动)之间的交互,这类接口命名以“Rte_”为前缀。AUTOSAR标准接口用于软件构件访问AUTOSAR服务。

    依赖这种分层架构和接口定义,AUTOSR显著提高了汽车电子嵌入式软件的复用性——层级越高者,复用性越强。值得注意的是:

    • 微控制器抽象层层级最低,随微控制器的更换而更换;

    • RTE虽然层级仅低于应用层,但由于它承担着应用层和BSW之间的桥梁作用,和硬件的耦合性最高,不具有复用性;

    • 应用层(除传感器、执行器相关的软件构件外)完全独立于硬件,具有绝对的复用性。

    AUTOSAR在定义软件架构和接口的同时。也定义了易于交换的硬件平台标准。AUTOSAR标准不仅提供了基础软件模块的规范。还提供了用于开发分布式系统应用软件的方法。这种方法以基于模型的软件和分布式系统描述开始。以自动代码生成和可重复的测试结束。

    Autosar也定义了与网络总线接口相关的模块,CAN,LIN等网络总线接口驱动、诊断等。AUTOSAR的出现使得ECU中的软件包括网络总线通信软件第三方供货成为可能。未来的网络总线标准是否仍然各自独立、互不兼容,目前还无法断定,但AUTOSAR却实实在在地将部分标准公开化、标准化,兼容化,而且实际的产品也已经被应用,AUTOSAR已对现在相互之间封闭的网络总线标准形成挑战。

    此外,AUTOSAR还定义了一套标准的软件开发流程,从系统建模到生成可执行的代码,包括软件组件设计、系统配置、ECU配置和代码生成三大流程,如图

    技术细节-AUTOSAR ADAPTIVE架构介绍

     

    展开全文
  • 中间件

    2017-11-07 18:37:41
    中间件不仅要实现互联,而且要实现应用的互操作,中间件是基于分布式处理的基础软件,远比OS平台和网络服务重要。   中间件是位于平台(硬件和操作系统)和应用之间的通用服务,如图1所示   图1 1

    中间件

    为解决分布式应用中的异构等问题

    中间件 = 平台 + 通信

    1.1 概念

    借助中间件可以在不同的技术之间共享资源,中间件位于客户机服务器的操作系统之上,管理计算资源和网络通信。中间件不仅要实现互联,而且要实现应用的互操作,中间件是基于分布式处理的基础软件,远比OS平台和网络服务重要。

     

    中间件是位于平台(硬件和操作系统)和应用之间的通用服务,如图1所示

     

    1

    1.2中间件和应用软件的区别

    中间件的设计充分考虑了通用性,并提供了标准化的程序开发接口API,能够被其它软件所调用和进行二次开发。

    1.3特点

    1满足大量应用的需要

    2运行于多种硬件OS平台 ;

    3支持分布式计算,提供跨网络、硬件OS平台的透明性的应用或服务的交互功能 ;

    4支持标准的协议

    5支持标准的接口。

    1.4中间件的基本类型

    可分为六类:1终端仿真/屏幕转换中间件、2数据访问中间件、3远程过程调用中间件、4消息中间件5交易中间件、6对象中间件。

    (1)终端仿真/屏幕转换中间件

    用以实现客户机图形用户接口与已有的字符接口方式的服务器应用程序间的互操作。

    (2)数据访问中间件

    适用于应用程序与数据源间的互操作,客户端使用面向数据库的API

    (3)远程过程调用中间件

    远程过程调用是一种广泛使用的分布式应用程序处理方法。

    RPC机制是早期开发分布式应用系统常采用的一种同步方式的请求/应答协议。

    RPC思想:把本地的过程调用扩展到分布式远端的过程,程序员编写客户端的应用,可以调用远程服务器上的过程。

    (4)消息中间件

    适用于事件驱动程的应用,当一个事件发生时,消息中间件通知服务方应该进行如何操作。

    (5)交易中间件

    针对联机交易处理系统而设计的软件。

    (6)对象中间件

    面向对象的技术通用封装、继承及多态性,提供了良好的代码重用功能。

    展开全文
  • 软件中间件(Middleware)

    千次阅读 2019-06-03 14:26:25
    中间件是位于硬件、操作系统等平台和应用之间的通用服务。借由中间件,解决了分布系统的异构问题。 通常将中间件分为数据库访问中间件、远程过程调用中间件、面向消息中间件、事务中间件、分布式对象中间件等。 一、...

    中间件是位于硬件、操作系统等平台和应用之间的通用服务。借由中间件,解决了分布系统的异构问题。
    通常将中间件分为数据库访问中间件、远程过程调用中间件、面向消息中间件、事务中间件、分布式对象中间件等。
    一、数据 库访问中间件:

    二、远程过程调用中间件(Remote Procedure Call,RPC):是一种分布式应用程序的处理方法。

    三、面向消息中间件(Message-Oriented Middleware,MOM):利用高效可靠的消息传递机制进行平台无关的数据传递,并可基于数据通信进行分布系统的集成。
    随着计算机网络和分布式应用的不断发展,远程消息传递越来越成为应用系统中不可缺少的组成部分。商业消息中间件的出现保证了消息传输的可靠性,高效率和安全性,同时也减少了系统的开发周期。目前应用最多的消息中间件产品为IBM MQSeries。

    四、分布式对象中间件:

    五、事务中间件:

    展开全文
  • 中间件是位于平台(硬件和操作系统)和应用之间的通用服务。 为什么要使用中间件呢?具体地说,中间件屏蔽了底层操作系统的复杂性,使程序开发人员面对一个简单而统一的开发环境,减少程序设计的复杂性,将...
  • **中间件是一类连接软件组件和应用的计算机软件,它包括一组服务。**以便于运行在一台或多台机器上的多个软件通过网络进行交互。该技术所提供的互操作性,推动了一致分布式体系架构的演进,该架构通常用于支持并简化...
  • 所有的技术分为两个,就是硬件软件,硬件就是CPU和内存和磁盘还有一些网络相关东西,这是硬件,一台电脑电脑不管用什么软件,最终都是利用这些硬件的资源去解决对应问题,cpu去做运算,内存做存储,磁盘做存储,网络做通讯 ...
  • 中间件是什么,常用的中间件有哪些

    万次阅读 多人点赞 2020-11-16 20:42:09
    中间件(英语:Middleware)顾名思义是系统软件和用户应用软件之间连接的软件,以便于软件各部件之间的沟通,特别是应用软件对于系统软件的集中的逻辑,是一种独立的系统软件或服务程序,分布式应用软件借助这种软件...
  • 什么是中间件

    2021-06-15 22:21:07
    中间件(英语:Middleware)顾名思义是系统软件和用户应用软件之间连接的软件,以便于软件各部件之间的沟通,特别是应用软件对于系统软件的集中的逻辑,是一种独立的系统软件或服务程序,分布式应用软件借助这种软件...
  • 中间件软件技术规格要求

    千次阅读 2016-04-18 11:06:05
    ★请提供单机和多机环境下的业界公开基准测试值(SPEC jAppServer2004)及其软硬件环境报告 群集和可用性 支持多种平台环境下的群集( Windows 、Unix、OS/390等) ★支持...
  • 2013年,新年伊始。进入软件行业多年,根据自己工作的实践...有了计量中间件,计量终端的软件开发就可以面向中间件开发,不需要涉及操作系统和硬件。同时可以在WINDOWS下做一个强大的模拟器,将计量终端的功能在模拟器
  • 第五章 中间件与分布式软件架构

    千次阅读 2015-01-27 20:51:16
    1)能屏蔽下层软件硬件的复杂性(包括异构性),从而简化分布式应用系统的设计与开发过程,提高效率,降低应用系统的获取成本 2)能扮演“专家”的角色,承揽解决系统架构中与“分布式”三个字关系比较密切的问题...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 40,298
精华内容 16,119
关键字:

中间件是软件还是硬件