跳转至

Specification of Operating System (OS)

返回本类索引

属性 值
平台 CP
类别 SWS — 软件模块规范（Software Specification）
UID 034
规范版本 R25-11

本地文件

  • 规范 PDF: F:\Work\Standards\01_Sources\CP_SWS_OS_034\AUTOSAR_CP_SWS_OS.pdf
  • ARXML 模型: F:\Work\Standards\01_Sources\CP_SWS_OS_034\AUTOSAR_CP_SWS_OS.arxml
  • 纯文本全文: F:\Work\Standards\01_Sources\CP_SWS_OS_034\zzgen\CP_SWS_OS.complete.txt

文档简介

This document describes the essential requirements on the AUTOSAR Operating System to satisfy the top-level requirements presented in the AUTOSAR SRS .

In general, operating systems can be split up in different groups according to their characteristics, e.g. statically configured vs. dynamically managed. To classify the AUTOSAR OS, here are the basic features of the OS

  • is configured and scaled statically
  • is amenable to reasoning of real-time performance
  • provides a priority-based scheduling policy
  • provides protective functions (memory, timing etc.) at run-time
  • is hostable on low-end controllers and without external resources

This feature set defines the type of OS commonly used in the current generation of automotive ECUs, except for Telematic/Infotainment systems. It is assumed that Telematic/Infotainment systems will continue to use proprietary OSs under the AUTOSAR framework (e.g. Windows CE, VxWorks, QNX, etc.). In the case where AUTOSAR components are needed to run on these proprietary OSs, the interfaces defined in this document should be provided as an Operating System Abstraction Layer (OSAL).

This document uses the industry standard (ISO 17356-3) as the basis for the AUTOSAR OS. The reader should be familiar with this standard before reading this document.

This document describes extensions to, and restrictions of .

模块依赖

  • It is assumed that the operating system may use timer units directly to drive counters.
  • If the user needs to drive scheduling directly from global time, then a global time interrupt is required.
  • If the user needs to synchronize the processing of a ScheduleTable to a global time, the operating system needs to be told the global time using the SyncScheduleTable service.
  • The IOC described in this document provides communication between OS-Applications. The IOC generation is based on configuration information which is generated by the RTE generator. On the other hand the RTE uses functions generated by the IOC to transmit data.
  • The Operating System depends on the definition of partitions and cores in the virtual module EcuC if OS-Applications are used.

章节详细内容

1. 简介与功能概述

原文标题：Introduction and functional overview

This document describes the essential requirements on the AUTOSAR Operating System to satisfy the top-level requirements presented in the AUTOSAR SRS .

In general, operating systems can be split up in different groups according to their characteristics, e.g. statically configured vs. dynamically managed. To classify the AUTOSAR OS, here are the basic features of the OS

  • is configured and scaled statically
  • is amenable to reasoning of real-time performance
  • provides a priority-based scheduling policy
  • provides protective functions (memory, timing etc.) at run-time
  • is hostable on low-end controllers and without external resources

This feature set defines the type of OS commonly used in the current generation of automotive ECUs, except for Telematic/Infotainment systems. It is assumed that Telematic/Infotainment systems will continue to use proprietary OSs under the AUTOSAR framework (e.g. Windows CE, VxWorks, QNX, etc.). In the case where AUTOSAR components are needed to run on these proprietary OSs, the interfaces defined in this document should be provided as an Operating System Abstraction Layer (OSAL).

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

2. 缩略语

原文标题：Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the AUTOSAR Operating System module that are not included in the .

Abbreviation Description
AR AUTOSAR
IOC Inter OS-Application communicator
LE A locatable entity is a distinct piece of software that has the same effect regardless of which core it is located.
MC Multi-Core
NMI Non maskable interrupt
RTOS Real Time Operating System
SLA Software Layered Architecture
SWC Software Component
SWFRT Software FreeRunningTimer

3. 术语表 of Terms

原文标题：Glossary of Terms

Term Definition <
Access Right An indication that an object (e.g. Task, ISR, hook function) of an OS-Application has the permission of access or manipulation with respect to memory, OS services or (set of) OS objects. <
Cardinality The number of items in a set. <
Counter An operating system object that registers a count in ticks. There are two types of counters: <
^ Hardware Counter A Counter that is advanced by hardware (e.g. timer). The count value is maintained by the peripheral "in hardware".
^ Software Counter A Counter which is incremented by making the IncrementCounter API call (see ). The count value is maintained by the operating system "in software".
Deadline The time at which a Task/Category 2 ISR must reach a certain point during its execution defined by system design relative to the stimulus that triggered activation. See figure <
Delay The number of ticks between two adjacent expiry points on a ScheduleTable.

