登陆
注册
首页> 问答> AUTOSAR与OSEK的区别与联系...

AUTOSAR与OSEK的区别与联系...

来源：汽车功能安全公众号
2020-05-10
0
0
0
AUTOSAR与OSEK



内容提要


  1. AUTOSAR与OSEK的简介

  2. AUTOSAR与OSEK的关系

  3. AUTOSAR和OSEK网络管理比较

  4. 汽车用OSEK OS学习笔记

  5. 相关资料下载




壹

AUTOSAR与OSEK的简介


AUTOSAR标准


    2003年行业内的几大巨头（包括BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, Siemens VDO）联合建立了AUTOSAR联盟，目的是一起开发并建立一套真正的开放的汽车电子电器架构（也就是我们现在所说的AUTOSAR标准或者AUTOSAR架构，AUTOSAR的全称是AUTomotive Open System ARchitecture），随着多年的发展，越来越多的行业内的公司加入到了AUTOSAR联盟中，这其中有OEM（汽车整车厂），Tier1（汽车零部件供应商），芯片制造商以及工具制造商，AUTOSAR构架/标准也成为了汽车E/E设计的发展方向。


AUTOSAR标准核心内容

  • ECU软件构架；
  • 软件组件（software components）；
  • 虚拟功能总线（Virtual Functional Bus）；
  • AUTOSAR设计方法（Methodology）。

更多AUTOSAR介绍，参考文末的下载学习资料：

OSEK/VDX标准

    1993年德国汽车工业界提出了OSEK(德文:Offene Systeme and deren Schnittstellen fur dieElektronik im Kraftfahr-zeug)体系，其含义是汽车电子开放式系统及其接口。这个体系的最早倡导者有：宝马、博世、戴姆勒克莱斯勒、欧宝、西门子、大众和卡尔斯鲁厄大学的工业信息技术研究所。法国的汽车制造商标致和雷诺于1994年加人了OSEK体系，并将法国汽车工业使用的汽车分布式运行系统(Vehicle Distributed eX-ecutivr, V DX)也纳人这一体系，VDX的作用与OSEK相似。


    在1995年召开的研讨会上，众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)。它主要由四部分组成：操作系统规范(OSEK Operating System，OSEK OS)、通信规范(OSEK Communication，OSEK COM )、网络管理规范( OSEK Net Management，OSEK NM)和OSEK实现语言(OSEK Implementation Language，OIL)。


    从此之后，各嵌入式OS厂商都相继推出了符合OSEK规范的产品，比较典型的有WINDRIVER公司的OSEKWorks，ETAS公司的RTA-OSEK，MOTOROLA的OSEKturbo和美国密西根大学的EMERALDS-OSEK等。随着该规范应用的不断深人，其结构和功能不断完善和优化，版本也不断升级和扩展。


更多OSEK介绍，参考文末的下载学习资料：






贰

AUTOSAR与OSEK的关系


      AUTOSAR与OSEK二者都是汽车电子软件的标准。OSEK/VDX是基于ECU开发的操作系统标准，AUTOSAR基于整体汽车电子开发的功能标准。AUTOSAR中规定的操作系统标准就是基于OSEK/VDX，通信和网络管理虽然和OSEK有区别，但是是有继承性的。可以认为，AUTOSAR是基于OSEK/VDX发展出来的，OSEK/VDX被AUTOSAR标准软件架构所包含。


一、AUTOSAR


现在的汽车正向着更高的安全性、经济环保性、舒适性、便捷性发展，从而为汽车电子系统带来了前所未有的复杂性，因为需求越来越多，更多的数据需要在整车电子系统中被处理被传递，据统计，在现代的汽车上平均每台车有25个以上的ECU（电子控制单元），在高端车型中甚至有超过100个ECU，更不用说未来还要迎接车联网的挑战。


汽车行业中的从业人员在很早的时候就预测到了这样的发展趋势，他们在很早的时候就在思考怎么应对复杂的电子系统设计，怎么能够让汽车电子系统开发更灵活，更有效率。在2003年的时候，行业内的几大巨头（包括BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, Siemens VDO）联合建立了AUTOSAR联盟，目的是一起开发并建立一套真正的开放的汽车电子电器架构（也就是我们现在所说的AUTOSAR标准或者AUTOSAR架构，我们经常提到的AUTOSAR一般就是指AUTOSAR构架/标准，AUTOSAR的全称是AUTomotive Open System ARchitecture），随着多年的发展，越来越多的行业内的公司加入到了AUTOSAR联盟中，这其中有OEM（汽车整车厂），Tier1（汽车零部件供应商），芯片制造商以及工具制造商，AUTOSAR构架/标准也成为了汽车E/E设计的发展方向。AUTOSAR架构和标准的目标是：


  • 满足未来汽车的需求，例如可用性和安全性、软件升级更新需求、可维护性等

  • 增加软件的灵活性和可扩展性来实现软件的集成和整合

  • 实现商用现成的跨产品线的软件硬件

  • 控制产品和流程的复杂度和风险

  • 优化成本


