汽车用OSEK OS学习笔记_osek os教程

 

1 Introduction

 1.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 上运行.

 Error checking:
 两级error checking：
  extended status 开发周期：
   enhanced plausibility checks on calling os services in a test phase.
   requires more execution time and memory space.

  standard status for production phase.
   recompiled

 App's Portability:
 portability and re-usability of app. 因此接口要定义的好。
  Portability:  换平台时应用程序改动不大。
   标准化的接口 (service calls, type definitions and constants) 。
   应用程序并行运行在 Input/Output 系统接口(非OSEK标准)上.
    APP可以有几种接口，1，OS的实时控制和资源管理接口。
       2，复杂功能模块或硬件接口。

   
   目标代码并没有定地址。
   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.
 

 

 1.2 Purpose of this document

 

 1.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.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.

2 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.

 Interrupt management
  • Services for interrupt processing
   interrupt strategy, the different types of ISR.

 Alarms
  • Relative and absolute alarms，两级原理, 支持基于时间的事件(e.g. hardware-timer)和非基于时间的events (角度测量). 

 Intra processor message handling
  • Services for exchange of data，intra processor communication.

 Error treatment
  • Mechanisms supporting the user in case of various errors
  the mechanisms to achieve centralised error handling. 错误集中处理
  the services to initialise and shutdown the system.

3 Architecture
 3.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没有规定任务优先级和硬件中断优先级的映射关系。

 3.2 Conformance classes 一致性分类
  According OS features: described as "conformance classes" (CC):
   • Provide convenient便利的 groups 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)

 The portability of app can only be assumed if the minimum requirements are not exceeded超出.
 The minimum requirements for Conformance Classes are shown in the Figure 3-3.
 

 
 3.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 deviations背离 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.