A pair of expiry points X and Y are said to be adjacent when:

  • There is no expiry point Z such that X.Offset < Z.Offset < Y.Offset.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

4. 相关文档

原文标题：Related documentation

5. 输入文档与相关标准规范

原文标题：Input documents & related standards and norms

6. 相关规范

原文标题：Related specification

AUTOSAR provides a General Specification on Basic Software Modules , which is also valid for AUTOSAR Operating System.

Thus, the specification shall be considered as additional and required specification for AUTOSAR Operating System.

All OSEK OS related types, defines and functions can be found in .

7. 约束与假设

原文标题：Constraints and assumptions

8. Existing Standards

This document makes the following assumptions about the referenced related standards and norms:

  • provides a sufficiently flexible scheduling policy to schedule AUTOSAR systems.
  • is a mature specification and implementations are used in millions of ECUs worldwide.
  • does not provide enough support for isolating multi-source software components at runtime.
  • does not provide enough runtime support for demonstrating the absence of some classes of fault propagation in a safety-case.

9. Terminology

The specification uses the following operators when requirements specify multiple terms:

  • NOT : negation of a single term e.g. NOT Weekend
  • AND : conjunction of two terms e.g. Weekend AND Saturday
  • OR : disjunction of two terms e.g. Monday OR Tuesday

A requirement comprising multiple terms is evaluated left to right. The precedence rules are:

  • Highest Precedence NOT
  • Lowest Precedence AND OR

The expression NOT X AND Y means (NOT X) AND (Y)

Where operators of the same precedence are used in the same sentence, commas are used to disambiguate. The expression X AND Y, OR Z means (X AND Y) OR Z.

10. Interaction with the RTE

The configuration of an AUTOSAR system maps the runnables of a software component to (one or more) Tasks that are scheduled by the operating system. All runnables in a Task share the same protection boundary. In AUTOSAR, a software component must not include an interrupt handler. A software component is therefore implemented as runnables executing within the body of a Task, or set of Tasks, only.

Runnables get access to hardware-sourced data through the AUTOSAR RTE. The RTE provides the runtime interface between runnables and the basic software modules. The basic software modules also comprise a number of Tasks and ISRs that are scheduled by the operating system.

It is assumed that the software component templates and the description of the basic software modules provide sufficient information about the required runtime behavior to be able to specify the attributes of Tasks required to configure the OS.

11. Operating 系统抽象 Layer (OSAL)

原文标题：Operating System Abstraction Layer (OSAL)

Systems that do not use the OS defined in AUTOSAR can provide a platform for the execution of AUTOSAR software components using an Operating System Abstraction Layer. The interface to the OSAL is exactly that defined for the AUTOSAR OS.

12. Multi-Core Hardware assumptions

There are currently several existing and suggested HW-architectures for Multi-Core microprocessors. There is considerable variation in the features offered by these architectures. Therefore this section attempts to capture a common set of architectural features required for Multi-Core.

Hardware assumptions shall remain assumptions and shall not become official AUTOSAR requirements.

13. CPU 核 features

原文标题：CPU Core features

More than one core on the same piece of silicon.

The HW offers a method that can be used by the SW to identify a core.

The hardware supports atomic read and atomic write operations for a fixed word length depending on the hardware.

The hardware supports some atomic Test-And-Set functionality or similar functionalities that can be used to build a critical section shared between cores. Additional atomic operations may exist.

The cores may have the same instruction set; at least a common basic instruction set is available on all cores. Core specific add-ons may exist, but they are not considered.

The cores have the same data representation. For example, the same size of integer, same byte and bit order, etc.

If per-core caches exist, AUTOSAR requires support for RAM - cache coherency in HW or in SW. In software means that the cache-controller can be programmed by the SW in a way that it invalidates cache lines or excludes certain memory regions from caching.

In case of an exception (such as an illegal memory reference or divide by zero) the exception occurs on the core that introduced the exception.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

14. 存储 features

原文标题：Memory features

  • Shared RAM is available to all cores; at least all cores can share a substantial part of the memory.
  • Flash shall be shared between all cores at least. However, performance can be improved if Flash/RAM can be partitioned so that there are separate pathways from cores to Flash.
  • A single address space is assumed, at least in the shared parts of the memory address space.
  • The AUTOSAR Multi-Core architecture shall be capable to run on systems that do and do not support memory protection. If memory protection exists, all cores are covered by a hardware-based memory protection.

15. Multi-Core 限制

原文标题：Multi-Core Limitations

  • In AUTOSAR R4.0, it is not supported to activate additional cores under control of AUTOSAR after the Operating System was started.
  • The scheduling algorithm does not assign Tasks dynamically to cores.
  • The AUTOSAR OS Resource algorithm is not supported across cores. Resources can be used locally, between Tasks that are bound to the same core but not between Tasks/ISRs which are bound to different cores.