AUTOSAR架构的主要特点是：


1、模块化和可配置性 
定义了一套汽车ECU软件构架，将不依赖硬件的软件模块和依赖硬件的软件模块分别优雅的封装起来，从而可以让ECU可以集成由不同供应商提供的软件模块，增加了功能的重用性，提高了软件质量。软件可以根据不同的ECU功能需求和资源情况进行灵活配置。


2、有标准化接口 
定义了一系列的标准API来实现软件的分层化。


3、提出了RTE的概念 
RTE全称是Runtime Environment，采用RTE实现了ECU内部和ECU之间的节点通讯，RTE处于功能软件模块和基础软件模块之间，使得软件集成更加容易。


4、具有标准的测试规范 
针对功能和通讯总线制定了标准的测试规范，测是规范涵盖的范围包括对于AUTOSAR的应用兼容性（例如RTE的需求，软件服务行为需求和库等）和总线兼容性（总线处理行为和总线协议等），它的目标是建立标准的测试规范从而减少测试工作量和成本。


AUTOSAR标准有四个核心内容：ECU软件构架，软件组件（software components），虚拟功能总线（Virtual Functional Bus），AUTOSAR设计方法（Methodology）。


二、OSEK


1、OSEK 简介


随着社会的进步和汽车工业的飞速发展，汽车在降低能耗、提高安全性和舒适度以及环保等方面的要求越来越高。这些要求刺激了电了技术在汽车上的应用，而且比重不断增加，其结果是汽车在零部件控制技术、通信和网络方面的复杂性大大增加。在这个强大的市场需求和激烈竞争的环境下，汽车电子的软硬件产品不断发展并出现多元化格局。


这时一些问题凸显出来，比如，由于处理器( CPU)不断升级导致不同的CPU间的软件移植滞后，由于不同实时操作系统的应用程序接口(API)不同，导致应用程序的移植性差等。为了改变这种状况，1993年德国汽车工业界提出了OSEK(德文:Offene Systeme and deren Schnittstellen fur die Elektronik im Kraftfahr-zeug)体系，其含义是汽车电子开放式系统及其接口。这个体系的最早倡导者有：宝马、博世、戴姆勒克莱斯勒、欧宝、西门子、大众和卡尔斯鲁厄大学的工业信息技术研究所。法国的汽车制造商标致和雷诺于1994年加人了OSEK体系，并将法国汽车工业使用的汽车分布式运行系统(Vehicle Distributed eX-ecutivr, VDX)也纳人这一体系，VDX的作用与OSEK相似。


