欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 房产 > 建筑 > 【AUTOSAR标准文档】AotuSar结构横向分层详解(RTE、BSW)

【AUTOSAR标准文档】AotuSar结构横向分层详解(RTE、BSW)

2024/10/24 6:58:00 来源:https://blog.csdn.net/weixin_66400112/article/details/143030562  浏览:    关键词:【AUTOSAR标准文档】AotuSar结构横向分层详解(RTE、BSW)

Top view

The AUTOSAR Architecture distinguishes on the highest abstraction level between three software layers: Application, Runtime Environment and Basic Software which run on a Microcontroller.

译文:AUTOSAR架构在最高抽象层次上将软件分为三层:运行在微控制器上的应用层、运行环境层和基础软件层。

Coarse view

The AUTOSAR Basic Software is further divided in the layers: Services, ECU Abstraction, Microcontroller Abstraction and Complex Drivers. 

译文: AUTOSAR基础软件进一步细分为以下几个层次:服务层、ECU抽象层、微控制器抽象层和复杂驱动层。

 The Basic Software Layers are further divided into functional groups. Examples of Services are System, Memory and Communication Services.

译文:基础软件层进一步被划分为不同的功能组。服务的例子包括系统服务、内存服务和通信服务。

Detailed view 

Microcontroller Abstraction Layer

The Microcontroller Abstraction Layer is the lowest software layer of the Basic Software.

It contains internal drivers, which are software modules with direct access to the µC and internal peripherals.

Task

Make higher software layers independent of µC

Properties

Implementation: µC dependent Upper

Interface: standardized and µC independent 

译文:

微控制器抽象层是基础软件的最低层。

它包含内部驱动程序,这些驱动程序是能够直接访问微控制器(µC)及其内部外设的软件模块。

任务

使更高的软件层与微控制器(µC)保持独立。

特性

  • 实现:依赖于微控制器(µC)的上层(此处“Upper”可能指的是该层之上的软件层或接口,即该层的实现是依赖于µC的,但其为上层提供了与µC无关的接口)。

注意:在“Properties”下的“Implementation: µC dependent Upper”这句话中,“Upper”一词可能有些含糊,因为通常我们不会这样描述一个层的实现。但根据上下文,这里可能是指该层(微控制器抽象层)的实现是依赖于微控制器的,并且它为上层软件提供了与微控制器无关的接口。为了更准确地表达,我们可以稍作调整,但保留原意:该层的实现依赖于微控制器,但其提供的接口是标准化的,与微控制器无关。 

ECU Abstraction Layer

The ECU Abstraction Layer interfaces the drivers of the Microcontroller Abstraction Layer. It also contains drivers for external devices. 

It offers an API for access to peripherals and devices regardless of their location (µC internal/external) and their connection to the µC (port pins, type of interface)

Task

Make higher software layers independent of ECU hardware layout

Properties

Implementation: µC independent, ECU hardware dependent Upper

Interface: µC and ECU hardware independen

译文:

ECU抽象层与微控制器抽象层的驱动程序进行接口连接,并且它还包含用于外部设备的驱动程序。

它提供了一个应用程序接口(API),用于访问外设和设备,无论这些外设和设备位于何处(微控制器内部/外部)以及它们与微控制器的连接方式(端口引脚、接口类型)如何。

任务

使更高的软件层独立于ECU硬件布局。

特性

  • 实现:与微控制器无关,但与ECU硬件相关(上层,即该层之上的软件层或接口与该层提供的接口进行交互时,无需关心ECU硬件的具体实现)。
  • 接口:与微控制器和ECU硬件无关(即该层提供的接口是标准化的,不依赖于特定的微控制器或ECU硬件)。

注意:在描述软件架构时,“实现”通常指的是软件层或组件的具体实现方式,而“接口”则指的是这些层或组件之间如何进行交互的规范或协议。在这里,“实现:µC independent, ECU hardware dependent Upper”意味着ECU抽象层的实现不依赖于特定的微控制器,但确实依赖于ECU硬件的某些方面(例如,ECU上的外设和设备的类型、连接方式等)。同时,“接口:µC and ECU hardware independent”则表明该层提供的接口是标准化的,不依赖于特定的微控制器或ECU硬件,从而允许更高的软件层以统一的方式与外设和设备进行交互。

Complex Drivers

The Complex Drivers Layer spans from the hardware to the RTE. 

Task