16. 限制

原文标题：Limitations

17. Hardware

The core AUTOSAR operating system assumes free access to hardware resources, which are managed by the OS itself. This includes, but is not limited to, the following hardware:

  • interrupt control registers
  • processor status words
  • stack pointer(s)

Specific (extended) features of the core operating system extend the requirements on hardware resource. The following list outlines the features that have requirements on the hardware. Systems that do not use these OS features do not have these hardware requirements.

  • Memory Protection: A hardware memory protection unit is required. All memory accesses that have the consequence of writing (e.g. reads that have the side effect of writing to a memory location) shall be treated as writes.
  • Time Protection: Timer Hardware for monitoring execution times and arrival rates.
  • Privileged and non-privileged modes on the MCU: to protect the OS against internal corruption caused by writes to OS controlled registers. This mode must not allow OS-Applications to circumvent protection (e.g. write registers which govern memory protection, write to processor status word etc.).

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

18. Programming Language

The API of the operating system is defined as C function calls or macros. If other languages are used, they must adapt to the C interface.

19. Miscellaneous

The operating system does not provide services for dynamic memory management.

20. 适用的车型领域

原文标题：Applicability to car domains

The operating system has the same design constraints regarding size and scalability under which was designed. The immediate domain of applicability is therefore currently body, chassis and power train ECUs. However, there is no reason that the OS cannot be used to implement ECUs for infotainment applications.

21. 对其他模块的依赖

原文标题：Dependencies to other modules

  • It is assumed that the operating system may use timer units directly to drive counters.
  • If the user needs to drive scheduling directly from global time, then a global time interrupt is required.
  • If the user needs to synchronize the processing of a ScheduleTable to a global time, the operating system needs to be told the global time using the SyncScheduleTable service.
  • The IOC described in this document provides communication between OS-Applications. The IOC generation is based on configuration information which is generated by the RTE generator. On the other hand the RTE uses functions generated by the IOC to transmit data.
  • The Operating System depends on the definition of partitions and cores in the virtual module EcuC if OS-Applications are used.

22. 文件结构

原文标题：File structure

23. 代码文件结构

原文标题：Code file structure

The code file structure of the Operating System module is not fixed, besides the requirements in the .

24. 头文件结构

原文标题：Header file structure

The IOC generator generates an additional header file Ioc.h. Users of the Ioc.h shall include the Ioc.h file. If an implementation of the IOC requires additional header files, it is free to include them. The header files are self-contained, that means they will include all other header files, which they require.

25. ARTI 文件结构

原文标题：ARTI File Structure

To support ARTI based debugging and tracing, all source files of the OS module with ARTI hook macros shall include an "Os_Arti.h" file. This file (along with the corresponding Arti.h and Arti.c file) will be provided by the ARTI hook implementer, i.e. the tracing tool. When building the final executable, the linker will pull in the compiled Arti.c file, too.

The usage of the ARTI hook macros is configurable. If the OS is configured to not use ARTI, the inclusion of "Os_Arti.h" may be omitted, and the ARTI hooks macros may be expanded to empty macros (nothing).

26. 需求追踪

原文标题：Requirements Tracing

The following tables reference the requirements specified in and and links to the fulfillment of these. Please note that if column "Satisfied by" is empty for a specific requirement this means that this requirement is not fulfilled by this document.

Requirement Description Satisfied by
ARTI Hooks shall be implemented with minimal intrusion
ARTI Hooks shall follow a fixed format
The ARTI template shall support core specific ARTI additions
The ARTI template shall support a parameter for the current application
The ARTI template shall support a parameter for the current task
The ARTI template shall support a parameter for the last error
The ARTI template shall support OS specific ARTI additions
The ARTI template shall support task specific ARTI additions
The ARTI description shall include a core class definition.
The ARTI description for a core class shall include a "current task" reference to the interpret the parameter value
The ARTI description shall include instance definitions for all cores of the ECU.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

27. 功能规范

原文标题：Functional specification

28. 核 OS

原文标题：Core OS

29. Background & Rationale

The OSEK/VDX Operating System is widely used in the automotive industry and has been proven in use in all classes of ECUs found in modern vehicles. The concepts that OSEK OS has introduced are widely understood and the automotive industry has many years of collective experience in engineering OSEK OS based systems.

OSEK OS is an event-triggered operating system. This provides high flexibility in the design and maintenance of AUTOSAR based systems. Event triggering gives freedom for the selection of the events to drive scheduling at runtime, for example angular rotation, local time source, global time source, error occurrence etc.