在1995年召开的研讨会上，众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)，本文简称OSEK规范。它主要由四部分组成:操作系统规范(OSEK Operating System,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。此后，各软件生产厂商都相继推出了符合OSEK规范的产品，比较典型的有WINDRIVER公司的OSEKWorks ,ETAS公司的ERCOSEK,MOTOROLA的OSEKturbo和美国密西根大学的EMERALDS-OSEK等。随着该规范应用的不断深人，其结构和功能不断完善和优化，版本也不断升级和扩展。目前OSEK OS2. 2 , OSEK COM2. 3 , OSEK NM2. 3和OIL2. 3已经提交ISO审议，即将成为一个国际标准。


2、OSEK OS的特点


OSEK规范为实现其制定的初衷并满足汽车控制领域对系统安全性和节省有限资源的特殊要求，制定了系统而全面的操作系统规范。其特点主要有以下几个方面。


2.1 实时性 
由于越来越多的微处理器被应用到汽车控制领域，如汽车刹车的防抱死系统、动力设备的安全控制等这些系统直接关系着人的生命安全，即使出现丝毫的差错也会导致危及生命安全的严重后果，因此要求操作系统具有严格的实时性。OSEK操作系统通过静态的系统配置、占先式调度策略、提供警报机制和优化系统运行机制以提高中断响应速度等手段来满足用户的实时需求。


2.2 可移植性 
OSEK规范详细规定了操作系统运行的各种机制，并在这些机制基础上制定了标准的应用程序编程接口，使那些独立编写的代码能够很容易地整合起来，增强了应用程序的可移植性。OSEK还制定了标准的OIL，用户只需更改OIL配置文件中与硬件相关部分，便可实现不同微处理器之间的应用程序移植。通过这些手段，减少了用于维护应用程序软件和提高它的可移植性的花费，降低了应用程序的开发成本。


2.3 可扩展性 
为了适用于广泛的目标处理器，支持运行在广泛硬件基础上的实时程序，OSEK操作系统具备高度模块化和可灵活配置的特性。它定义了不同的符合级别( Conformance Classes)，并采用对不同应用程序有可靠接收能力的体系结构，从而增强了系统的可扩展性。OSEK操作系统可以在很少的硬件资源(RAM,ROM,CPC时间)环境下运行，即便在8位微处理器上也是如此。


由上我们可以看出，AUTOSAR与OSEK二者都是汽车电子软件的标准。OSEK基于ECU开发，AUTOSAR基于整体汽车电子开发。AUTOSAR中规定的操作系统就是OSEK，而通信和网络管理虽然和OSEK有区别，但思路一样的。所以认为，AUTOSAR是基于OSEK提出的（但不仅基于OSEK），OSEK被AUTOSAR标准软件架构包含。

叁

AUTOSAR和OSEK网络管理比较


一、共同点：

1. 都属于直接网络管理。
2. 网络管理的目的都是协调各节点同步进入休眠及唤醒（主要是休眠）。

3. 都依靠特定的网络管理CAN报文，每个节点的网络管理ID都不一样。

4. 唤醒方法相同，第一个唤醒的节点发送网络管理帧即同时唤醒其它节点。

 


二、不同点：

1. 唤醒帧类型不一样：


网络唤醒后，OSEK要求节点发出的第一帧必须是Alive类型，不能是Ring, Limphome等。AutoSar只要求是网络管理帧就行，条件宽松。


2. 休眠的同步算法不一样：


    OSEK网络管理使用令牌环机制，令牌从网络地址低的节点传到网络地址高的节点，如果没有更高的节点，就传给最低地址节点。令牌环根据ECU的网络地址建立。每个ECU都会接受网络管理消息，只有和目的地址相同的一个节点才会得到令牌。


  • 唤醒后建立逻辑环过程：


   1) 控制器唤醒后想参与网络的节点会先发Alive报文申请加入逻辑环。
   2)逻辑环建成后，各节点按顺序发Ring报文向后续节点传递“令牌”。

  • 同步休眠过程：


   1)如果逻辑环中有节点想休眠，就设置Ring报文中的Sleep.Ind指示位。


   2)当逻辑环中所有的节点都设置了Sleep.Ind指示位，也意味着任何节点接收到所有其它节点的Sleep.Ind指示位。


   3)逻辑环中所有的节点设置Sleep.Ack指示位


   4)任何节点接收到所有其它的节点的Sleep.Ack指示位


   5)所有节点同步进入等待睡眠状态


   6)tWaitBusSleep时间内没有收到唤醒时间，所有节点同步进入睡眠状态。



     AutoSar基于分布式策略，每个节点根据通信系统中发送或者接收到的NM消息来执行自给自足的网络活动。NM消息通过广播发送，所有网络中的所有节点都可以接收到。接收到NM消息表示发送这个NM消息的节点倾向保持网络工作模式（NETWORK MODE）。如果有节点准备好进入总线睡眠模式 （BUS SLEEP MODE），它就停止发送NM消息，但是只要它还能够接收到从其他节点发来的NM消息，它就延迟到总线睡眠模式的变迁。最终，在一定的时限内，由于不再接收到NM消息，每个节点都启动到总线睡眠模式的变迁。如果网络中的任何节点需要总线通信，它可以通过发送NM消息使网络从来总线睡眠模式中唤醒。概括如下：


1) 每个网络节点如果想保持总线通信，就会一直发送周期性的NM消息；如果它不再需要保持总线通信，它就不再发送NM消息。2) 如果总线通信已经被释放，并且在配置的一段时间内没有发送或者接收到NM消息，则执行到Bus-Sleep模式的转移。


 


2). PDU结构不一样


OSEK网络帧PDU包括自己地址，目标地址（下一个令牌环目标），命令状态，用户选择数据。而AutoSar网络帧PDU只包括自己地址，少量控制信息，用户选择数据。内容简单的多。





三、小结：

1. OSEK同步休眠时刻是所有节点都发送Ring请求休眠帧，且收到其它节点的Ring确认休眠帧。而AutoSar的同步休眠时刻是所有节点都停发NM帧，且不能收到其它节点的NM帧。比较而言，AutoSar要简单一些。