Provide the possibility to integrate special purpose functionality, e.g. drivers for devices:

① which are not specified within AUTOSAR,

② with very high timing constrains or

③ for migration purposes etc.

Properties

Implementation: might be application, µC and ECU hardware dependent Upper

Interface: might be application, µC and ECU hardware dependent

译文:

复杂驱动层跨越硬件到运行时环境(RTE)的范围。

任务

提供集成特定功能(例如设备驱动程序)的可能性,这些设备包括:

① 在AUTOSAR规范中未指定的设备,

② 具有极高时间约束的设备,

③ 或出于迁移目的等所需的设备。

特性

  • 实现:可能依赖于应用程序、微控制器(µC)和ECU硬件(上层,即该层之上的软件层或接口与该层提供的接口进行交互时,可能会受到应用程序、微控制器和ECU硬件的影响)。
  • 接口:可能依赖于应用程序、微控制器(µC)和ECU硬件(即该层提供的接口可能会因应用程序、微控制器和ECU硬件的不同而有所变化)。

需要注意的是,复杂驱动层的存在是为了处理那些不在AUTOSAR标准范围内的、具有特殊需求的设备。因此,它的实现和接口可能会更加灵活,以适应这些特殊设备的需求。同时,这也意味着在使用复杂驱动层时,需要更加谨慎地考虑其与其他软件层之间的交互和依赖关系。

 Services Layer

The Services Layer is the highest layer of the Basic Software which also applies for its relevance for the application software: while access to I/O signals is covered by the ECU Abstraction Layer, the Services Layer offers: 

① Operating system functionality

② Vehicle network communication and management services

③ Memory services (NVRAM management)

④ Diagnostic Services (including UDS communication, error memory and fault treatment)

⑤ ECU state management, mode management

⑥  Logical and temporal program flow monitoring (Wdg manager) 

Task

Provide basic services for applications, RTE and basic software modules.

Properties

Implementation: mostly µC and ECU hardware independent Upper Interface: µC and ECU hardware independent

译文:

服务层是基础软件的最高层,同时也因其对应用软件的重要性而备受关注。虽然ECU抽象层负责处理I/O信号的访问,但服务层则提供了以下功能:

① 操作系统功能

② 车辆网络通信和管理服务

③ 内存服务(NVRAM管理)

④ 诊断服务(包括UDS通信、错误内存和故障处理)

⑤ ECU状态管理、模式管理

⑥ 程序流程的逻辑和时间监控(看门狗管理器)

任务

为应用、运行时环境(RTE)和基础软件模块提供基本服务。

特性

  • 实现:大多与微控制器(µC)和ECU硬件无关(上层,即该层之上的软件层或接口与该层提供的接口进行交互时,无需关心微控制器和ECU硬件的具体实现)。
  • 接口:与微控制器(µC)和ECU硬件无关(即该层提供的接口是标准化的,不依赖于特定的微控制器或ECU硬件)。

服务层作为基础软件的顶层,为应用软件和其他软件组件提供了必要的服务和支持,确保了整个AUTOSAR架构的稳定性和可靠性。

AUTOSAR Runtime Environment (RTE)

The RTE is a layer providing communication services to the application software (AUTOSAR Software Components and/or AUTOSAR Sensor/Actuator components). 

Above the RTE the software architecture style changes from “layered“ to “component style“.

The AUTOSAR Software Components communicate with other components (inter and/or intra ECU) and/or services via the RTE.

Task

Make AUTOSAR Software Components independent from the mapping to a specific ECU.

Properties

Implementation: ECU and application specific (generated individually for each ECU)

Upper Interface: completely ECU independent

译文:

运行时环境(RTE)是一个为应用软件(AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件)提供通信服务的层。

在RTE之上,软件架构风格从“分层式”转变为“组件式”。

AUTOSAR软件组件通过RTE与其他组件(ECU内部和/或ECU之间)和/或服务进行通信。

任务

使AUTOSAR软件组件独立于特定ECU的映射。

特性

  • 实现:针对ECU和应用具有特异性(为每个ECU单独生成)。
  • 上层接口:完全独立于ECU。

运行时环境(RTE)作为连接AUTOSAR软件组件与底层硬件及服务的桥梁,确保了软件组件的可移植性和可重用性。通过RTE,软件组件可以在不同的ECU上运行,而无需关心底层硬件的具体实现,从而提高了软件开发的效率和灵活性。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com