For these reasons the core functionality of the AUTOSAR OS shall be based upon the OSEK OS. In particular OSEK OS provides the following features to support concepts in AUTOSAR:

  • fixed priority-based scheduling
  • facilities for handling interrupts
  • only interrupts with higher priority than Tasks
  • some protection against incorrect use of OS services
  • a startup interface through StartOS and the StartupHook
  • a shutdown interface through ShutdownOS and the ShutdownHook

OSEK OS provides many features in addition to these.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

30. 需求

原文标题：Requirements

Upstream requirements: , , ⌈ The Operating System module shall provide an API that is backward compatible with the OSEK OS API . ⌋

31. Restrictions on OSEK OS

It is too inefficient to achieve timing and memory protection for alarm callbacks. They are therefore not allowed in specific scalability classes ()

Upstream requirements: ⌈ The Operating System module shall only allow Alarm Callbacks in Scalability Class 1. ⌋

OSEK OS is required to provide functionality to handle inter-task (internal) communication according to the OSEK COM specification when internal communication only is required in the system. In AUTOSAR, internal communication is provided by the AUTOSAR RTE or by AUTOSAR COM at least one of which will be present for all AUTOSAR ECUs.

AUTOSAR OS, when used in an AUTOSAR system, therefore does not need to support internal communication.

An OSEK OS must implement internal communication if the symbol LOCALMESSAGESONLY is defined. AUTOSAR OS can deprecate the need to implement OSEK COM functionality and maintain compatibility with OSEK suite of specifications by ensuring that AUTOSAR OS always exists in an environment where LOCALMESSAGESONLY is undefined.

OSEK OS has one special Resource called RES_SCHEDULER. This Resource has 2 specific aspects:

It is always present in the system, even if it is not configured.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

32. Undefined 行为 in OSEK OS

原文标题：Undefined Behaviour in OSEK OS

There are a number of cases where the behaviour of OSEK OS is undefined. These cases represent a barrier to portability. AUTOSAR OS tightens the OSEK OS specification by defining the required behaviour.

Upstream requirements: ⌈ If in a call to SetRelAlarm the parameter "increment" is set to zero, the service shall return E_OS_VALUE in standard and extended status . ⌋

Upstream requirements: ⌈ The first call to StartOS (for starting the Operating System) shall not return. ⌋

Upstream requirements: ⌈ If ShutdownOS is called and ShutdownHook returns then the Operating System module shall disable all interrupts and enter an endless loop. ⌋

33. Extensions to OSEK OS

Upstream requirements: ⌈ The Operating System module shall provide the services DisableAllInterrupts, EnableAllInterrupts, SuspendAllInterrupts, ResumeAllInterrupts prior to calling StartOS and after calling ShutdownOS. ⌋

It is assumed that the static variables of the functions mentioned in are initialized.

Upstream requirements: ⌈ The Operating System module shall provide the ability to increment a software Counter as an alternative action on alarm expiry. ⌋

The Operating System module provides API service IncrementCounter (see ) to increment a software Counter.

Upstream requirements: ⌈ The Operating System module shall allow to automatically start preconfigured absolute alarms during the start of the Operating System. ⌋

is an extension to OSEK OS which allows this only for relative alarms.

Upstream requirements: ⌈ The Operating System API shall check in extended mode all pointer arguments for a NULL_PTR and return E_OS_ILLEGAL_ADDRESS in this case unless NULL_PTR is explicitly allowed as a valid pointer address value in the API parameter specification. ⌋

34. 软件 Free Running Timer

原文标题：Software Free Running Timer

Due to the fact that the number of timers is often very limited, some functionality and configuration is added to extend the reuse of timers. E.g. this allows timer measurements.

Upstream requirements: ⌈ The Operating System module shall handle all the initialization and configuration of timers used directly by the Operating System module and not handled by the GPT driver. ⌋

The Operating System module provides API service GetCounterValue (see ) to read the current count value of a Counter (returning either the hardware timer ticks if Counter is driven by hardware or the software ticks when user drives Counter).

The Operating System module provides API service GetElapsedValue (see ) to get the number of ticks between the current tick value and a previously read tick value.

⌈ The Operating System module shall adjust the read out values of hardware timers (which drive counters) in such that the lowest value is zero and consecutive reads return an increasing count value until the timer wraps at its modulus. ⌋

35. ScheduleTables

36. Background & Rationale

It is possible to implement a statically defined Task activation mechanism using an OSEK Counter and a series of auto started alarms. In the simple case, this can be achieved by specifying that the Alarms are not modified once started. Run-time modifications can only be made if relative synchronization between alarms can be guaranteed. This typically means modifying the alarms while associated Counter tick interrupts are disabled.

ScheduleTables address the synchronization issue by providing an encapsulation of a statically defined set of expiry points. Each expiry point defines:

  • one or more actions that must occur when it is processed where an action is the activation of a Task or the setting of an event.
  • An offset in ticks from the start of the ScheduleTable