2. OSEK令牌环中有一个节点异常，其它节点就要重新建立环才能维持正常网络状态，策略比较复杂。而AutoSar网络管理中，一个节点异常时不影响其它节点的网络状态。比较而言，AutoSar要简单一些。

更多OSEK网络管理规范的介绍，参考文末的下载学习资料：



肆

汽车用OSEK OS学习笔记


一、 Introduction


 1 System philosophy

 Event driven control systems. 
 the basis platform that integration all kinds of modules. 
    根据性能和最低resource原则完成features, 不需要100%匹配，portability 优先.  支持 time-critical 各类应用。高模块化和多配置以便低端CPU和复杂控制单元。在"conformance classes" 定义。 因为 time-critical，不在动态生成内核单元. 内核单元在 system generation phase 产生. 在不影响系统整体速度时， 避免大范围Error inquiries, Error inquiries用于 测试阶段，少time-critical的应用，甚至uniform system appearance is  ensured阶段.


 标准接口：

 应用层和OS的接口定义。系统服务使用 ISO/ANSI-C-like syntax 说明。
 
 可裁剪 Scalability：

 不同的 conformance classes, 几种调度机制和可配置使得 OSEK os 可用于 a broad spectrum of applications and hardware. 最小硬件资源需求(RAM, ROM, CPU time) ，可以在 8 bit microcontrollers 上运行.


   目标代码并没有定地址。
   portable description language: Oil，"tasks" and "alarms" 。


  Port化 APP 需要考虑 开发过程's characteristics, 开发环境, ECU构架: 
   •  软件开发手册
   • 文件管理系统
   • Data allocation and stack usage of the compiler 
   • ECU 的内存结构
   • ECU 的 Timing
   • Mcu interfaces e.g. ports, A/D converter, serial communication and watchdog timer 
   • API calls 的 Placement。


  这说明 OSEK spec 不足以描述所有的 OSEK implementation. The implementation shall supply specific documentation.


  Portability 支持：
  在 Chapter 14 说明了提高在不同的OSEK APP间提高portability的细节这个文档只考虑 接口。


  汽车上的特别需求：
  Reliability, real-time capability, and cost sensitivity:
   • OSEK os ，scaled statically. Tasks, resources . 
   • Running on ROM. 
   • app portability. 
   • predictable and documented behaviour of os implementations. 
   • The implementation of predictable performance parameters. 

 2 Purpose of this document


 3 Structure of this document


  Chapter 2, Summary OSEK os concept. 
  Chapter 3, Architecture of the OSEK os the design principles, the architecture.
  Chapter 4, Task management 
  Chapter 5, Application modes and how they are supported. 
  Chapter 6, Interrupt processing 
  Chapter 7, Event mechanism 
  Chapter 8, Resource management 
  Chapter 9, Alarms
  Chapter 10, Messages 
  Chapter 11, Error handling, tracing and debugging
  Chapter 12, Description of system services
   This chapter describes the conventions协定 used for description. 
  Chapter 13, Specification of operating system services describes all operating system services made available to the user. 
   Structure of the description is identical for any service; all the information the service user requires. 
  Chapter 14, Implementation and application specific topics, Provides a list of all operating system specific topics, including services, data types, and constants.
  Chapter 15, Changes from specification 1.0 to 2.Provides a survey of major changes in the operating system specification from version 1.0 to version 2.0,    2.1, 2.1r1 and 2.2. 
  Chapter 16, Index  List of all operating system services and figures. 
  Chapter 17, History List of all official releases.


二、 Summary 摘要

1, Provides a pool of different services and processing mechanisms. 
2, Built according to the user's configuration instructions at system generation time. 
3, Four conformance classes: satisfy different requirements(concerning functionality and capability of OS). 
         User can adapt the operating system to the control task and the target hardware.  The operating system cannot be modified later at execution time. 
4, Applications(conformance class) portable to OSEK class. This is ensured by a definition of the services,their scope of capabilities, and the behaviour of each conformance class. Only all the services of a conformance class are offered with the determined scope of capabilities, the operating    system implementation conforms to OSEK.  The service groups are structured in terms of functionality.


 Task management：
  different task types, scheduling mechanisms. 
  • 开始和中止一个任务。
  • 任务状态管理，任务切换


 Task Synchronisation：
  Two means of synchronisation effective on tasks: 
  • Resource management： 
   Access control for inseparable operations to jointly used(logic)           resources or devices, or for control of a program flow. 
   discusses the benefits and OSEK priority ceiling protocol. 
  • Event control：    
   Event management for task synchronisation. the different behaviour depending on the scheduling.
  • Services for interrupt processing 
  • Relative and absolute alarms，两级原理, 支持基于时间的事件(e.g. hardware-timer)和非基于时间的events (角度测量). 
  • Services for exchange of data，intra processor communication.
  • Mechanisms supporting the user in case of various errors 
  the mechanisms to achieve centralised error handling.
  the services to initialise and shutdown the system.


