ortcc系统（ouac系统）



  本文旨在对《汽车嵌入式系统手册》进行速读，粗略了解基本概念。以便在后续需要的时候加以详细理解。

  分为“以车为中心”的功能域，如动力总成控制、底盘控制、主动或被动安全系统，和“以乘客为中心”的功能域，如多媒体/车载信息服务、身体/舒适和人-机界面（HMI）。

  域被定义为“一个包含知识、影响范围和活动的球体， 其中有一个或多个系统待处理（例如待建立）。” 域这个术语可以被用来作为一种手段，把机械系统与电子系统组合起来。

五个域：

• 动力总成域与参与车辆纵向推进的系统有关， 包括发动机、变速器和所有所属部件。一方面， 控制器根据自然因素（如气流的温度、氧气水平等） 动作； 另一方面， 根据给环境带来的扰动（如噪声、排气污染等） 动作。
• 底盘域是指四个车轮和它们的相对位置与运动；在这个域中，系统主要控制转向和制动。控制器考虑驾驶人发出的请求（转向、制动或加速指令）、道路轮廓和环境条件（如风向、风速等）， 它们必须保证驾驶人和乘客的舒适性（悬架） 以及他们的安全。这个域包括的系统有ABS、ESP、自动稳定控制系统（ASC） 和四轮驱动（4WD）。底盘域对于乘客及车辆本身的安全来说极其重要。
• 车身域包括不属于车辆动力学的实体，是那些方便汽车用户使用的部件，如安全气囊、刮水器、照明、车窗升降器、空调和座椅等设备。下图给出一个示例。

• 人机界面（HMI）域包括允许电子系统和驾驶人交换信息的设备（显示器和开关）。
• 车载信息处理域是允许车辆和外界交换信息的相关组件（如收音机、导航系统、互联网接入和支付系统等）。

  新的车载嵌入式系统的设计是基于一个协作式的研发流程。因此， 它必须保证不同合作方开发的组件之间的互通性， 并便于移植到不同的平台以提高系统的灵活性。一方面， 达到这些目标的一种手段是由应用流程之间共享硬件资源的服务标准化， 特别是网络协议和操作系统。另一方面， 可移植性是通过规范一个通用的中间件来实现的。

一些标准化的组件或模型：

• 车载网络和协议 —— A、B、C类对应低中高速
• 操作系统
• 中间件——中间件(middleware)是基础软件的一大类，在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。在不同的技术之间共享资源并管理计算资源和网络通信。
• 汽车应用中的架构描述语言——在车载嵌入式系统设计中涉及的这些不同的合作伙伴之间共享相同的建模语言是支持有效协同开发过程的一种手段。

/

• 由于更多电子控制单元(ECU)复杂性的增加及共享软件和功能的增长。
• ECU 硬件和网络[控制器局域网络（CAN）、本地互联网络（LIN）、FlexRay、MOST 等] 的更多多样性。
• ECU之间的交流越来越多，但它仍然是非结构化的
• 以前软件结构的缺点：
  • 没有合适的抽象层
  • 很多功能是分布在多个ECU上的，例如，在高端车辆上，用于控制指示器信号灯的软件分布在多达八个ECU上。
• 目标：
  • “在标准上合作，在实施中竞争”
  • AUTOSAR 严格的基于组件的方法的最重要的结果（涉及研发流程），就是应用研发从较低水平的集成研发中分离出来——应用软件（BSW）。这两个部分之间的分界线就是AUTOSAR运行环境（RTE）。
• 工作方法：
  • 尽可能利用现有解决方案，例如CAN、LIN等，或者建立与其他标准化组织的合作，如Flexray等；而非试着发明创造新的解决方案。

  以一个示意性的软件体系架构为例：

  有两种类型的接口：“发送/接收接口”和“客户端/服务器接口”。发送/接收接口支持基于信息的通信（由一系列数据元素组成），而客户端/服务器接口支持远程过程调用方式的通信（由一列操作组成，每个操作都有一个签名——包括一个名称和参数列表）。

  软件架构的定义是在不考虑硬件上运行的软件组件情况下进行的。这意味着两个软件组件可以运行在相同或不同的ECU上。那么组件之间的通信既可以是内部的ECU通信，也可以是跨ECU通信。为了抽象化这一差异， AUTOSAR推出了VFB。VFB可以看成连接所有组件的一个软件总线。

  AUTOSAR 定义了针对ECU 的软件架构。这种架构是以分层的方式来定义。

• 该架构的最底层———微控制器抽象层（MCAL）。
• 在MCAL上面，有ECU抽象层（ECU-AL）。
• 除了ECU-AL之外，服务层提供额外的服务，如非冲突的随机存取存储器（NVRAM） 管理器和诊断事件管理器（DEM）。AUTOSAR 操作系统（AUTOSAR OS）也是服务层的一部分。为了管理，AUTOSAR OS必须能够访问硬件，例如针对时间片段调度的计时器。

BSW

RTE

  前面提到了「如果将ASW视为应用程序，那BSW就就可以视为安卓系统（并不严谨）」，在非AUTOSAR的应用中，ASW通常直接采用操作系统服务（如激活一个任务），或直接发送或接收CAN 信息。但在AUTOSAR中，RTE不仅仅是一个抽象层。ASW组件根本不知道操作系统任务的概念或CAN信息。同样，没有这些概念和AUTOSAR之间的一对一映射。

  RTE采用BSW是为了通过指定的接口和运行的实体来实现ASW组件的特性。这包括两项主要任务：实现通信和实现运行实体的激活。

  生成RTE，总是只提供给定配置所需的功能而已。生成过程有两个阶段：

• 合约阶段
• 生成阶段

  AUTOSAR是(追求精确的技术目标来管理未来)的软件架构。其中的一些目标为：

• 在网络内部， 功能从一个ECU 中移植到另一个ECU 上。
• 集成来自多个供应商的功能模块。
• 复用经过验证的解决方案（硬件和软件）
    为了达到这些目标， AUTOSAR引入了由元模型定义的一个标准化架构。AUTOSAR 系统中的一切都需要采用标准化的模型元素来描述。

这书翻译的太烂了，我感觉看起来都得通过语法分析中文……然后发现果然是中文语法不通……

  写几个有意思的点吧，这章很多地方没啥笔记的意义。

  该系统可以激活和松开每个制动器50次/s。这种精细控制使每个轮胎获得最优纵向和令人满意的横向附着，制动距离最小化，而操纵性又可以接受。ABS 控制算法保证功能点保持在如图3.5 所示的边界A和B之间。当制动启动时，车辆动力学和摩擦定律快速滑过工况点（从O 到S点），导致最后50% 制动力系数和100%滑移率（车轮被抱死）。如果松开制动踏板，那么滑移是逐步减少到零的。如果存在足够的启动恢复率，那么制动效果可以保持在一个较高的水平。

  几个关键词吧，重点就是那张ECU软件架构图；整体比较抽象，加之翻译的很烂，阅读体验很差。本文完成了第一部分的阅读，还有二三四三部分，有空的时候我会速速刷过。后续还有《Automotive Software Architectures》和《汽车以太网》两本相关的书籍要读。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/77773.html