Each ScheduleTable has a duration in ticks. The duration is measured from zero and defines the modulus of the ScheduleTable.

At runtime, the Operating System module will iterate over the ScheduleTable, processing each expiry point in turn. The iteration is driven by an OSEK Counter. It therefore follows that the properties of the Counter have an impact on what is possible to configure on the ScheduleTable.

37. 需求

原文标题：Requirements

38. 结构 of a ScheduleTable

原文标题：Structure of a ScheduleTable

Upstream requirements: ⌈ A ScheduleTable shall have at least one expiry point. ⌋

Upstream requirements: ⌈ An expiry point shall contain a (possibly empty) set of Tasks to activate. ⌋

Upstream requirements: ⌈ An expiry point shall contain a (possibly empty) set of Events to set. ⌋

Replenish of execution budget by expiry point Upstream requirements: ⌈ An expiry point shall contain a (possibly empty) set of Taskss to replenish their execution budget. The replenishment is allowed only for tasks with OsTaskTimingProtectionDeferrableServer=TRUE and is done by means of BudgetReplenish (see ) ⌋

Note: For details about the background of see .

Upstream requirements: ⌈ An expiry point shall contain an offset in ticks from the start of the ScheduleTable. ⌋

39. Constraints on Expiry Points

There is no use case for an empty expiry point, so each one must define at least one action.

Upstream requirements: ⌈ An expiry point shall activate at least one Task OR set at least one event OR replenish a Tasks execution budget. ⌋

The OS needs to know the order in which expiry points are processed. It is therefore necessary to ensure that the expiry points on a ScheduleTable can be totally ordered. This is guaranteed by forcing each expiry point on a ScheduleTable to have a unique offset.

Upstream requirements: ⌈ Each expiry point on a given ScheduleTable shall have a unique offset. ⌋

Iteration over expiry points on a ScheduleTable is driven by an OSEK Counter. The characteristics of the Counter - OsCounterMinCycle and OsCounterMaxAllowedValue - place constraints on expiry point offsets.

Upstream requirements: ⌈ The Initial Offset shall be zero OR in the range OsCounterMinCycle .. OsCounterMaxAllowedValue of the underlying Counter. ⌋

Similarly, constraints apply to the delays between of adjacent expiry points and the delay to the logical end of the ScheduleTable.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

40. Processing ScheduleTables

Upstream requirements: ⌈ The Operating System module shall process each expiry point on a ScheduleTable from the Initial Expiry Point to the Final Expiry Point in order of increasing offset. ⌋

Upstream requirements: ⌈ The Operating System module shall permit multiple ScheduleTables to be processed concurrently. ⌋

Upstream requirements: ⌈ A ScheduleTable of the Operating System module shall be driven by exactly one Counter. ⌋

Upstream requirements: ⌈ The Operating System module shall be able to process at least one ScheduleTable per Counter at any given time. ⌋

Upstream requirements: ⌈ The Operating System module shall make use of ticks so that one tick on the Counter corresponds to one tick on the ScheduleTable. ⌋

It is possible to activate a Task and set (one or more unique) Events for the same Task at the same expiry point. The ordering of Task activations and event settings performed from the expiry point could lead to different implementations exhibiting different behaviour (for example, activating a suspended Task and then setting and event on the Task would succeed but if the ordering was reversed then the event setting would fail).

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

41. Repeated ScheduleTable Processing

A ScheduleTable may or may not repeat after the final expiry point is processed. This allows two types of behaviour:

single-shot - the ScheduleTable processes each expiry point in sequence and then stops at the end. This is useful for triggering a phased sequence of actions in response to some trigger

repeating - the ScheduleTable processes each expiry point in turn, after processing the final expiry point, it loops back to the initial expire point. This is useful for building applications that perform repeated processing or system which need to synchronize processing to a driver source.

A repeating ScheduleTable means that each expiry point is repeated at a period equal to the ScheduleTable duration.

Upstream requirements: ⌈ The ScheduleTable shall be configurable as either single-shot or repeating. ⌋

Upstream requirements: ⌈ If the ScheduleTable is single-shot, the Operating System module shall stop the processing of the ScheduleTable Final Delay ticks after the Final Expiry Point is processed. ⌋

Upstream requirements: ⌈ If the ScheduleTable is single-shot, the Operating System module shall allow a Final Delay between 0 ..

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

42. Controlling ScheduleTable Processing

The application is responsible for starting and stopping the processing of a ScheduleTable.

The Operating System module provides the service StartScheduleTableAbs (see ) to start the processing of a ScheduleTable at an absolute value "Start" on the underlying Counter. (The Initial Expiry Point has to be processed when the value of the underlying Counter equals Start + InitialOffset).