三、 Architecture

 1 Processing levels
  Basis serves for app independent, and provides their environment on one processor. 
  Defined set of interfaces. two types of entities: 
   • Interrupt service routines managed by the operating system 
   • Tasks (basic tasks and extended tasks) 
  Hardware resources can be managed by services. These services are called by a unique interface, 
  either by app or internally within the operating system. 
  OSEK defines three processing levels: 
   • Interrupt level 
   • Logical level for scheduler 
   • Task level 
    tasks are scheduled (non, full or mixed preemptive scheduling) according to their user 
    assigned priority. The run time context is occupied at the beginning of execution time and 
    is released again once the task is finished. 
   
  The following priority rules have been established: 
   • 中断优先于任务。
   • 中断处理有多个中断优先级。 
   • 中断服务程序含静态的中断优先级。
   • 中断服务程序的优先级设定由操作和硬件结构决定。
   • 任务优先级和资源ceiling-priorities大号对应高优先级。
   • 任务优先级静态设置(the meaning of task priorities is described in chapter 4.5). 
  Processing levels are defined for the handling of tasks
  interrupt routines as a range of consecutive values. 
  Mapping of operating system priorities to hardware priorities is implementation specific. 
  调度器的优先级设定是逻辑的(不是硬件的优先级),OSEK没有规定任务优先级和硬件中断优先级的映射关系。


2 Conformance classes 一致性分类

  According OS features: described as "conformance classes" (CC):
   • Provide convenientgroups of OS features for easier understanding and discussion OSEK OS. 
   • To allow partial implementations along pre-defined. maybe certified as OSEK compliant. 
   • To create an upgrade path from classes of lesser functionality to classes of higher functionality 
     with no changes to the app using OSEK related features. 
  To be certified, it is mandatory that the complete conformance class is implemented. However, system needs only to link those required system services for a specific app. 
  
  一致性分类按以下属性分类：
   • Multiple requesting of task activation, as described in chapter 4.3 
   • Task types, as described in chapter 4.2 
   • Number of tasks per priority


    Conformance classes: 
   • BCC1 (only basic tasks, one task per priority, 
         one activation request per task
           while all tasks have different priorities) 
   • BCC2 (like BCC1, plus more than one task per priority possible 
       multiple requesting of task activation allowed) 
   • ECC1 (like BCC1, plus extended tasks) 
   • ECC2 (like ECC1, plus more than one task per priority possible
       multiple requesting of task activation allowed for basic tasks)
 
 3 Relationship between OSEK OS and OSEKtime OS
 OSEKtime OS is an OS especially tailored to the needs of time triggered architectures. 
 It allows OSEK OS to coexist with OSEKtime OS. Conceptually,  OSEKtime assigns its idle time to be used by OSEK.  OSEK OS interrupts and tasks have lower priority than similar entities in OSEKtime OS.  The OSEK interfaces, and the definition of system calls, do not change if OSEK coexists with OSEKtime.  There are minor exceptions with respect to system startup and shutdown due to the fact that OSEKtime is responsible for the overall system whereas OSEK is only locally responsible. 
    These deviation are specifically mentioned within this specification. 
 On top of this, there is functionality defined within OSEKtime which imposes restrictions on the implementation of OSEK OS if it is intended to coexist with OSEKtime OS.



伍

相关学习资料下载


需要了解和学习的朋友，如需下载完整资料，可以添加小编微信：foauto，发送：姓名+公司邮箱，并说明需要那份资料，小编确认后会邮件发送，仅供学习参考！


注：本文转摘自网络并由小编整理成文，仅供学习参考，感谢相关文章作者天楚锐齿、CSDN博主「tomlingyu」「Lincanman123」「leon1741」等的精心付出和写作，归属和解释权归原作者和发布单位所有！


收藏
点赞
上一篇：【论文学习】基于AUTOSAR的标准的CAN通信栈设计与实现... 下一篇：Adaptive Autosar-汽车软件架构平台浅析
2000
评论

沪公网安备31010702008313号 沪ICP备18019345号-2 © 2019 上海工业控制安全创新科技有限公司 保留所有权利