The Operating System module provides the service StartScheduleTableRel (see ) to start the processing of a ScheduleTable at "Offset" relative to the "Now" value on the underlying Counter (The Initial Expiry Point shall be processed when the value of the underlying Counter equals Now + Offset + InitialOffset).

The figure below illustrates the two different methods for a ScheduleTable driven by a Counter with a modulus of 65536 (i.e. an OsCounterMaxAllowedValue = 65535).

The Operating System module provides the service StopScheduleTable (see ) to cancel the processing of a ScheduleTable immediately at any point while the ScheduleTable is running.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

43. ScheduleTable 同步

原文标题：ScheduleTable Synchronization

44. Background & Rationale

The absolute time at which the Initial Expiry Point on a ScheduleTable is processed is under user control. However, if the ScheduleTable repeats then it is not guaranteed that the absolute count value at which the initial expiry point was first processed is the same count value at which it is subsequently processed. This is because the duration of the ScheduleTable need not be equal to the Counter modulus.

In many cases it may be important that ScheduleTable expiry points are processed at specific absolute values of the underlying Counter. This is called synchronization. Typical use-cases include:

  • Synchronization of expiry points to degrees of angular rotation for motor management
  • Synchronizing the computation to a global (network) time base. Note that in AUTOSAR, the Operating System does not provide a global (network) time source because

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

45. 需求

原文标题：Requirements

Upstream requirements: ⌈ The Operating System module shall provide the ability to synchronize the processing of ScheduleTable to known Counter values. ⌋

46. Implicit 同步

原文标题：Implicit Synchronization

The Operating System module does not need to provide any additional support for implicit synchronization of ScheduleTables. However, it is necessary to constrain configuration and runtime control of the ScheduleTable so that ticks on the configured ScheduleTable can be aligned with ticks on the Counter. This requires the range of the ScheduleTable to be identical to the range of the Counter (the equality of tick resolution of each is guaranteed by the requirements on the ScheduleTable / Counter interaction):

Upstream requirements: ⌈ A ScheduleTable of the Operating System module that is implicitly synchronized shall have a Duration equal to OsCounterMaxAllowedValue + 1 of its associated OSEK OS Counter. ⌋

To synchronize the processing of the ScheduleTable it must be started at a known counter value. The implication of this is that a ScheduleTable requiring implicit synchronization must only be started at an absolute counter value and cannot be started at a relative count value.

Upstream requirements: ⌈ The Operating System module shall prevent a ScheduleTable that is implicitly synchronized from being started at a relative count value. ⌋

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

其余 352 章（内容从略，见纯文本全文）

  1. Explicit 同步
  2. 启动
  3. Providing a 同步 Count
  4. Specifying 同步 Bounds
  5. Performing 同步
  6. Stack Monitoring Facilities
  7. Background & Rationale
  8. 需求
  9. OS-Application
  10. Background & Rationale
  11. 需求
  12. Protection Facilities
  13. 存储 Protection
  14. Background & Rationale
  15. 需求
  16. 时序 Protection
  17. Background & Rationale
  18. Deferrable Server
  19. 需求
  20. Implementation Notes
  21. 服务 Protection
  22. Background & Rationale
  23. Invalid Object Parameter or Out of Range Value
  24. Background & Rationale
  25. 需求
  26. 服务 Calls Made from Wrong Context
  27. Background & Rationale
  28. 需求
  29. 服务 with Undefined 行为
  30. Background & Rationale
  31. 需求
  32. 服务 Restrictions for Non-Trusted OS-Applications
  33. Background & Rationale
  34. 需求
  35. 服务 Calls on Objects in Different OS-Applications
  36. Background
  37. 需求
  38. Protecting the Hardware used by the OS
  39. Background & Rationale
  40. 需求
  41. Implementation Notes
  42. Providing Trustedfunctions
  43. Background & Rationale
  44. 需求
  45. Protection 错误处理
  46. Background & Rationale
  47. 需求
  48. Operating 系统 for Multi-Core
  49. Background & Rationale
  50. 需求
  51. 调度
  52. 需求
  53. Locatable entities (LE)
  54. 需求
  55. Multi-Core start-up concept
  56. 需求
  57. 核 under 控制 of the AUTOSAR OS
  58. 需求
  59. Multi-Core 关机 concept
  60. Synchronized 关机 concept
  61. Individual 关机 concept
  62. fatal internal 错误的关机 in case
  63. OS 服务 functionality (概述)
  64. GetTaskID
  65. Interrupt disabling
  66. 需求
  67. Task activation
  68. 需求
  69. Task Chaining
  70. 需求
  71. Event setting
  72. 需求
  73. Activating additional 核
  74. Start of the OS
  75. 需求
  76. Task termination
  77. 需求
  78. Termination of OS-Applications
  79. 需求
  80. 关机 of the OS
  81. 需求
  82. Waiting for Events
  83. 需求
  84. Calling trusted functions
  85. 需求
  86. Invoking reschedule
  87. 需求
  88. Resource 处理
  89. The CoreID
  90. 需求
  91. Counters, background & rationale
  92. Multi-Core restrictions on Counters
  93. 需求
  94. 同步 of Counters
  95. Alarms
  96. 需求
  97. ScheduleTables
  98. 需求
  99. The spinlock mechanism
  100. 需求
  101. Offline checks
  102. 需求
  103. Auto start Objects
  104. 需求
  105. Inter-OS-Application Communicator (IOC)
  106. Background & Rationale
  107. IOC - 通用目的
  108. IOC functionality
  109. Communication
  110. 通知
  111. IOC 接口
  112. IOC internal 结构
  113. IOC 配置 and generation
  114. IOC 集成示例
  115. 示例 1 - 1：1 sender/receiver communication without 通知
  116. 示例 2 - N：1 client/server communication with receiver 通知 by RTE
  117. 系统 Scalability
  118. Background & Rationale
  119. 需求
  120. Hook Functions
  121. Background & Rationale
  122. 需求
  123. Hardware peripheral access
  124. Background & Rationale
  125. 需求
  126. Interrupt source API
  127. Background & Rationale
  128. 需求
  129. 错误分类
  130. ARTI Debug Information
  131. OS ARTI Objects
  132. ARTI Hook Macros
  133. Class AR_CP_OS_APPLICATION
  134. Class AR_CP_OS_TASK
  135. Class AR_CP_OS_CAT2ISR
  136. Class AR_CP_OS_SERVICECALLS
  137. Class AR_CP_OS_SPINLOCK
  138. Class AR_CP_OS_HOOK
  139. API 规范
  140. Constants
  141. 类型 StatusType的错误 codes
  142. Macros
  143. 类型定义
  144. ApplicationType (for OS-Applications)
  145. ApplicationStateType
  146. ApplicationStateRefType
  147. TrustedFunctionIndexType
  148. TrustedFunctionParameterRefType
  149. AccessType
  150. ObjectAccessType
  151. ObjectTypeType
  152. MemoryStartAddressType
  153. MemorySizeType
  154. ISRType
  155. ScheduleTableType
  156. ScheduleTableStatusType
  157. ScheduleTableStatusRefType
  158. ProtectionReturnType
  159. RestartType
  160. PhysicalTimeType
  161. CoreIdType
  162. SpinlockIdType
  163. TryToGetSpinlockType
  164. AreaIdType
  165. CounterType
  166. 功能定义
  167. GetApplicationID
  168. GetCurrentApplicationID
  169. GetISRID
  170. CallTrustedFunction
  171. CheckISRMemoryAccess
  172. CheckTaskMemoryAccess
  173. CheckObjectAccess
  174. CheckObjectOwnership
  175. StartScheduleTableRel
  176. StartScheduleTableAbs
  177. StopScheduleTable
  178. NextScheduleTable
  179. StartScheduleTableSynchron
  180. SyncScheduleTable
  181. SetScheduleTableAsync
  182. GetScheduleTableStatus
  183. IncrementCounter
  184. GetCounterValue
  185. GetElapsedValue
  186. TerminateApplication
  187. GetApplicationState
  188. GetNumberOfActivatedCores
  189. GetCoreID
  190. StartCore
  191. GetSpinlock
  192. ReleaseSpinlock
  193. TryToGetSpinlock
  194. ShutdownAllCores
  195. ReadPeripheral8, ReadPeripheral16, ReadPeripheral32
  196. WritePeripheral8, WritePeripheral16, WritePeripheral32
  197. ModifyPeripheral8, ModifyPeripheral16, ModifyPeripheral32
  198. EnableInterruptSource
  199. DisableInterruptSource
  200. ClearPendingInterrupt
  201. ActivateTaskAsyn
  202. SetEventAsyn
  203. isOsStarted
  204. BudgetReplenish
  205. IOC
  206. Imported 类型
  207. 类型定义
  208. Constants
  209. 功能定义
  210. IocInit
  211. IocSend/IocWrite
  212. IocSendGroup/IocWriteGroup
  213. IocReceive/IocRead
  214. IocReceiveGroup/IocReadGroup
  215. IocEmptyQueue
  216. Expected 接口
  217. Mandatory 接口
  218. Optional 接口
  219. Callout 接口
  220. ProtectionHook
  221. Application specific StartupHook
  222. Application specific ErrorHook
  223. Application specific ShutdownHook
  224. ReceiverPullCB
  225. 服务接口
  226. 时序图
  227. Sequence chart for calling trusted functions
  228. Sequence chart for usage of ErrorHook
  229. Sequence chart for ProtectionHook
  230. Sequence chart for StartupHook
  231. Sequence chart for ShutdownHook
  232. Sequence diagrams of Sender Receiver communication over the IOC
  233. Last-is-best communication
  234. Queued communication without pull callback
  235. Queued communication with pull callback
  236. 配置规范
  237. How to read this chapter
  238. Rules for paramters
  239. Containers and 配置 parameters
  240. Os
  241. OsAlarmSetEvent
  242. OsAlarm
  243. OsAlarmAction
  244. OsAlarmActivateTask
  245. OsAlarmAutostart
  246. OsAlarmCallback
  247. OsAlarmIncrementCounter
  248. OsApplication
  249. OsApplicationHooks
  250. OsApplicationTrustedFunction
  251. OsAppMode
  252. OsCounter
  253. OsEvent
  254. OsDriver
  255. OsHooks
  256. OsIsr
  257. OsIsrResourceLock
  258. OsIsrTimingProtection
  259. OsOS
  260. OsPeripheralArea
  261. OsResource
  262. OsScheduleTable
  263. OsScheduleTableAutostart
  264. OsScheduleTableEventSetting
  265. OsScheduleTableExpiryPoint
  266. OsScheduleTableTaskActivation
  267. OsScheduleTblAdjustableExpPoint
  268. OsScheduleTableTaskReplenish
  269. OsScheduleTableSync
  270. OsSpinlock
  271. OsTask
  272. OsTaskAutostart
  273. OsTaskResourceLock
  274. OsTaskTimingProtection
  275. OsTimeConstant
  276. Containers and 配置 parameter extensions of the IOC
  277. OsIoc
  278. OsIocCommunication
  279. OsIocSenderProperties
  280. OsIocReceiverProperties
  281. OsIocDataProperties
  282. Containers and 配置 parameters for ARTI
  283. ArtiHardware
  284. ArtiHardwareCoreClass
  285. ArtiHardwareCoreInstance
  286. ArtiOs
  287. ArtiOsAlarmClass
  288. ArtiOsAlarmInstance
  289. ArtiOsClass
  290. ArtiOsContextClass
  291. ArtiOsContextInstance
  292. ArtiOsInstance
  293. ArtiOsIsrClass
  294. ArtiOsIsrInstance
  295. ArtiOsResourceClass
  296. ArtiOsResourceInstance
  297. ArtiOsScheduleTableClass
  298. ArtiOsScheduleTableInstance
  299. ArtiOsSpinlockClass
  300. ArtiOsSpinlockInstance
  301. ArtiOsStackClass
  302. ArtiOsStackInstance
  303. ArtiOsTaskClass
  304. ArtiOsTaskInstance
  305. 发布信息
  306. Generation of the OS
  307. Read in 配置
  308. Consistency check
  309. Generating operating 系统
  310. Application Notes
  311. Hooks
  312. Providing Trusted Functions
  313. 软件 Components and OS-Applications
  314. Global Time 同步
  315. Working with FlexRay
  316. Migration from OIL to XML
  317. Debug 支持
  318. 集成 hints for peripheral protection
  319. Termination of OS-Applications
  320. Outlook on 存储 Protection 配置
  321. 配置 Approach
  322. 附录
  323. 不适用需求
  324. History of Constraints and 规范 Items
  325. Differences between R25-11 and R26-11
  326. Added 规范 Items in R26-11
  327. Changed 规范 Items in R26-11
  328. Deleted 规范 Items in R26-11
  329. Added Constraints in R26-11
  330. Changed Constraints in R26-11
  331. Deleted Constraints in R26-11
  332. Differences between R24-11 and R25-11
  333. Added 规范 Items in R25-11
  334. Changed 规范 Items in R25-11
  335. Deleted 规范 Items in R25-11
  336. Added Constraints in R25-11
  337. Changed Constraints in R25-11
  338. Deleted Constraints in R25-11
  339. Differences between R23-11 and R24-11
  340. Added 规范 Items in R24-11
  341. Changed 规范 Items in R24-11
  342. Deleted 规范 Items in R24-11
  343. Added Constraints in R24-11
  344. Changed Constraints in R24-11
  345. Deleted Constraints in R24-11
  346. Differences between R22-11 and R23-11
  347. Added 规范 Items in R23-11
  348. Changed 规范 Items in R23-11
  349. Deleted 规范 Items in R23-11
  350. Added Constraints in R23-11
  351. Changed Constraints in R23-11
  352. Deleted Constraints in R23-11