AUTOSAR_SWS_OS

十二月 23, 2025

Specification of Operating System

简介和功能概述

本文档描述了 AUTOSAR 操作系统（OS）的基本要求，此需求满足在操作系统（OS）需求 [1] 中被提出的最高级别的需求。

一般来说，可以根据其特性将操作系统（OS）分为不同的类型，例如，被静态地配置型和被动态地管理型。为了对 AUTOSAR 操作系统（OS）进行分类，以下是操作系统（OS）的基本特性：

被静态地配置及裁剪

适用于实时性需求

提供基于优先级的调度策略

在运行时（Runtime）中提供保护功能（内存、时序等）

在低端控制器上运行，无需外部资源

本功能集定义了在现世代汽车电子控制单元 (ECU) 中常用的操作系统（OS）的类型，但车载信息娱乐系统除外。车载信息娱乐系统将继续使用基于 AUTOSAR 框架的专有操作系统（OS）（例如，Windows CE、VxWorks、QNX 等）。如果需要在这些专有操作系统（OS）上运行 AUTOSAR 组件，则应将在本文档中被定义的接口作为操作系统抽象层 (OSAL) 提供。

本文档以行业标准 [2] 作为 AUTOSAR 操作系统（OS）的基础。读者在阅读本文档之前应熟悉该标准。

本文档描述了对 [2] 的扩展及限制。

首字母缩略词、缩写和词汇表

术语表

[2] 是一个成熟的规范，其实现已在全球数百万个 ECU 中被使用

[2] 未提供足够的支持以在运行时（Runtime）中隔离多源软件组件

[2] 未提供足够的支持以证明在运行时（Runtime）中不存在某些类型的故障传播（对于安全案例）

术语

当需求包含多个术语时，本规范使用以下运算符：

NOT：表示对于单个术语的否定，例如，NOT Weekend（非周末）

AND：表示对于两个术语的合取，例如，Weekend AND Saturday（周末且星期六）

OR：表示对于两个术语的析取，例如，Monday OR Tuesday（星期一或星期二）

对于包含多个术语的需求，应按从左到右的顺序进行评估。优先级规则如下：

NOT 具有最高优先级

AND 及 OR 具有最低优先级

表达式 NOT X AND Y 表示 ((NOT X) AND (Y))

如果在同一语句中使用了优先级相同的运算符，则将对逗号进行使用以消除歧义。表达式 X AND Y, OR Z 表示 ((X AND Y) OR (Z))。

与 RTE 的交互

AUTOSAR 操作系统（OS）的配置 [5] 将软件组件的 Runnable 映射到由操作系统（OS）调度的一个或多个任务中。任务中的所有 Runnable 共享相同的保护边界。在 AUTOSAR 中，软件组件不得包含中断服务例程 (ISR)。因此，软件组件仅以 Runnable 的形式被实现，这些 Runnable 仅在一个或一组任务中被执行。

Runnable 通过 RTE 对硬件数据进行访问。RTE 提供 Runnable 与基础软件模块（BSW）之间的运行时（Runtime）接口。基础软件模块（BSW）也包含若干由操作系统（OS）调度的任务和中断服务例程 (ISR)。

应假设软件组件模板及对基础软件模块（BSW）的描述提供了足够的信息，以说明所需的运行时（Runtime）行为，以便指定对操作系统（OS）进行配置所需的任务的属性。

操作系统抽象层 (OSAL)

即使不使用在 AUTOSAR 中被定义的操作系统（OS），系统也可以通过操作系统抽象层 (OSAL) 为 AUTOSAR 软件组件的执行提供平台。操作系统抽象层 (OSAL) 的接口与 AUTOSAR 操作系统（OS）的接口完全相同。

多核硬件假设

目前存在多种多核微处理器硬件架构（此处“架构”涵盖核心与内存、外设之间的连接，以及中断处理机制）。不同架构提供的功能之间的差异巨大。因此，本节旨在概述一组多核处理器所需的通用架构特性。

硬件假设仅为假设，不应成为 AUTOSAR 的正式需求。

CPU 核心特性

1. 同一块硅片上存在多个核心。

2. 硬件为软件提供了一种对核心进行识别的方法。

3. 硬件支持以固定字长的方式进行原子读取/写入操作（具体取决于硬件）。

4. 硬件支持某些原子测试及原子设置功能或与其类似的功能，可被用于构建在核心间被共享的临界区（可能存在其他原子操作）。

5. 核心应具有相同的指令集，至少所有核心都应提供一套通用的基本指令集。可能存在特定于某个核心的附加指令，但此处不予考虑。

6. 核心应具有相同的数据表达形式。例如，整数（integer）的数据大小、字节序及比特序相同等。

7. 如果在每个核心上都存在缓存，AUTOSAR 要求硬件或软件对 RAM 缓存一致性进行支持。软件对 RAM 缓存一致性进行支持是指：可以通过软件对缓存控制器进行编程，并使某些缓存行失效或在缓存区域中排除某些内存区域。

8. 对于异常（例如，对内存进行非法访问或除零操作），其仅存在（被抛出）于会对其进行处理的核心中。

9. 对于通知功能，应可在任何核心上触发中断/陷阱。

内存功能

1. 可供所有核心使用的共享 RAM ，应至少保证所有核心都可对一部分内存进行访问。

2. 应至少保证闪存在所有核心之间被共享。但是，如果可以通过对闪存/ RAM 进行分区建立核心与闪存之间的独立路径，则可以提升性能。

3. 应假定对唯一的地址空间进行使用，至少对于内存地址空间的共享部分来说应如此。

4. 无论是否对内存保护进行支持，AUTOSAR 多核架构都应能够在系统中运行。如果存在内存保护，则所有核心都将受到基于硬件的内存保护。

多核的限制

1. 在 AUTOSAR R4.0 中，不支持在操作系统（OS）被启动后对由 AUTOSAR 控制的其他核心进行激活。

2. 调度算法不会动态地将任务分配给核心。

3. AUTOSAR 操作系统（OS）的资源算法不支持跨核。资源可以在本地被使用，也可以在被绑定到同一核心的任务间被使用，但不能在被绑定到不同核心的任务/中断服务例程 (ISR) 间被使用。

限制

硬件

AUTOSAR 操作系统（OS）假定其自身可以自由地对硬件资源进行访问，这些资源由操作系统（OS）管理。这包括但不限于以下硬件：

中断控制寄存器

处理器状态字

堆栈指针

操作系统（OS）的特定（扩展）功能会对硬件资源有额外的需求。以下列表概述了对硬件有额外的需求的功能（未对这些特定（扩展）功能进行使用的操作系统（OS）没有这些额外的需求）：

内存保护：需要一个硬件内存保护单元。所有会对内存进行写入操作的对内存的访问（例如，读取操作会产生写入内存位置的副作用）都应被视为写入操作。

时间保护：需要一个被用于对执行时间和到达率进行监控的定时器硬件。

MCU 上的特权模式和非特权模式：需要一个被用于保护操作系统（OS）免受因对由操作系统（OS）控制的寄存器进行写入操作而导致的内部故障的影响的实现。此模式不得允许应用程序绕过保护（例如，对控制内存保护单元的寄存器进行写入操作、对处理器状态字进行写入操作等）。特权模式必须完全由受保护的操作系统（OS）控制，操作系统（OS）在其内部对该模式进行使用，并在非受信任的应用程序和受信任的应用程序之间来回切换控制权。微处理器必须对这种机制（使处理器能够进入特权模式）进行支持。

本地/全局时间同步：需要一个全局时间源。

通常情况下，操作系统（OS）无法对位于处理器中的硬件故障进行检测。一旦发生硬件故障，操作系统（OS）将无法保证其正常运行。

由操作系统（OS）管理的额外需求中的资源必须在相应的操作系统（OS）配置文件中被定义。

编程语言

操作系统（OS）的 API 以 C 语言的函数调用或宏的形式被定义。如果使用其他编程语言，则必须使其适配 C 语言的接口。

杂项

操作系统（OS）不提供动态内存管理。

对于汽车领域的适用性

操作系统（OS）在大小和可扩展性方面的设计约束与 [2] 中的设计约束相同。因此，其直接适用范围目前为车身、底盘和动力总成 ECU。然而，该操作系统（OS）也完全可被用于与信息娱乐应用相关的 ECU。

对其他模块的依赖

虽然没有对其他模块的强制依赖，但：

应假设操作系统（OS）可直接对定时器单元进行使用以驱动计数器。

如果用户需要直接通过全局时间对调度进行驱动，则需要全局时间中断。

如果用户需要将对 ScheduleTable 的处理与全局时间同步，则需要通过 SyncScheduleTable 服务将全局时间告知操作系统（OS）。

在本文档中被描述的 IOC 提供应用程序间的通信。IOC 的生成基于 RTE 生成器生成的配置信息。另一方面，RTE 通过 IOC 生成的函数对数据进行传输。

文件结构

代码文件结构

除了 [6] 中的需求外，操作系统（OS）的代码文件结构不固定。

头文件结构

IOC 生成器会生成一个额外的头文件 Ioc.h。对 Ioc.h 进行使用的用户必须包含该文件。如果 IOC 的实现需要其他头文件，可以自行包含。这些头文件是被包含的，这意味着它们会包含所有其他所需的头文件。

ARTI 文件结构

为了支持基于 ARTI 的调试和跟踪，所有包含 ARTI Hook 宏的操作系统（OS）源文件都必须包含 Os_Arti.h 文件。该文件（以及相应的 Arti.h 和 Arti.c 文件）将由 ARTI Hook 的实现（跟踪工具）提供。构建最终可执行文件时，链接器也会对已编译的 Arti.c 文件进行引用。

对 ARTI Hook 宏的使用是可配置的。如果操作系统（OS）的配置不使用 ARTI，则可以不包含 Os_Arti.h 文件，并且对 ARTI Hook 宏的展开为空（不包含任何内容）。

需求可追溯性

功能定义

操作系统（OS）

背景与理由

OSEK/VDX 操作系统（OS）在汽车行业被广泛地应用，并已在现代车辆中的各类 ECU 中得到验证。OSEK/VDX 操作系统（OS）引入的概念已被广泛地理解，汽车行业在基于 OSEK/VDX 操作系统（OS）的系统工程方面也积累了多年的经验。

OSEK/VDX 操作系统（OS）是一个事件触发型操作系统（OS）。这为基于 AUTOSAR 的系统的设计和维护提供了高度的灵活性。事件触发机制允许在运行时（Runtime）中自由地选择被用于对调度进行驱动的事件，例如，角度旋转、本地时钟源、全局时钟源、错误的发生等。

鉴于以上原因，AUTOSAR 操作系统（OS）的核心功能将基于 OSEK/VDX 操作系统（OS）。具体来说，OSEK/VDX 操作系统（OS）将提供以下功能来对 AUTOSAR 中的概念进行支持：

基于固定优先级的调度

中断处理机制

仅中断优先级高于任务优先级

防止对操作系统（OS）服务进行错误地使用的保护

通过 StartOS 和 StartupHook 提供的启动接口

通过 ShutdownOS 和 ShutdownHook 提供的关机接口

OSEK/VDX 操作系统（OS）还提供了许多其他功能，详情请了解 [2]。

基于 OSEK/VDX 操作系统（OS）的 AUTOSAR 操作系统（OS）意味着旧版应用程序将向后兼容，也就是说，为 OSEK/VDX 操作系统（OS）编写的应用程序也可以在 AUTOSAR 操作系统（OS）上运行。但是，在 AUTOSAR 操作系统（OS）中被引入的一些功能将限制对现有的 OSEK/VDX 操作系统（OS）的功能的使用，同时这些被引入的功能也可能会对现有的 OSEK/VDX 操作系统（OS）的功能进行扩展。

需求

[SWS_Os_00001]

[SRS_Os_00097]

[SRS_BSW_00336]

[SRS_BSW_00345]

操作系统（OS）应提供向后兼容 OSEK/VDX 操作系统（OS）API [2] 的 API。

OSEK/VDX 操作系统（OS）的限制

对于闹钟回调例程的时间保护和内存保护的效率太低。因此，在特定的可裁剪等级（[SWS_Os_00242]）中才允许对此功能进行使用。

[SWS_Os_00242]

[ ]

操作系统（OS）仅允许在可裁剪等级 1 中对闹钟回调例程进行使用。

当仅系统需要进行内部通信时，OSEK/VDX 操作系统（OS）必须根据 OSEK/VDX 的 COM 规范提供对任务间（内部）通信进行处理的功能。在 AUTOSAR 中，任务间（内部）通信由 RTE 或 COM 提供，在所有使用 AUTOSAR 的 ECU 中至少将存在其中之一。

因此，在 AUTOSAR 系统中对 AUTOSAR 操作系统（OS）进行使用时无需对任务间（内部）通信进行支持。

如果对 LOCALMESSAGESONLY 进行了定义，则 OSEK/VDX 操作系统（OS）必须对任务间（内部）通信进行实现。通过确保其自身始终存在于 LOCALMESSAGESONLY 未被定义的环境中，AUTOSAR 操作系统（OS）将在不对 OSEK/VDX 的 COM 的功能进行实现的同时保持其与 OSEK/VDX 规范的兼容性。

在 OSEK/VDX 操作系统（OS）中存在一个名为 RES_SCHEDULER 的特殊资源。该资源有两个特点：

它始终存在于系统中（即使未对其进行配置），这意味着操作系统（OS）将始终感知 RES_SCHEDULER。

它始终具备最高任务优先级。这意味着被分配了此资源的任务将不会被其他任务抢占。

由于总是存在特殊情况（例如，时间保护问题），AUTOSAR 操作系统（OS）对 RES_SCHEDULER 的处理方式将与对其他资源的处理方式保持一致。这意味着 RES_SCHEDULER 不会被自动地创建。

请注意，在多核系统中，调度是按核心进行的。第 7.9.21 节包含有关此类系统中资源处理的更多信息。

在 OSEK/VDX 操作系统（OS）中，必须通过特定的宏（例如，DeclareTask() 等）对操作系统（OS）对象进行声明。在对 AUTOSAR 操作系统（OS）的实现中不应依赖于此类声明，并且（为了向后兼容）应将该宏扩展为空。

OSEK/VDX 操作系统（OS）中未被定义的行为

在 OSEK/VDX 操作系统（OS）中存在一些未被定义的行为，这对其可移植性带来了障碍。AUTOSAR 操作系统（OS）将通过对所需的行为进行定义完善 OSEK/VDX 操作系统（OS）规范。

[SWS_Os_00304]

[ ]

如果在对 SetRelAlarm 进行调用时，参数 increment 被设置为零，则该服务应在标准状态和扩展状态中返回 E_OS_VALUE。

[SWS_Os_00424]

[ ]

在首次对 StartOS（被用于启动操作系统（OS））进行调用时，不应返回。

[SWS_Os_00425]

[ ]

如果对 ShutdownOS 进行调用且 ShutdownHook 返回时，则操作系统（OS）应禁用所有中断并进入死循环。

对 OSEK/VDX 操作系统（OS）的扩展

[SWS_Os_00299]

[SRS_Os_11018]

操作系统（OS）应在对 StartOS 进行调用之前和对 ShutdownOS 进行调用之后提供 DisableAllInterrupts、EnableAllInterrupts、SuspendAllInterrupts、ResumeAllInterrupts 服务。

应假设在 [SWS_Os_00299] 中被提到的函数的静态变量已被初始化。

[SWS_Os_00301]

[SRS_Os_11021]

操作系统（OS）应提供在闹钟到期时对软件计数器进行递增操作（作为一个替代操作）的功能。

操作系统（OS）应提供 IncrementCounter（参见 [SWS_Os_00399]）服务来对软件计数器进行递增操作。

[SWS_Os_00476]

[ ]

操作系统（OS）应允许在操作系统（OS）被启动期间自动地启动被预先配置的绝对闹钟。

[SWS_Os_00476] 是 OSEK/VDX 操作系统（OS）的一个扩展（仅对于相对闹钟而言）。

[SWS_Os_00566]

[ ]

在扩展模式下，操作系统（OS）的服务应对所有指针参数是否为 NULL 进行检查，如果出现指针参数为 NULL 的情况，则应在扩展状态中返回 E_OS_PARAM_POINTER。

自由运行软件定时器

由于定时器的数量通常非常有限，因此需要添加一些功能和配置以扩展定时器的重用性。例如，允许对定时器进行测量。更多详细信息，请参阅 [7]。

[SWS_Os_00374]

[SRS_Frt_00020]

操作系统（OS）应对其直接使用且不由 GPT 驱动程序处理的所有定时器进行初始化和配置。

操作系统（OS）应提供 GetCounterValue（参见 [SWS_Os_00383]）服务来读取计数器的当前计数值（如果计数器由硬件驱动，则应返回硬件定时器的滴答数。如果计数器由软件驱动，则应返回软件中的滴答数）。

操作系统（OS）应提供 GetElapsedValue（参见 [SWS_Os_00392]）服务来获取当前滴答数与先前已读取的滴答数之间的差值。

[SWS_Os_00384]

[SRS_Frt_00030]

[SRS_Frt_00031]

操作系统（OS）应调整从硬件定时器（驱动计数器）中读取回来的值，使其最小值为零，并且在连续读取过程中应返回在数值上呈增加趋势的计数值，直到定时器到达其最大计数值并开始向下计数。

调度表

背景与理由

可以使用 OSEK/VDX 计数器和一系列被自动地启动的闹钟来实现对被静态地定义的任务进行激活的机制。在简单情况下，可以通过指定一旦闹钟被启动就不可对闹钟进行修改来实现。只有在能够保证闹钟间的相对同步的情况下，才能在运行时（Runtime）中对闹钟进行修改。这通常意味着在对相关的计数器的滴答中断进行禁用的情况下对闹钟进行修改。

调度表通过对一组被静态地定义的到期时间点进行封装解决同步问题。每个到期时间点将定义：

一个或多个在对该到期时间点进行处理时必须被执行的操作，其中操作为对任务的激活或对事件的设置。

一个距离调度表开始被处理时的时间点的时间偏移量（以滴答为单位）。

每个调度表都有一个持续时间（以滴答为单位）。持续时间（定义了对于其自身的最大计数值）从零开始计量。

在运行时（Runtime）中，操作系统（OS）将对调度表进行遍历，依次对每个到期时间点进行处理。此迭代由 OSEK/VDX 计数器驱动。因此，计数器的属性将对调度表上可被配置的选项的范围产生影响。

需求

调度表的结构

[SWS_Os_00401]

[ ]

在每个调度表中应至少存在一个到期时间点。

[SWS_Os_00402]

[ ]

到期时间点应包含一组待被激活的任务（也可以为空）。

[SWS_Os_00403]

[ ]

到期时间点应包含一组待被设置的事件（也可以为空）。

[SWS_Os_00404]

[ ]

到期时间点应包含一个距离调度表开始被处理时的时间点的时间偏移量（以滴答为单位）。

到期时间点的限制

没有对空白到期时间点的使用场景，每个到期时间点都必须至少包含一个操作。

[SWS_Os_00407]

[ ]

到期时间点应至少对一个任务进行激活或至少对一个事件进行设置。

操作系统（OS）需要知道对到期时间点的处理的顺序。因此，必须确保调度表上的到期时间点完全有序。这可以通过强制调度表中的每个到期时间点具有唯一的偏移量（以滴答为单位）被保证。

[SWS_Os_00442]

[ ]

给定调度表中的每个到期时间点都应具有一个唯一的偏移量（以滴答为单位）。

对调度表中的到期时间点的迭代由 OSEK/VDX 计数器驱动。该计数器的属性 OsCounterMinCycle 和 OsCounterMaxAllowedValue 将对到期时间点的偏移量（以滴答为单位）造成限制。

[SWS_Os_00443]

[ ]

初始偏移量应为零或在计数器的属性 OsCounterMinCycle .. OsCounterMaxAllowedValue 的范围内。

同样，此限制也适用于相邻到期时间点之间的延迟以及到调度表的结束延迟。

[SWS_Os_00408]

[ ]

相邻到期时间点之间的延迟应在计数器的属性 OsCounterMinCycle .. OsCounterMaxAllowedValue 的范围内。

对调度表的处理

[SWS_Os_00002]

[SRS_Os_00098]

操作系统（OS）应按照偏移量从小到大的顺序（从最开始的到期时间点到最终的到期时间点），对调度表中的每个到期时间点进行处理。

[SWS_Os_00007]

[SRS_Os_00098]

操作系统（OS）应允许同时对多个调度表进行处理。

[SWS_Os_00409]

[ ]

操作系统（OS）的调度表应由一个计数器驱动。

[SWS_Os_00410]

[ ]

对于每个计数器，操作系统（OS）应能够在任何给定时间点对由该计数器驱动的调度表中的至少一个调度表进行处理。

[SWS_Os_00411]

[ ]

操作系统（OS）应对滴答进行使用，以便计数器中的一个滴答与调度表中的一个滴答相对应。

可以在对单个到期时间点的处理中对任务进行激活并为该任务设置（一个或多个唯一的）事件。在对到期时间点的处理中，对任务的激活和对事件的设置的先后顺序可能会导致在不同的实现中出现不同的结果（例如，先对一个处于 Suspended 状态的任务进行激活，然后再为该任务设置事件，则操作将会成功。但如果颠倒顺序，则操作将会失败）。为了防止这种不确定性，必须强制在对到期时间点的处理中的操作顺序。

[SWS_Os_00412]

[ ]

如果对到期时间点的处理包含对任务的激活及为该任务设置（一个或多个唯一的）事件的操作，则操作系统（OS）应先对任务进行激活，然后再为该任务设置事件。关于对到期时间点的处理中的顺序，不应做任何其他假设。

调度表的状态应始终为已被定义的状态，下图对不同的状态（对于非同步调度表）以及它们之间的转换进行了说明。

如果调度表未被激活（此时操作系统（OS）将不会对其进行处理），则其状态应为 SCHEDULETABLE_STOPPED 状态。在被激活后，调度表的状态将被切换为 SCHEDULETABLE_RUNNING 状态，此时操作系统（OS）将会对（其中的）到期时间点进行处理。如果调用了切换调度表服务，则该调度表的状态将被切换为 SCHEDULETABLE_NEXT 状态，并等待对当前正在被处理的调度表的处理的结束。

重复地进行对调度表的处理

在对最后一个到期时间点的处理结束后，可能会重复地进行对该调度表的处理（也可能不会）。这将导致两种行为：

单次执行：调度表将按顺序对每个到期时间点进行处理，并在处理完毕后结束。这适用于对某些触发条件进行响应，并分阶段执行一系列操作。

重复执行：调度表将按顺序对每个到期时间点进行处理，在对最后一个到期时间点的处理结束后将继续从头开始执行。这适用于构建需要被重复执行的应用程序，或需要同步对底层驱动程序的处理的系统。

重复地进行对调度表的处理意味着，其中每个到期时间点都将以调度表的持续时间为周期被重复地处理。

[SWS_Os_00413]

[ ]

调度表可被配置为单次执行或重复执行。

[SWS_Os_00009]

[ ]

如果调度表被配置为单次执行，在对最后一个到期时间点的处理结束后，操作系统（OS）应停止对其结束延迟（以滴答为单位）进行处理。

[SWS_Os_00427]

[ ]

如果调度表被配置为单次执行，操作系统（OS）应允许结束延迟（以滴答为单位）的值为 0 到 OsCounterMaxAllowedValue 之间。

[SWS_Os_00444]

[ ]

如果调度表被配置为重复执行，操作系统（OS）应允许结束延迟（以滴答为单位）的值为 OsCounterMinCycle 到 OsCounterMaxAllowedValue 之间。

[SWS_Os_00194]

[ ]

如果调度表被配置为重复执行，在对最后一个到期时间点的处理结束后，操作系统（OS）应在结束延迟（以滴答为单位）后从头开始对调度表进行处理。

关于对调度表的处理的控制

应用程序应负责启动或停止对调度表的处理。

操作系统（OS）应提供 StartScheduleTableAbs 服务（参见 [SWS_Os_00358]），被用于当底层计数器的值等于参数 Start 的值时启动对调度表的处理（当底层计数器的值等于参数 Start + InitialOffset 时，则必须对调度表的初始到期时间点进行处理）。

操作系统（OS）应提供 StartScheduleTableRel 服务（参见 [SWS_Os_00347]），被用于当底层计数器的值相对于该服务被调用时的值的偏移量为参数 Offset 的值时启动对调度表的处理（当底层计数器的值等于该服务被调用时底层计数器的值 + 参数 Offset + InitialOffset 时，则必须对调度表的初始到期时间点进行处理）。

下图展示了由最大计数值为 65536 的计数器（即 OsCounterMaxAllowedValue = 65535）驱动的对调度表的两种不同的处理方式。

操作系统（OS）应提供 StopScheduleTable 服务（参见 [SWS_Os_00006]），可以在对调度表的处理过程中的任何时刻取消对调度表的处理。

[SWS_Os_00428]

[ ]

如果在对最后一个到期时间点的处理结束前，对调度表的处理被取消，随后又被重新启动，则根据 [SWS_Os_00358]、[SWS_Os_00347]，在调度表被重新启动后应从头开始对调度表进行处理。

操作系统（OS）应提供 NextScheduleTable 服务（参见 [SWS_Os_00191]），被用于从一个调度表切换到另一个调度表。

[SWS_Os_00414]

[ ]

当请求调度表切换时，操作系统（OS）应继续对当前调度表的到期时间点进行处理。在对最后一个到期时间点的处理结束后，应进行结束延迟（以滴答为单位），然后进行调度表切换。对初始到期时间点的处理将在初始时间偏移量（以滴答为单位）之后被进行。

操作系统（OS）应提供 GetScheduleTableStatus 服务（参见 [SWS_Os_00227]），被用于对调度表的状态进行查询。

调度表可被配置为在操作系统（OS）被启动时被自动地启动（参见第 10 章）（类似于 OSEK/VDX 操作系统（OS）中的任务和闹钟）。OSEK/VDX 操作系统（OS）定义了一个特定的顺序：对任务的自动激活先于对闹钟的自动激活。AUTOSAR 操作系统（OS）通过调度表对这一顺序进行了扩展。

[SWS_Os_00510]

[ ]

在启动过程中，操作系统（OS）应在任务和闹钟被自动地启动后处理对调度表的自动启动。

对调度表的同步

背景与理由

用户可以控制对调度表的初始到期时间点进行（首次）处理时的时间点（计数器的绝对值）。但是，如果调度表被配置为重复执行，则无法保证后续对调度表的初始到期时间点进行处理时的时间点（计数器的绝对值）与首次的相同。这是因为调度表的持续时间不一定与计数器的最大计数值相等。

在许多情况下，在底层计数器的值等于特定的（绝对）值时对调度表的到期时间点进行处理可能非常重要。这称为同步。典型的用例包括：

通过对到期时间点与旋转角度进行同步实现电机管理。

与全局（网络）时基进行同步。请注意，在 AUTOSAR 中，操作系统（OS）不提供全局（网络）时间源，因为：

在许多情况下，可能不需要全局时间。

其他 AUTOSAR 模块，尤其是 FlexRay，会对其提供独立于操作系统（OS）的全局时间。

如果操作系统（OS）需要与多个全局（网络）时间源进行同步（例如，在两个时间触发型网络之间构建网关时），则操作系统（OS）不能作为唯一的全局（网络）时间源。

AUTOSAR 操作系统（OS）提供两种方式以对同步进行支持：

隐式同步：对调度表进行驱动的计数器需要进行同步。这通常是与时间触发型网络（例如，FlexRay、TTP）进行同步的方式（底层硬件对网络时间同步进行管理，并通过定时器的输出/比较接口（函数）将时间提供给操作系统（OS））。下图显示了具有隐式同步的调度表的可能的状态。

显式同步：调度表由操作系统（OS）计数器驱动，但该计数器并非需要进行同步的计数器。操作系统（OS）将提供额外的功能，以确保对由操作系统（OS）计数器驱动的调度表的处理与同步计数器保持同步。这通常是与周期性广播的全局时间进行同步的方式。下图显示了具有显式同步的调度表的可能的状态。

需求

[SWS_Os_00013]

[SRS_Os_11002]

操作系统（OS）应提供将对调度表的处理与已知的计数器值进行同步的功能。

隐式同步

操作系统（OS）无需为调度表的隐式同步提供任何额外的支持。但是，必须在调度表的配置和在运行时（Runtime）中对其的控制方面进行限制，以便调度表的配置中的时间点（滴答）能够与计数器中的时间点（滴答）对齐。这要求调度表的持续时间（以滴答为单位）与计数器的最大计数值（以滴答为单位）相等（两者的时间点（滴答）的分辨率相同由调度表与计数器之间的交互的需求保证）：

[SWS_Os_00429]

[ ]

操作系统（OS）中具有隐式同步的调度表的持续时间应等于与其关联的 OSEK/VDX 操作系统（OS）计数器的 OsCounterMaxAllowedValue + 1。

为了同步对调度表的处理，必须确定处理开始时的计数器值。这意味着，只能以绝对计数器值（而不是相对计数器值）启动对具有隐式同步的调度表的处理。

[SWS_Os_00430]

[ ]

操作系统（OS）应阻止以相对计数值启动对具有隐式同步的调度表的处理。

当以绝对计数器值启动对调度表的处理时，每个到期时间点将在计数器值等于在服务调用中被指定的（绝对）值（以滴答为单位）加上到期时间点的偏移量（以滴答为单位）时被处理。常见用例是确保在调度表配置中被指定的偏移量（以滴答为单位）与底层计数器的绝对值（以滴答为单位）相对应。这可以通过对 StartScheduleTableAbs(Tbl, 0) 进行调用轻松实现，如下所示。

显式同步

具有显式同步的调度表需要操作系统（OS）提供额外的支持。调度表通常由操作系统（OS）计数器（被称为“驱动计数器”）驱动，但对其的处理需要与另一个计数器（被称为“同步计数器”）进行同步，该计数器并非操作系统（OS）计数器。

对于调度表、驱动计数器以及同步计数器，必须强制执行以下约束：

约束 1：

[SWS_Os_00431]

[ ]

具有显式同步的调度表的持续时间不得超过驱动计数器的最大计数值。

约束 2：

[SWS_Os_00462]

[ ]

具有显式同步的调度表的持续时间应等于同步计数器的最大计数值。

约束 3：

[SWS_Os_00463]

[ ]

同步计数器的分辨率应与驱动计数器（与调度表关联的）的分辨率相同。这意味着每个滴答之间的间隔时长对于调度表与同步计数器而言应是相同的。

请注意，操作系统（OS）有责任对其自身是否满足约束 2 和 3 进行验证。

显式同步的功能是使操作系统（OS）在同步计数器的绝对值与到期时间点的偏移量（以滴答为单位）相等时，持续地对每个到期时间点进行处理。这意味着显式同步始终假定对调度表的处理开始时的时间点必须与同步计数器的绝对值为零时的时间点同步。

为了实现这一点，必须告知操作系统（OS）关于同步计数器的值。由于同步计数器的最大计数值与调度表的持续时间（以滴答为单位）相等，操作系统（OS）可以通过此信息计算漂移时间。然后，操作系统（OS）会自动地对到期时间点的偏移量（以滴答为单位）进行调整，根据需要提前或延后对到期时间点的处理，以保持同步。

启动

启动具有显式同步的调度表有两种方式：

异步启动：当同步计数器的绝对值为任意值时启动对调度表的处理。

同步启动：当同步计数器的绝对值为零时启动对调度表的处理（仅当同步计数器的值被提供时），这可能意味着因此造成的等待将没有限期。

现有的在绝对时间点或相对时间点对调度表进行启动的服务都支持异步启动。这两个服务都依据驱动计数器（而非同步计数器）的值设置对初始到期时间点进行处理时的时间点。这使得可以在同步计数器的值为未知的情况下启动对调度表的处理。

同步启动需要一个额外的服务，该服务仅在操作系统（OS）获知同步计数器的值后才启动对调度表的处理。

操作系统（OS）应提供 StartScheduleTableSynchron 服务（参见 [SWS_Os_00201]），以支持以同步启动的方式启动对具有显式同步的调度表的处理。对初始到期时间点的处理将在驱动计数器的值为（调度表的持续时间 - 同步计数器的绝对值）+ 初始到期时间点的偏移量时进行。

[SWS_Os_00435]

[ ]

如果以同步启动的方式启动对具有显式同步的调度表的处理，那么操作系统（OS）应保证在对 StartScheduleTableSynchron 服务进行调用后，该调度表将处于 SCHEDULETABLE_WAITING 状态。

提供同步计数器的值

操作系统（OS）应知晓同步计数器的值。由于调度表的持续时间与同步计数器的最大计数值相等，操作系统（OS）可以通过同步计数器的值确定调度表当前所处的时间点（以滴答为单位）与同步计数器的值之间的差距，并决定是否需要进行同步操作。

操作系统（OS）应提供 SyncScheduleTable 服务（参见 [SWS_Os_00199]），被用于向调度表提供同步计数器的值并以同步启动的方式启动对调度表的处理。

指定同步范围

默认情况下，不允许对调度表的任何到期时间点进行调整。仅当调度表被配置为显式同步时才允许对其进行调整。操作系统（OS）对到期时间点进行调整的被允许的范围由以下参数决定：

OsScheduleTableMaxShorten：到期时间点的偏移量可被减少的最大值（以滴答为单位）

OsScheduleTableMaxLengthen：到期时间点的偏移量可被增加的最大值（以滴答为单位）

下图展示了参数 OsScheduleTableMaxShorten 和 OsScheduleTableMaxLengthen 为不同值时的行为：

[SWS_Os_00415]

[ ]

应允许对到期时间点的参数 OsScheduleTableMaxShorten 进行配置，以定义到期时间点的偏移量可被减少的最大值（以滴答为单位）。

[SWS_Os_00416]

[ ]

应允许对到期时间点的参数 OsScheduleTableMaxLengthen 进行配置，以定义到期时间点的偏移量可被增加的最大值（以滴答为单位）。

进行同步时，必须确保调度表的到期时间点按照其在调度表中的顺序（由其偏移量定义）被处理。这意味着由参数 OsScheduleTableMaxShorten 和 OsScheduleTableMaxLengthen 定义的范围存在在调度表的同一个迭代周期内（不会发生范围跨越迭代周期的情况）。

[SWS_Os_00436]

[ ]

到期时间点的偏移量 - OsScheduleTableMaxShorten 的值应大于前一个到期时间点的偏移量 + OsCounterMinCycle 的值。

[SWS_Os_00559]

[ ]

OsScheduleTableMaxLengthen 的值应小于调度表的持续时间。

[SWS_Os_00437]

[ ]

到期时间点的 OsScheduleTableMaxLengthen + 距离上一个到期时间点的偏移量的值应小于底层计数器的 OsCounterMaxAllowedValue 的值。

具有显式同步的调度表应允许驱动计数器的值与同步计数器的值之间存在一定的偏差。此偏差可被设置为零，表示除非两者完全相同，否则不被视为同步。

[SWS_Os_00438]

[ ]

调度表应定义一个精度范围，其取值范围为 0 到调度表的持续时间。

执行同步

通过同步计数器的值，操作系统（OS）在每个到期时间点对调度表进行（重新）同步，方法是计算对于到下一个到期时间点的延迟的调整。与在最后一个到期时间点执行此操作相比，这可以更快地对调度表进行（重新）同步。

[SWS_Os_00206]

[SRS_Os_11002]

当新的同步计数器的值被提供时，操作系统（OS）应计算当前具有显式同步的调度表（的驱动计数器的值）与同步计数器的值之间的偏差。

在同步计数器的值被提供之前尝试对具有显式同步的调度表进行同步是没有意义的。

[SWS_Os_00417]

[ ]

操作系统（OS）应在同步计数器的值被提供之后开始对具有显式同步的调度表进行同步，并持续地对到期时间点进行调整直至同步完成。

[SWS_Os_00418]

[ ]

如果偏差小于或等于被配置的 OsScheduleTblExplicitPrecision（精度范围），操作系统（OS）应将具有显式同步的调度表的状态设置为“运行中且同步”。

[SWS_Os_00419]

[ ]

如果偏差大于被配置的 OsScheduleTblExplicitPrecision，操作系统（OS）应将具有显式同步的调度表的状态设置为“运行中”。

[SWS_Os_00420]

[ ]

如果偏差不为零，且下一个到期时间点可被调整，并且其所处的调度表落后于同步计数器（TableTicksAheadOfSyncCounter <= TableTicksBehindOfSyncCounter），则操作系统（OS）应在当前到期时间点将调度表（的驱动计数器的值）调整为到下一个到期时间点的延迟 - min(MaxShorten, Deviation) 的值（以滴答为单位）。

[SWS_Os_00421]

[ ]

如果偏差不为零，且下一个到期时间点可被调整，并且其所处的调度表超前于同步计数器（TableTicksAheadOfSyncCounter > TableTicksBehindOfSyncCounter），则操作系统（OS）应在当前到期时间点将调度表（的驱动计数器的值）调整为到下一个到期时间点的延迟 + min(MaxLengthen, Deviation) 的值（以滴答为单位）。

图 7.8 显示了对具有显式同步的调度表的同步。它假设以下条件：

EP1-3 的 OsScheduleTableMaxLengthen 为 2

EP1-3 的 OsScheduleTableMaxShorten 为 1

操作系统（OS）应提供 SetScheduleTableAsync 服务（参见 [SWS_Os_00422]），被用于取消正在被进行的调度表中在可被调整的到期时间点处的同步操作。

操作系统（OS）应提供 GetScheduleTableStatus 服务（参见 [SWS_Os_00227]），被用于对调度表的状态进行查询（包括同步状态）。

Stack Monitoring Facilities

Background & Rationale

On processors that do not provide any memory protection hardware it may still be necessary to provide a "best effort with available resources" scheme for detectable classes of memory faults. Stack monitoring will identify where a Task or ISR has exceeded a specified stack usage at context switch time. This may mean that there is considerable time between the system being in error and that fault being detected. Similarly, the error may have been cleared at the point the fault is notified (the stack may be less than the specified size when the context switch occurs).

It is not usually sufficient to simply monitor the entire stack space for the system because it is not necessarily the Task/ISR that was executing that used more than stack space than required - it could be a lower priority object that was pre-empted.

Significant debugging time can be saved by letting the Operating System correctly identify the Task/Category 2 ISR in error.

Note that for systems using an MPU and scalability class 3 or 4 a stack overflow may cause a memory exception before the stack monitoring is able to detect the fault.

Requirements

[SWS_Os_00067]

[SRS_Os_11003]

The Operating System module shall provide a stack monitoring which detects possible stack faults of Task(s)/Category 2 ISR(s).

[SWS_Os_00068]

[SRS_Os_11003]

[SRS_Os_11013]

If a stack fault is detected by stack monitoring AND no ProtectionHook is configured, the Operating System module shall call the ShutdownOS service with the status E_OS_STACKFAULT.

[SWS_Os_00396]

[ ]

If a stack fault is detected by stack monitoring AND a ProtectionHook is configured the Operating System module shall call the ProtectionHook with the status E_OS_STACKFAULT.

OS-Application

Background & Rationale

An AUTOSAR OS must be capable of supporting a collection of Operating System objects (Tasks, ISRs, Alarms, ScheduleTables, Counters) that form a cohesive functional unit. This collection of objects is termed an OS-Application.

The Operating System module is responsible for scheduling the available processing resource between the OS-Applications that share the processor. If OS-Application(s) are used, all Tasks, ISRs, Counters, Alarms and ScheduleTables must belong to an OS-Application. All objects which belong to the same OS-Application have access to each other. The right to access objects from other OS-Applications may be granted during configuration. An Event is accessible if the Task for which the event can be set is accessible. Access means that these Operating System objects are allowed as parameters to API services.

There are two classes of OS-Application:

Trusted OS-Applications are allowed to run with monitoring or protection features disabled at runtime. They may have unrestricted access to memory, the Operating System module's API, and need not have their timing behaviour enforced at runtime. They are allowed to run in privileged mode when supported by the processor. The Operating System module assumes that trusted OS-Applications (and trusted functions) do not cause a memory related protection fault. If such a fault happens the system stability is likely gone and a shutdown may be the only option.

Non-Trusted OS-Applications are not allowed to run with monitoring or protection features disabled at runtime. They have restricted access to memory, restricted access to the Operating System module's API and have their timing behaviour enforced at runtime. They are not allowed to run in privileged mode when supported by the processor.

It is assumed that the Operating System module itself is trusted.

There are services offered by the AUTOSAR OS which give the caller information about the access rights and the membership of objects. These services are intended to be used in case of an inter-OS-Application call for checking access rights and arguments.

Note that Resource objects do not belong to any OS-Application, but access to them must be explicitly granted. (The same principle applies to spinlocks in Multi-Core systems)

The running OS-Application is defined as the OS-Application to which the currently running Task or ISR belongs. In case of a hook routine the Task or ISR which caused the call of the hook routine defines the running OS-Application.

OS-Applications have a state which defines the scope of accessibility of its Operating System objects from other OS-Applications. Each OS-Application is always in one of the following states:

Active and accessible (APPLICATION_ACCESSIBLE): Operating System objects may be accessed from other OS-Applications. This is the default state at startup.

Currently in restart phase (APPLICATION_RESTARTING). Operating System objects cannot be accessed from other OS-Applications. State is valid until the OS-Application calls AllowAccess.

Terminated and not accessible (APPLICATION_TERMINATED): Operating System objects cannot be accessed from other OS-Applications. State will not change.

The following figure shows the states and the possible transitions:

Requirements

[SWS_Os_00445]

[ ]

The Operating System module shall support OS-Applications which are a configurable selection of Trusted Functions, Tasks, ISRs, Alarms, ScheduleTables, Counters, hooks (for startup, error and shutdown).

[SWS_Os_00446]

[ ]

The Operating System module shall support the notion of trusted and non-trusted OS-Applications.

[SWS_Os_00464]

[ ]

Trusted OS-Applications may offer services ("trusted services") to other (even non-trusted) OS-Applications.

The Operating System module provides the services GetApplicationID and GetCurrentApplicationID (see [SWS_Os_00016]) to determine the configured resp. currently executing OS-Application (a unique identifier shall be allocated to each application).

The Operating System module provides the service CheckObjectOwnership (see [SWS_Os_00017]) to determine to which OS-Application a given Task, ISR, Counter, Alarm or ScheduleTable belongs.

The Operating System module provides the service CheckObjectAccess (see [SWS_Os_00256]) to determine which OS-Applications are allowed to use the IDs of a Task, Resource, Counter, Alarm or ScheduleTable in API calls.

The Operating System module provides the service TerminateApplication (see [SWS_Os_00258]) to terminate the OS-Application to which the calling Task/Category 2 ISR/application specific error hook belongs. (This is an OS-Application level variant of the TerminateTask service)

The Operating System provides the service TerminateApplication (see [SWS_Os_00258]) to terminate another OS-Application AND calls to this service shall be ignored if the caller does not belong to a trusted OS-Application.

[SWS_Os_00447]

[SRS_Os_11022]

If the Operating System module terminates an OS-Application, then it shall:

terminate all running, ready and waiting Tasks/ISRs of the OS-Application AND

disable all interrupts of the OS-Application AND

stop all active alarms of the OS-Applications AND

stop all ScheduleTables of the OS-Application.

[SWS_Os_00448]

[ ]

The Operating System module shall prevent access of OSApplications, trusted or non-trusted, to objects not belonging to this OS-Application, except access rights for such objects are explicitly granted by configuration.

The Operating System provides the service GetApplicationState (see [SWS_Os_00499]) to request the current state of an OS-Application.

[SWS_Os_00500]

[ ]

The Operating System module shall set the state of all OSApplications after the call of StartOS and before any StartupHook is called to APPLICATION_ACCESSIBLE.

The Operating System module provides the service AllowAccess (see [SWS_Os_00501]) to set the own state of an OS-Application from APPLICATION_RESTARTING to APPLICATION_ACCESSIBLE.

[SWS_Os_00502]

[ ]

If an OS-Application is terminated (e.g. through a service call or via protection hook) and no restart is requested, then the Operating System module shall set the state of this OS-Application to APPLICATION_TERMINATED.

[SWS_Os_00503]

[SRS_Os_11023]

If an OS-Application is terminated (e.g. through a service call or via protection hook) and a restart is requested, then the Operating System module shall set the state of this OS-Application to APPLICATION_RESTARTING.

[SWS_Os_00504]

[ ]

The Operating System module shall deny access to Operating System objects from other OS-Applications to an OS-Application which is not in state APPLICATION_ACCESSIBLE.

[SWS_Os_00509]

[ ]

If a service call is made on an Operating System object that is owned by another OS-Application without state APPLICATION_ACCESSIBLE, then the Operating System module shall return E_OS_ACCESS.

An example for [SWS_Os_00509] is a call to ActivateTask for a Task in an OSApplication that is restarting.

Protection Facilities

Protection is only possible for Operating System managed objects. This means that:

It is not possible to provide protection during runtime of Category 1 ISRs, because the operating system is not aware of any Category 1 ISRs being invoked. Therefore, if any protection is required, Category 1 ISRs have to be avoided. If Category 1 interrupts AND OS-Applications are used together then all Category 1 ISR must belong to a trusted OS-Application.

It is not possible to provide protection between functions called from the body of the same Task/Category 2 ISR.

Memory Protection

Background & Rationale

Memory protection will only be possible on processors that provide hardware support for memory protection.

The memory protection scheme is based on the (data, code and stack) sections of the executable program.

Stack: An OS-Application comprises a number of Tasks and ISRs. The stack for these objects, by definition, belongs only to the owner object and there is therefore no need to share stack data between objects, even if those objects belong to the same OS-Application.

Memory protection for the stacks of Tasks and ISRs is useful mainly for two reasons:

Provide a more immediate detection of stack overflow and underflow for the Task or ISR than can be achieved with stack monitoring

Provide protection between constituent parts of and OS-Application, for example to satisfy some safety constraints.

Data: OS-Applications can have private data sections and Tasks/ISRs can have private data sections. OS-Application's private data sections are shared by all Tasks/ ISRs belonging to that OS-Application.

Code: Code sections are either private to an OS-Application or can be shared between all OS-Applications (to use shared libraries). In the case where code protection is not used, executing incorrect code will eventually result in a memory, timing or service violation.

Requirements

Data Sections and Stack

[SWS_Os_00198]

[SRS_Os_11006]

The Operating System module shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications.

[SWS_Os_00795]

[SRS_Os_11005]

The OS shall offer the possibility to restrict write access of trusted OS-Applications in the same way as it is done for non-trusted OS-Applications.

This can be configured with the OsTrustedApplicationWithProtection.

Private data of an OS-Application

[SWS_Os_00026]

[SRS_Os_11000]

The Operating System module may prevent read access to an OS-Application's data section attempted by other non-trusted OS-Applications.

[SWS_Os_00086]

[SRS_Os_11006]

The Operating System module shall permit an OS-Application read and write access to that OS-Application's own private data sections.

[SWS_Os_00207]

[SRS_Os_11005]

The Operating System module shall prevent write access to the OS-Application's private data sections from other non-trusted OS-Applications.

Private Stack of Task/ISR

[SWS_Os_00196]

[SRS_Os_11006]

The Operating System module shall permit a Task/Category 2 ISR read and write access to that Task's/Category 2 ISR's own private stack.

[SWS_Os_00208]

[SRS_Os_11005]

The Operating System module may prevent write access to the private stack of Tasks/Category 2 ISRs of a non-trusted application from all other Tasks/ISRs in the same OS-Application.

[SWS_Os_00355]

[ ]

The Operating System module shall prevent write access to all private stacks of Tasks/Category 2 ISRs of an OS-Application from other non-trusted OS-Applications.

Private data of a Task/ISR

[SWS_Os_00087]

[SRS_Os_11006]

The Operating System module shall permit a Task/Category 2 ISR read and write access to that Task's/Category 2 ISR's own private data sections.

[SWS_Os_00195]

[SRS_Os_11005]

The Operating System module may prevent write access to the private data sections of a Task/Category 2 ISR of a non-trusted application from all other Tasks/ISRs in the same OS-Application.

[SWS_Os_00356]

[ ]

The Operating System module shall prevent write access to all private data sections of a Task/Category 2 ISR of an OS-Application from other nontrusted OS-Applications.

Code Sections

[SWS_Os_00027]

[ ]

The Operating System module may provide an OS-Application the ability to protect its code sections against executing by non-trusted OS-Applications.

[SWS_Os_00081]

[SRS_Os_11007]

The Operating System module shall provide the ability to provide shared library code in sections that are executable by all OS-Applications.

Peripherals

[SWS_Os_00209]

[ ]

If OsTrustedApplicationWithProtection == FALSE then the Operating System module shall permit trusted OS-Applications read and write access to peripherals.

[SWS_Os_00083]

[ ]

The Operating System module shall allow non-trusted OSApplications to write to their assigned peripherals only (incl. reads that have the side effect of writing to a memory location).

Memory Access Violation

[SWS_Os_00044]

[SRS_Os_11013]

If a memory access violation is detected, the Operating System module shall call the ProtectionHook with status code E_OS_PROTECTION_MEMORY.

Timing Protection

Background & Rationale

A timing fault in a real-time system occurs when a Task or interrupt misses its deadline at runtime.

AUTOSAR OS does not offer deadline monitoring for timing protection. Deadline monitoring is insufficient to correctly identify the Task/ISR causing a timing fault in an AUTOSAR system. When a deadline is violated this may be due to a timing fault introduced by an unrelated Task/ISR that interferes/blocks for too long. The fault in this case lies with the unrelated Task/ISR and this will propagate through the system until a Task/ISR misses its deadline. The Task/ISR that misses a deadline is therefore not necessarily the Task/ISR that has failed at runtime, it is simply the earliest point that a timing fault is detected.

If action is taken based on a missed deadline identified with deadline monitoring this would potentially use false evidence of error to terminate a correct OS-Application in favor of allowing an incorrect OS-Application to continue running. The problem is best illustrated by example. Consider a system with the following configuration:

Assuming that all Tasks are ready to run at time zero, the following execution trace would be expected and all Tasks would meet their respective deadlines.

Now consider the case when Tasks A and B behave incorrectly. The figure below shows both Task A and Task B executing for longer than specified and Task B arriving 2 ticks earlier than specified. Both Tasks A and B meet their deadlines. Task C however, behaves correctly but it fails to meet its deadline because of the incorrect execution of Tasks A and B. This is fault propagation - a fault in an unrelated part of the system is causing a correctly functioning part of the system to fail.

Whether a Task or ISR meets its deadline in a fixed priority preemptive operating system like AUTOSAR OS is determined by the following factors:

the execution time of Task/ISRs in the system

the blocking time that Task/ISRs suffers from lower priority Tasks/ISRs locking shared resources or disabling interrupts

the interarrival rate of Task/ISRs in the system

For safe and accurate timing protection it is necessary for the operating system to control these factors at runtime to ensure that Tasks/ISRs can meet their respective deadlines.

AUTOSAR OS prevents timing errors from (1) by using execution time protection to guarantee a statically configured upper bound, called the Execution Budget, on the execution time of:

Tasks

Category 2 ISRs

AUTOSAR OS prevents timing errors from (2) by using locking time protection to guarantee a statically configured upper bound, called the Lock Budget, on the time that:

Resources are held by Tasks/Category 2 ISRs

OS interrupts are suspended by Tasks/Category 2 ISRs

ALL interrupts are suspended/disabled by Tasks/Category 2 ISRs

AUTOSAR OS prevents timing errors from (3) by using inter-arrival time protection to guarantee a statically configured lower bound, called the Time Frame, on the time between:

A Task being permitted to transition into the READY state due to:

Activation (the transition from the SUSPENDED to the READY state)

Release (the transition from the WAITING to the READY state)

A Category 2 ISR arriving. An arrival occurs when the Category 2 ISR is recognized by the OS

Inter-arrival time protection for basic Tasks controls the time between successive activations, irrespective of whether activations are queued or not. In the case of queued activations, activating a basic Task which is in the READY or RUNNING state is a new activation because it represents the activation of a new instance of the Task. Interarrival time protection therefore interacts with queued activation to control the rate at which the queue is filled.

Inter-arrival time protection for extended Tasks controls the time between successive activations and releases. When a Task is in the WAITING state and multiple Events are set with a single call to SetEvent this represents a single release. When a Task waits for one or more Events which are already set this represents a notional Wait/ Release/Start transition and therefore is considered as a new release.

The following figure shows how execution time protection and inter-arrival time protection interact with the task state transition model for AUTOSAR OS.

Notes:

1. Inter-arrival time enforcement on Category 2 ISRs can be used to protect an ECU from a "babbling idiot" source of interrupts (e.g. a CAN controller taking an interrupt each time a frame is received from another ECU on the network).

2. Timing protection only applies to Tasks or Category 2 ISRs. There is no protection for Category 1 ISRs. If timing protection error occurs during a category 1 ISR, consistency of the Operating System module cannot be guaranteed. Therefore we discourage timing protection in systems with category 1 interrupts.

3. Timing protection does not apply before the Operating System module is started.

4. In the case of trusted OS-Applications it is essential that all timing information is correct, otherwise the system may fail at run-time. For a non-trusted OSApplication, timing protection can be used to enforce timing boundaries between executable objects.

Requirements

[SWS_Os_00028]

[SRS_Os_11008]

In a non-trusted OS-Application, the Operating System module shall apply timing protection to every Task/Category 2 ISR of this non-trusted OSApplication.

[SWS_Os_00089]

[SRS_Os_11008]

In a trusted OS-Application, the Operating System module shall provide the ability to apply timing protection to Tasks/Category 2 ISRs of this OSApplication.

[SWS_Os_00397]

[ ]

If no OS-Application is configured, the Operating System module shall be able to apply timing protection to Tasks/Category 2 ISRs.

Timing Protection: Tasks

[SWS_Os_00064]

[SRS_Os_11008]

[SRS_Os_11013]

If a Task's OsTaskExecutionBudget is reached then the Operating System module shall call the ProtectionHook with E_OS_PROTECTION_TIME.

[SWS_Os_00473]

[SRS_Os_11008]

The Operating System module shall reset a Task's OsTaskExecutionBudget on a transition to the SUSPENDED or WAITING states.

[SWS_Os_00465]

[SRS_Os_11008]

The Operating System module shall limit the inter-arrival time of Tasks to one per OsTaskTimeFrame.

[SWS_Os_00469]

[SRS_Os_11008]

The Operating System module shall start an OsTaskTimeFrame when a Task is activated successfully.

[SWS_Os_00472]

[SRS_Os_11008]

The Operating System module shall start an OsTaskTimeFrame when a Task is released successfully.

[SWS_Os_00466]

[ ]

If an attempt is made to activate a Task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the activation AND shall call the ProtectionHook with E_OS_PROTECTION_ARRIVAL.

[SWS_Os_00467]

[ ]

If an attempt is made to release a Task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the release AND shall call the ProtectionHook with E_OS_PROTECTION_ARRIVAL AND the event shall be set.

Timing Protection: ISRs

[SWS_Os_00210]

[SRS_Os_11013]

If a Category 2 ISR's OsIsrExecutionBudget is reached then the Operating System module shall call the ProtectionHook with E_OS_PROTECTION_TIME.

[SWS_Os_00474]

[SRS_Os_11008]

The Operating System module shall reset an ISR's OsIsrExecutionBudget when the ISR returns control to the OS or terminates.

[SWS_Os_00470]

[SRS_Os_11008]

The Operating System module shall limit the inter-arrival time of Category 2 ISRs to one per OsIsrTimeFrame.

[SWS_Os_00471]

[SRS_Os_11008]

The Operating System module shall measure the start of an OsIsrTimeFrame from the point at which it recognizes the interrupt (i.e. in the Operating System interrupt wrapper).

[SWS_Os_00048]

[SRS_Os_11008]

If Category 2 interrupt occurs before the end of the OsIsrTimeFrame then the Operating System module shall not execute the user provided ISR AND shall call the ProtectionHook with E_OS_PROTECTION_ARRIVAL.

Timing Protection: Resource Locking and Interrupt Disabling

[SWS_Os_00033]

[SRS_Os_11008]

[SRS_Os_11013]

[SRS_Os_11014]

If a Task/Category 2 ISR holds an OSEK Resource and exceeds the OsTaskResourceLockBudget (or OsIsrResourceLockBudget) , the Operating System module shall call the ProtectionHook with E_OS_PROTECTION_LOCKED.

[SWS_Os_00037]

[SRS_Os_11008]

[SRS_Os_11013]

[SRS_Os_11014]

If a Task/Category 2 ISR disables interrupts (via Suspend/Disable|All/OS|Interrupts()) and exceeds the configured OsIsrAllInterruptLockBudget (or OsIsrOsInterruptLockBudget or OsTaskAllInterruptLockBudget or OsTaskOsInterruptLockBudget) the Operating System module shall call the ProtectionHook with E_OS_PROTECTION_LOCKED.

Implementation Notes

Execution time enforcement requires hardware support, e.g. a timing enforcement interrupt. If an interrupt is used to implement the time enforcement, the priority of this interrupt has to be high enough to "interrupt" the supervised Tasks or ISRs.

Depending on the real hardware support this could mean that DisableAllInterrupts and SuspendAllInterrupts disable not all interrupts (e.g. all interrupts except of the interrupt used for timing protection) or that the usage of Category 1 ISRs - which bypass the Operating System (and also the timing protection) - is limited somehow.

The implementation has to document such implementation specific behaviour (e.g. the limitations when timing protection is used).

Service Protection

Background & Rationale

As OS-Applications can interact with the Operating System module through services, it is essential that the service calls will not corrupt the Operating System module itself. Service Protection guards against such corruption at runtime.

There are a number of cases to consider with Service Protection: An OS-Application makes an API call

with an invalid handle or out of range value.

in the wrong context, e.g. calling ActivateTask in the StartupHook.

or fails to make an API call that results in the OSEK OS being left in an undefined state, e.g. it terminates without a ReleaseResource call

that impacts on the behaviour of every other OS-Application in the system, e.g. ShutdownOS

to manipulate Operating System objects that belong to another OS-Application (to which it does not have the necessary permissions), e.g. an OS-Application tries to execute ActivateTask on a Task it does not own.

The OSEK OS already provides some service protection through the status codes returned from service calls and this will provide the basis for service protection. This means that service protection will only apply for the extended status of OSEK OS.

However, OSEK OS does not cover all the cases outlined above. The following sections describe - besides the mandatory extended status - the additional protection requirements to be applied in each of these cases.

Invalid Object Parameter or Out of Range Value

Background & Rationale

The current OSEK OS service calls already return E_OS_ID on invalid objects (i.e. objects not defined in the OIL file) and E_OS_VALUE for out of range values (e.g. setting an alarm cycle time less than OsCounterMinCycle).

Requirements

[SWS_Os_00051]

[SRS_Os_11009]

[SRS_Os_11013]

If an invalid address (address is not writable by this OSApplication) is passed as an out-parameter to an Operating System service, the Operating System module shall return the status code E_OS_ILLEGAL_ADDRESS.

Service Calls Made from Wrong Context

Background & Rationale

The current OSEK OS defines the valid calling context for service calls (see [2]), however protects against only a small set of these invalid calls, e.g. calling TerminateTask from a Category 2 ISR.

Note:

TerminateApplication: Only in case of self termination.

In the table above "C" indicates that validity is only "Checked in Extended status by E_OS_CALLEVEL" .

Requirements

[SWS_Os_00088]

[SRS_Os_11009]

[SRS_Os_11013]

If an OS-Application makes a service call from the wrong context AND is currently not inside a Category 1 ISR the Operating System module shall not perform the requested action (the service call shall have no effect) and return E_OS_CALLEVEL or the "invalid value" of the service.

Services with Undefined Behaviour

Background & Rationale

There are a number of situations where the behaviour of OSEK OS is undefined in extended status. This is unacceptable when protection is required as it would allow the Operating System module to be corrupted through its own service calls. The implementation of service protection for the Operating System module must therefore describe and implement a behaviour that does not jeopardize the integrity of the system or of any OS-Application which did not cause the specific error.

Requirements

Tasks ends without calling a TerminateTask or ChainTask

[SWS_Os_00052]

[SRS_Os_11009]

If a Task returns from its entry function without making a TerminateTask or ChainTask call, the Operating System module shall terminate the Task (and call the OsPostTaskHook if configured).

[SWS_Os_00069]

[SRS_Os_11009]

If a Task returns from its entry function without making a TerminateTask or ChainTask call AND the error hook is configured, the Operating System module shall call the ErrorHook (this is done regardless of whether the Task causes other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the Task leaves the RUNNING state.

[SWS_Os_00070]

[SRS_Os_11009]

[SRS_Os_11013]

If a Task returns from the entry function without making a TerminateTask or ChainTask call and still holds OSEK Resources, the Operating System module shall release them.

[SWS_Os_00239]

[ ]

If a Task returns from the entry function without making a TerminateTask or ChainTask call and interrupts are still disabled, the Operating System module shall enable them.

Category 2 ISR ends with locked interrupts or allocated resources

[SWS_Os_00368]

[ ]

If a Category 2 ISR calls DisableAllInterrupts / SuspendAllInterrupts / SuspendOSInterrupts and ends (returns) without calling the corresponding EnableAllInterrupts / ResumeAllInterrupts / ResumeOSInterrupts, the Operating System module shall perform the missing service and shall call the ErrorHook (if configured) with the status E_OS_DISABLEDINT.

[SWS_Os_00369]

[ ]

If a Category 2 ISR calls GetResource and ends (returns) without calling the corresponding ReleaseResource, the Operating System module shall perform the ReleaseResource call and shall call the ErrorHook (if configured) with the status E_OS_RESOURCE (see [12], section 13.1).

PostTaskHook called during ShutdownOS

[SWS_Os_00071]

[ ]

If the PostTaskHook is configured, the Operating System module shall not call the hook if ShutdownOS is called.

Tasks/ISRs calls EnableAllInterrupts/ResumeAllInterrupts/ResumeOSInterrupts without a corresponding disable

[SWS_Os_00092]

[SRS_Os_11009]

If EnableAllInterrupts / ResumeAllInterrupts / ResumeOSInterrupts are called and no corresponding DisableAllInterrupts / SuspendAllInterrupts / SuspendOSInterrupts was done before, the Operating System module shall not perform this Operating System service.

Tasks/ISRs calling OS services when DisableAllInterupts/SuspendAllInterrupts/ SuspendOSInterrupts called

[SWS_Os_00093]

[SRS_Os_11009]

[SRS_Os_11013]

If interrupts are disabled/suspended by a Task/ISR/Hook and the Task/ISR/Hook calls any Operating System service (excluding the interrupt services) then the Operating System module shall ignore the service AND shall return E_OS_DISABLEDINT if the service returns a StatusType value.

Service Restrictions for Non-Trusted OS-Applications

Background & Rationale

The Operating System service calls available are restricted according to the calling context (see 7.7.3.3). In a protected system, additional constraints need to be placed to prevent non-trusted OS-Applications executing API calls that can have a global effect on the system. Each level of restriction is a proper subset of the previous level as shown in the figure below.

There are two defined integrity levels:

Trusted

Non-Trusted

that correspond exactly with trusted and non-trusted OS-Applications.

Requirements

[SWS_Os_00054]

[ ]

The Operating System module shall ignore calls to ShutdownOS from non-trusted OS-Applications.

Service Calls on Objects in Different OS-Applications

Background

Section 7.7.3.2 stated that E_OS_ID is returned by OSEK OS service calls when the object is invalid. Under the protection scheme a service call can be invalid because the caller does not have valid permissions for the object (a new meaning for multi-OSApplication systems).

This is a similar case to an object not being accessible in OSEK OS (for example, when a Task tries to get a Resource which exists in the system but has not been configured as used by the Task).

Requirements

[SWS_Os_00056]

[SRS_Os_11001]

[SRS_Os_11010]

[SRS_Os_11013]

If an OS-object identifier is the parameter of an Operating System module's system service, and no sufficient access rights have been assigned to this OS-object at configuration time (parameter Os[...]AccessingApplication, e.g. OsTaskAccessingApplication) to the calling Task/Category 2 ISR, the Operating System module's system service shall return E_OS_ACCESS.

[SWS_Os_00449]

[ ]

CheckTaskMemoryAccess and CheckISRMemoryAccess check the memory access. Memory access checking is possible for all OS-Applications and from all OS-Applications and does not need granted rights.

[SWS_Os_00449] is an exception to [SWS_Os_00056].

[SWS_Os_00450]

[ ]

CheckObjectAccess checks the access rights for Operating System objects. Checking object access is possible for all OS-Applications and from all OS-Applications and does not need granted rights.

[SWS_Os_00450] is an exception to [SWS_Os_00056].

Protecting the Hardware used by the OS

Background & Rationale

Where a processor supports privileged and non-privileged mode it is usually the case that certain registers, and the instructions to modify those registers, are inaccessible outside the privileged mode.

On such hardware, executing the Operating System module in privileged mode and Tasks/ISRs in non-privileged mode protects the registers fundamental to Operating System module operation from inadvertent corruption by the objects executing in nonprivileged mode. The Operating System module's services will need to execute in privileged mode as they will need to modify the registers that are protected outside this mode.

The Operating System module can use the control registers of the MPU, timer unit(s), interrupt controller, etc. and therefore it is necessary to protect those registers against non-trusted OS-Applications.

Requirements

[SWS_Os_00058]

[ ]

If supported by hardware, the Operating System module shall execute non-trusted OS-Applications in non-privileged mode.

[SWS_Os_00096]

[SRS_Os_11011]

As far as supported by hardware, the Operating System module shall not allow non-trusted OS-Applications to access control registers managed by the Operating System module.

[SWS_Os_00245]

[SRS_Os_11011]

If an instruction exception occurs (e.g. division by zero) the Operating System module shall call the protection hook with E_OS_PROTECTION_EXCEPTION.

Implementation Notes

When the Operating System module is running non-trusted OS-Applications, the Operating System module's treatment of interrupt entry and hook routines must be carefully managed.

Interrupt handling: Where the MCU supports different modes (as discussed in this section) ISRs will require the Operating System module to do extra work in the ISR() wrapper. ISRs will typically be entered in privileged mode. If the handler is part of a non-trusted OS-Application then the ISR() wrapper must make sure that a switch to non-privileged mode occurs before the handler executes.

Providing Trustedfunctions

Background & Rationale

An OS-Application can invoke a Trustedfunction provided by (another) trusted OSApplication. That can require a switch from non-privileged to privileged mode. This is typically achieved by these operations:

Each trusted OS-Application may export services which are callable from other OS-Applications.

During configuration these trusted services must be configured to be called from a non-trusted OS-Application.

The call from the non-trusted OS-Application to the trusted service is using a mechanism (e.g. trap/software interrupt) provided by the Operating System. The service is passed as an identifier that is used to determine, in the trusted environment, if the service can be called.

The Operating System offers services to check if a memory region is write/read/execute accessible from an OS-Application. It also returns information if the memory region is part of the stack space.

The Operating System software specification does not provide support for non-trusted services.

Requirements

[SWS_Os_00451]

[ ]

The Operating System module shall allow exporting services from trusted OS-Applications.

The Operating System module provides the service CallTrustedFunction (see [SWS_Os_00097]) to call a trusted function from a (trusted or non-trusted) OSApplication.

[SWS_Os_00100]

[ ]

If CallTrustedFunction is called and the called trusted function is not configured the Operating System module shall call the ErrorHook with E_OS_SERVICEID.

The Operating System module provides the services CheckISRMemoryAccess and CheckTaskMemoryAccess (see [SWS_Os_00512] and [SWS_Os_00513]) for OSApplications to check if a memory region is write/read/execute accessible from a Task/ Category 2 ISR and also return information if the memory region is part of the stack space.

Protection Error Handling

Background & Rationale

The Operating System can detect protection errors based on statically configured information on what the constituent parts of an OS-Application can do at runtime. See section 7.7.

Unlike monitoring, protection facilities will trap the erroneous state at the point the error occurs, resulting in the shortest possible time between transition into an erroneous state and detection of the fault. The different kinds of protection errors are described in the glossary. If a protection error occurs before the Operating System module is started the behaviour is not defined. If a protection error happens during shutdown, e.g. in the application-specific shutdown hook, an endless loop between the shutdown service and the protection hook may occur.

In the case of a protection error, the Operating System module calls a user provided ProtectionHook for the notification of protection errors at runtime. The ProtectionHook runs in the context of the Operating System module and must therefore be trusted code.

The Operating System module itself needs only to detect an error and provide the ability to act. The ProtectionHook can select one out of four options the Operating System module provides, which will be performed after returning from the ProtectionHook, depending on the return value of the ProtectionHook. The options are:

do nothing

forcibly terminate the faulty Task/Category 2 ISR

forcibly terminate all Tasks and ISRs in the faulty OS-Application

without restart of the OS-Application

with restart of the OS-Application

shutdown the Operating System module.

Requirements [SWS_Os_00243] and [SWS_Os_00244] define the order of the default reaction if no faulty Task/Category 2 ISR or OS-Application can be found, e.g. in the system specific hook routines. Also OS-Applications are only mandatory in Scalability Classes 3 and 4, therefore in other Scalability Classes OS-Applications need not be defined.

Note that forcibly terminating interrupts is handled differently in "forcibly terminate the faulty ISR" and "forcibly terminate the OS-Application". If a faulty ISR is forcibly terminated, the current invocation of the ISR is terminated. A subsequent invocation is allowed. If the OS-Application is forcibly terminated, then the interrupt source is also disabled, preventing subsequent interrupts.

Notes regarding the return value PRO_IGNORE

The meaning of "do nothing" (PRO_IGNORE) means that the error reaction is ignored. The PRO_IGNORE is only allowed in specific situations (currently: arrival rate errors). After the error is detected (e.g. as specified in [SWS_Os_00466] or [SWS_Os_00467]) the protection hook is called. If the hook returns with PRO_IGNORE the OS does continue its normal operation. If a service call was the root cause of the violation (e.g. an ActivateTask) and protection hook returns PRO_IGNORE the service call shall continue its operation (e.g. to activate a Task) and return E_OK (if successful and possible).

Example 1: A Task calls ActivateTask(B) and causes an arrival rate violation. The activation is not performed ([SWS_Os_00466]) and protection hook is called. When returning PRO_IGNORE the OS continues and the ActivateTask service activates B and returns E_OK.

Example 2: A Task A calls SetEvent for Task B (which currently waits for the event). The OS detects ([SWS_Os_00467]) an arrival rate violation and performs a call of the protection hook. When the call returns with PRO_IGNORE, the SetEvent service continues and sets the event. Task B changes to READY state and a rescheduling might happen. The SetEvent service call will return E_OK to Task A.

Requirements

[SWS_Os_00211]

[ ]

The Operating System module shall execute the ProtectionHook with the same permissions as the Operating System module.

[SWS_Os_00107]

[SRS_Os_11014]

If no ProtectionHook is configured and a protection error occurs, the Operating System module shall call ShutdownOS.

[SWS_Os_00106]

[SRS_Os_11014]

If the ProtectionHook returns PRO_IGNORE and was called with E_OS_PROTECTION_ARRIVAL the Operating System module shall return control to the user application.

[SWS_Os_00553]

[ ]

If the ProtectionHook returns PRO_TERMINATETASKISR the Operating System module shall forcibly terminate the faulty Task/Category 2 ISR.

[SWS_Os_00554]

[ ]

If the ProtectionHook returns PRO_TERMINATEAPPL the Operating System module shall forcibly terminate the faulty OS-Application.

[SWS_Os_00555]

[SRS_Os_11023]

If the ProtectionHook returns PRO_TERMINATEAPPL_RESTART the Operating System module shall forcibly terminate the faulty OS-Application and afterwards restart the OS-Application.

[SWS_Os_00556]

[ ]

If the ProtectionHook returns PRO_SHUTDOWN the Operating System module shall call the ShutdownOS.

[SWS_Os_00506]

[ ]

If the ProtectionHook is called with E_OS_PROTECTION_ARRIVAL the only valid return values are PRO_IGNORE or PRO_SHUTDOWN (The reason for this case is that the Task which is supervised is not necessary active (and can not be e.g. terminated) and it can be that the caller of the activation is the real problem). Returning other values will result in a call to ShutdownOS.

[SWS_Os_00475]

[ ]

If the ProtectionHook returns PRO_IGNORE and the ProtectionHook was not called with E_OS_PROTECTION_ARRIVAL then the Operating System module shall call ShutdownOS.

[SWS_Os_00243]

[SRS_Os_11014]

If the ProtectionHook returns PRO_TERMINATETASKISR and no Task or ISR can be associated with the error, the running OS-Application is forcibly terminated by the Operating System module. If even no OS-Application can be assigned, ShutdownOS is called.

[SWS_Os_00244]

[SRS_Os_11014]

If the ProtectionHook returns PRO_TERMINATEAPPL or PRO_TERMINATEAPPL_RESTART and no OS-Application can be assigned, ShutdownOS is called.

[SWS_Os_00557]

[ ]

If the ProtectionHook returns PRO_TERMINATEAPPL_RESTART and no OsRestartTask was configured for the faulty OS-Application, ShutdownOS is called.

[SWS_Os_00108]

[SRS_Os_11014]

If the Operating System module forcibly terminates a Task, it terminates the Task, releases all allocated OSEK resources and calls EnableAllInterrupts/ ResumeOSInterrupts / ResumeAllInterrupts if the Task called DisableAllInterrupts / SuspendOSInterrupts / SuspendAllInterrupts before without the corresponding EnableAllInterrupts/ ResumeOSInterrupts / ResumeAllInterrupts call.

[SWS_Os_00109]

[SRS_Os_11014]

If the Operating System module forcibly terminates an interrupt service routine, it clears the interrupt request, aborts the interrupt service routine (The interrupt source stays in the current state.) and releases all OSEK resources the interrupt service routine has allocated and calls EnableAllInterrupts / ResumeOSInterrupts / ResumeAllInterrupts if the interrupt called DisableAllInterrupts / SuspendOSInterrupts / SuspendAllInterrupts before without the corresponding EnableAllInterrupts/ ResumeOSInterrupts / ResumeAllInterrupts call.

[SWS_Os_00110]

[SRS_Os_11014]

If the Operating System module shall forcibly terminate an OSApplication, it shall :

forcibly terminate all Tasks/ISRs of the OS-Application AND

cancel all alarms of the OS-Application AND

stop ScheduleTables of the OS-Application AND

disable interrupt sources of Category 2 ISRs belonging to the OS-Application

[SWS_Os_00111]

[ ]

When the Operating System module restarts an OS-Application, it shall activate the configured OsRestartTask.

Operating System for Multi-Core

This chapter specifies some extensions that allow to use an AUTOSAR system on Multi-Core micro-processors. It describes the main philosophy as well as additional extensions to the existing OS functionality regarding Multi-Core. The following chapter contains a specification of a new mechanism within the OS called IOC (Inter OSApplication Communicator) that supports the communication between OS-Applications located on the same or on different cores

Background & Rationale

The existing AUTOSAR-OS is based on the OSEK/VDX Operating System which is widely used in the automotive industry. The AUTOSAR Multi-Core OS is derived from the existing AUTOSAR OS.

The Multi-Core OS in AUTOSAR is not a virtual ECU concept, instead it shall be understood as an OS that shares the same configuration and most of the code but operates on different data structures for each core.

To reduce the memory footprint all cores should use the same code base. Sometimes it can be beneficial to spend some more ROM/Flash, e.g. to use a local ROM, and "double" parts of the code to get faster ROM/Flash access.

Requirements

[SWS_Os_00567]

[SRS_Os_80008]

The generated part of the OS is derived from a single configuration that contains the relevant information for all cores. This implies, that IDs (e.g. TaskID, ResourceID, . . . ) are unique across cores. Every ID shall refer exactly to one entity independent from the core on which the entity is accessed. This applies also to objects that cannot be shared between cores.

Scheduling

The priority of the Tasks drives the scheduling. Since multiple cores run truly parallel, several Tasks can execute at the same time.

The OS can be entered on each core in parallel. This optimizes scalability towards multiple cores. The cores schedule independently. This implies that the schedule on one core does not consider the scheduling on the other cores (This also applies to Tasks with the same priority, bound to different cores. It also means that nonpreemptive Tasks cannot be preempted on the core they are running, but Tasks on other cores can run in parallel). A low priority Task on one core may run in parallel with a high priority Task on another core.

Tasks and ISRs cannot dynamically change cores by means of the scheduling algorithm.

Requirements

[SWS_Os_00568]

[SRS_Os_80001]

Implementations shall be able to independently execute a Task or an ISR on each started AUTOSAR OS core in parallel.

[SWS_Os_00569]

[SRS_Os_80001]

[SRS_Os_80013]

The scheduling strategy as defined in AUTOSAR OS shall apply for each individual core in a Multi-Core system, for the Tasks and ISR assigned to the core.

Locatable entities (LE)

A locatable entity is an entity that has to be located entirely on one core. The assignment of LEs to cores is defined at configuration time (OsApplicationCoreRef).

In this release of the AUTOSAR standard OS-Applications shall be the LEs. Because every Task has to run on some core, the usage of OS-Applications becomes obligatory in AUTOSAR R4.0 for Multi-Core systems. BSW modules are not allowed to ignore OSApplications, even if they do not use any protection mechanisms. This is independent from the SC class.

As is stated in the AUTOSAR Specification of the Operating System, if OS-Applications are used, all Tasks, ISR etc. must belong to an OS-Application. This implies, that no AUTOSAR software exists outside of an OS-Application in Multi-Core systems.

On single-core systems OS-Applications are available only for SC3 and SC4 because the mechanism is used to support memory protection and implies the usage of extended mode. In Multi-core systems OS-Applications are always available independent of memory protection and on SC1 standard mode shall be possible.

Requirements

[SWS_Os_00570]

[SRS_Os_80003]

[SRS_Os_80005]

All Tasks that are assigned to the same OS-Application shall execute on the same core.

[SWS_Os_00571]

[SRS_Os_80003]

[SRS_Os_80005]

All ISRs that are assigned to the same OS-Application shall execute on the same core.

[SWS_Os_00572]

[SRS_Os_80005]

[SRS_Os_80006]

ISR balancing (if supported by the HW) shall be switched off at boot time by the OS.

[SWS_Os_00764]

[ ]

The OS module shall support OS-Applications in case of MultiCore also for SC1 and SC2.

[SWS_Os_00763]

[ ]

In an SC1 system standard mode shall be possible.

[SWS_Os_00573]

[SRS_Os_80003]

[SRS_Os_80005]

The binding of OS-Applications to cores shall be configured within the OS-Application container.

A new configuration item: OsApplicationCoreRef within the OS-Application container shall be used to define the core to which the OS-Application is bound. The OS generator will map the configuration parameter "CORE" to a certain core, so that all OS-Applications with the same configuration parameter reside on the same core.

Multi-Core start-up concept

The way cores are started depends heavily on the hardware. Typically the hardware only starts one core, referred as the master core, while the other cores (slaves) remain in halt state until they are activated by the software.

In contrast to such a master-slave system other boot concepts with cores that start independently from each other are conceivable. However it is possible to emulate master-slave behavior on such systems by software.

The AUTOSAR Multi-Core OS specification requires a system with master-slave startup behavior, either supported directly by the hardware or emulated in software. The master core is defined to be the core that requires no software activation, whereas a slave core requires activation by software.

In Multi-Core configurations, each slave core that is used by AUTOSAR must be activated before StartOS is entered on the core. Depending on the hardware, it may be possible to only activate a subset of the available cores from the master. The slave cores might activate additional cores before calling StartOS. All cores that belong to the AUTOSAR system have to be activated by the designated AUTOSAR API function. Additionally, the StartOS function has to be called on all these cores.

If a core is activated it executes some HW and compiler specific operations, before the "main" function is called. In case the same "main" function is executed on each core, the cores have to be differentiated by their specific core Id within the function.

Example:

void main ()
{
    StatusType rv;
    /* ... */

    switch (GetCoreID())
    {
        case OS_CORE_ID_MASTER:
            /* ... */
            StartCore(OS_CORE_ID_0, &rv);
            StartOS(OSDEFAULTAPPMODE);
            break;

        case OS_CORE_ID_0:
            /* ... */
            StartCore(OS_CORE_ID_1, &rv);
            StartOS(DONOTCARE);
            break;

        otherwise:
            StartOS(DONOTCARE);
    }
}

StartOS synchronizes all cores twice. The first synchronization point is located before the StartupHooks are executed, the second after the OS-Application specific StartupHooks have finished and before the scheduler is started. The exact point where the second synchronization occurs depends on the implementation, but it shall be before the scheduling is started. This release of the AUTOSAR specification does not support timeouts during the synchronization phase. Cores that are activated with StartCore but do not call StartOS may cause the system to hang. It is in the responsibility of the integrator to avoid such behavior.

As shown in figure 7.16, the StartupHook is called on every core right after the first synchronization. However, there is only one StartupHook in the system. If, for example, core-individual functionality must be executed during StartupHook the GetCoreID function can be used to discriminate the individual cores. After the global StartupHook has finished each core performs the StartupHooks of its OS-Applications . Since OS-Applications are bound to cores the OS-Application specific StartupHooks are executed only on the core to which the corresponding OS-Application is bound.

Requirements

[SWS_Os_00574]

[SRS_Os_80006]

The master core shall be able to activate cores.

[SWS_Os_00575]

[SRS_Os_80006]

Any slave core shall be able to activate cores.

[SWS_Os_00576]

[SRS_Os_80006]

It shall be allowed to use only a subset of the cores available on a mcu for the AUTOSAR system.

[SWS_Os_00577]

[SRS_Os_80006]

The cores shall boot in master-slave mode. If this is not supported by the hardware, it shall be that the cores boot in parallel and emulate the behavior of a master-slave system.

[SWS_Os_00578]

[SRS_Os_80006]

In case of an emulation a slave core (CoreS), which is controlled by the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another core has activated the slave core by means of StartCore(CoreS).

[SWS_Os_00579]

[SRS_Os_80001]

[SRS_Os_80006]

All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global StartupHook is called.

[SWS_Os_00580]

[SRS_Os_80006]

All cores that belong to the AUTOSAR system shall be synchronized within the StartOS before the global StartupHook is called.

[SWS_Os_00581]

[SRS_Os_80006]

The global StartupHook shall be called on all cores immediately after the first synchronization point.

[SWS_Os_00582]

[SRS_Os_80006]

[SRS_Os_80008]

The OS-Application-specific StartupHooks shall be called after the global StartupHook but only on the cores to which the OS-Application is bound.

Cores under control of the AUTOSAR OS

The AUTOSAR OS controls several cores as stated above. It need not control all cores of a mcu, however. The maximum number of controlled cores shall be configured within the OsOS section of the configuration.

The AUTOSAR OS API provides a StartCore function to start the cores under its control. The StartCore function takes a scalar value parameter of type CoreIdType, specifying the core that shall be started. StartCore can be called more than once on the master core and also on slave cores. Each core can only be started once, however.

For example:

StartusType rv1, rv2;
StartCore(OS_CORE_ID_1, &rv1);
StartCore(OS_CORE_ID_2, &rv2);

if ((rv1 != E_OK) || (rv2 != E_OK))
    EnterPanicMode();

StartOS(OSDEFAULTAPPMODE);

The StartOS function shall be called on all cores that have been activated by StartCore. It is not allowed to call StartCore from a core that has already called StartOS.

Cores that belong to the AUTOSAR system shall be started by the designated AUTOSAR OS API service StartCore.

Requirements

[SWS_Os_00583]

[SRS_Os_80001]

[SRS_Os_80011]

The number of cores that can be controlled by the AUTOSAR OS shall be configured offline. A new configuration item (OsNumberOfCores) within the OsOS container is used to specify the maximum number of cores that are controlled by the AUTOSAR OS. If no value for OsNumberOfCores has been specified the number of cores shall be one.

Multi-Core shutdown concept

AUTOSAR supports two shutdown concepts, the synchronized shutdown and the individual shutdown concept. While the synchronized shutdown is triggered by the new API function ShutdownAllCores, the individual shutdown is invoked by the existing API function ShutdownOS.

Synchronized shutdown concept

If a Task with the proper rights calls ShutdownAllCores, a signal is sent to all other cores to induce the shutdown procedure. Once the shutdown procedure has started on a core, interrupts and Tasks are not further processed, and no scheduling will take place, therefore it makes no sense to activate any Task, however no error will be generated. It is in the responsibility of the application developer/system integrator to make sure that any preparations for shutdown on application and basic software level are completed before calling ShutdownAllCores (e.g. by means of the ECU state manager).

During the shutdown procedure every core executes its OS-Application specific ShutdownHook functions, followed by a synchronization point. After all cores have reached the synchronization point the global ShutdownHook function is executed by all cores in parallel.

[SWS_Os_00586]

[SRS_Os_80007]

During the shutdown, the OS-Application specific ShutdownHook shall be called on the core on which the corresponding OS-Application is bound.

[SWS_Os_00587]

[SRS_Os_80007]

Before calling the global ShutdownHook, all cores shall be synchronized.

[SWS_Os_00588]

[SRS_Os_80007]

The global ShutdownHook shall be called on all cores.

Individual shutdown concept

If a Task calls ShutdownOS the OS will be shut down on the core on which ShutdownOS has been called. Every core shall be able to invoke ShutdownOS . Similar to StartOS this function will shutdown the individual core. To shutdown the whole ECU ShutdownOS has to be called on every core. The function will not return.

Individual shutdown is not supported in AUTOSAR R4.x (AUTOSAR mode management will not use it).

Shutdown in case of fatal internal errors

In multicore systems it can happen that a fatal internal OS error is detected only on one core. In such cases a local shutdown of that core does not make sense.

[SWS_Os_00762]

[ ]

In cases where the OS detects a fatal internal error all cores shall be shut down.

OS service functionality (overview)

Within this chapter we describe which existing single core AUTOSAR OS functionality has been extended. The following table gives an overview of all standard OS API functions. The column "Multi-Core support" contains one of the following values:

Extended: The function that has been extended substantially to support special Multi-Core functionality.

Adapted: the function required some minor changes but basically remains unchanged.

Unchanged: the behavior of the function has not changed.

New: the function is a new AUTOSAR OS API-function.

[SWS_Os_00589]

[SRS_Os_80013]

[SRS_BSW_00459]

All functions that are not allowed to operate cross core shall return E_OS_CORE in extended status if called with parameters that require a cross core operation.

GetTaskID

GetTaskID can be called both from Task and Category 2 ISR level. When called from an interrupt routine, on Single-Core systems, GetTaskID returns either the interrupted Task or indicates that no Task is running. On Multi-Core systems it

indicates that no Task is running on the core or,

returns the ID of the interrupted Task on the core.

Interrupt disabling

Note:

All types of interrupts can only be disabled on the local core. This implies that the interrupt flags on other cores remain in their current state. Scheduling continues on the other cores. Running ISRs on other cores continue executing.

Requirements

[SWS_Os_00590]

[SRS_Os_80013]

The OS service DisableAllInterrupts shall only affect the core on which it is called.

[SWS_Os_00591]

[SRS_Os_80013]

The OS service EnableAllInterrupts shall only affect the core on which it is called.

[SWS_Os_00592]

[SRS_Os_80013]

The OS service SuspendAllInterrupts shall only affect the core on which it is called.

[SWS_Os_00593]

[SRS_Os_80013]

The OS service ResumeAllInterrupts shall only affect the core on which it is called.

[SWS_Os_00594]

[SRS_Os_80013]

The OS service SuspendOSInterrupts shall only affect the core on which it is called.

[SWS_Os_00595]

[SRS_Os_80013]

The OS service ResumeOSInterrupts shall only affect the core on which it is called.

Task activation

Task activation shall be extended to work across cores. This document will not specify any implementation details. This functions timing behavior can be slower when working across cores. If a Task has to be activated on another core, a scheduling decision is necessary on that core. If the core has not been started an error is generated.

Requirements

[SWS_Os_00596]

[SRS_Os_80001]

[SRS_Os_80015]

It shall be possible to activate a Task that is part of an OSApplication located on another core, as long as the assigned access rights allow it.

[SWS_Os_00598]

[SRS_Os_80015]

The call of ActivateTask across cores shall behave synchronously, i.e. a call returns after the Task has been activated or an error has been detected. It shall not be possible to continue execution on the calling core before ActivateTask is accomplished on the remote core.

[SWS_Os_00599]

[SRS_Os_80015]

In case of an error when calling ActivateTask across cores, the error handler shall be called on the core on which ActivateTask was originally called.

[SWS_Os_00816]

[SRS_Os_80015]

The operating system shall provide an asynchronous version of ActivateTask which does not return errors to the caller, but only calls the (global) error hook (if configured). The function name shall be ActivateTaskAsyn.

Task Chaining

Task chaining shall be extended to work across cores. This document will not specify any implementation details. This function's timing behavior can be slower when working across cores. If a Task has to be activated on another core, a scheduling decision is necessary on that core. If the core has not been activated, an error is generated.

Requirements

[SWS_Os_00600]

[SRS_Os_80001]

[SRS_Os_80015]

It shall be possible to chain a Task that is part of an OS-Application located on another core, as long as the assigned access rights allow it.

Event setting

SetEvent shall be extended to work across cores. This document will not specify any implementation details. This function's timing behavior can be slower when working across cores. If the core has not been activated, an error is generated.

Requirements

[SWS_Os_00602]

[SRS_Os_80016]

It shall be possible to set an Event that is part of an OSApplication located on another core, as long as the assigned access rights allow it.

[SWS_Os_00604]

[SRS_Os_80016]

The call of SetEvent across cores shall behave synchronously, i.e. a call returns after the Event has been set or an error has been detected. It shall not be possible to continue execution on the calling core before SetEvent is accomplished on the remote core.

[SWS_Os_00605]

[SRS_Os_80016]

In case of an error when calling SetEvent across cores, the error handler shall be called on the core on which SetEvent was originally called.

[SWS_Os_00817]

[SRS_Os_80016]

The operating system shall provide an asynchronous version of SetEvent which does not return errors to the caller, but only calls the (global) error hook (if configured). The function name shall be SetEventAsyn.

Activating additional cores

The mechanism by which additional cores can be activated as described in section 7.9.5

Start of the OS

It is necessary to extend the functionality of StartOS. This is because StartOS is called once on each core. The user provides the so called application mode (This is the application mode of the Operating System and shall not be confused by other application modes defined in the AUTOSAR mode management) to the Operating System through the call parameter of StartOS(AppMode).The application mode defines which of the configured (startup) objects (Tasks, Alarms, ScheduleTables) the OS automatically starts.

On a Multi-Core system all cores shall run in the same application mode. If StartOS is called with the Appmode DONOTCARE, the AppMode of the other cores is used. At least one core has to define an AppMode other than DONOTCARE.

If the application mode is the same on all cores, StartOS will proceed its task. More details can be found in chapter 7.9.4.

Requirements

[SWS_Os_00606]

[SRS_Os_80001]

The AUTOSAR specification does not support the activation of AUTOSAR cores after calling StartOS on that core. If StartCore is called after StartOS it shall return with E_OS_ACCESS in extended status.

[SWS_Os_00607]

[SRS_Os_80006]

[SRS_Os_80013]

StartOS shall start the OS on the core on which it is called.

[SWS_Os_00608]

[SRS_Os_80006]

If more than one core calls StartOS with an AppMode other than DONOTCARE, the AppModes shall be the same. StartOS shall check this at the first synchronization point. In case of violation, StartOS shall not start the scheduling, shall not call any StartupHooks, and shall enter an endless loop on every core.

[SWS_Os_00609]

[SRS_Os_80006]

If StartOS is called with the AppMode DONOTCARE the application mode of the other core(s) (differing from DONOTCARE) shall be used.

[SWS_Os_00610]

[SRS_Os_80006]

At least one core shall define an AppMode other than DONOTCARE.

[SWS_Os_00611]

[SRS_Os_80020]

If the IOC is configured, StartOS shall initialize the data structures of the IOC.

[SWS_Os_00830] DRAFT

[SRS_Os_80020]

If the IOC is configured and the OS Generator is invoked in "Default mode", StartOS shall invoke the IocInit (See [SWS_Os_00835]) to initialize the data structures of the IOC.

Task termination

The termination of Tasks requires an additional check: It is not allowed to terminate a Task while a spinlock is occupied. If TerminateTask / ChainTask is called with an occupied spinlock an error is returned.

Requirements

If TerminateTask (or ChainTask) is called while the calling Task holds a spinlock, the behavior is undefined in standard status.

[SWS_Os_00612]

[SRS_Os_80021]

In extended status TerminateTask / ChainTask shall return with an error (E_OS_SPINLOCK), which can be evaluated in the application.

[SWS_Os_00613]

[SRS_Os_80021]

Spinlocks occupied by Tasks that are terminated in response to a protection hook shall be automatically released. This applies also to the case in which an OS-Application is terminated.

Termination of OS-Applications

Similar to Tasks an OS-Application cannot be terminated while any of its Tasks occupy a spinlock. In such cases, the lock is automatically released. To avoid an avalanche of error handling, no calls to the ErrorHook are made.

It might be possible that TerminateApplication(A) is called in parallel from different cores. The implementation has to support such a call pattern by executing the first arriving call of TerminateApplication(A)and ignoring any subsequent calls until the termination is completed.

Requirements

[SWS_Os_00614]

[SRS_Os_80021]

TerminateApplication shall check if any of the Tasks in the OS-Application have occupied a spinlock. If so, the spinlocks shall be released.

[SWS_Os_00615]

[SRS_Os_80021]

If TerminateApplication(A) is called in parallel from different cores, the OsApplication A is terminated by the first call, any subsequent calls will return with E_OK in standard and extended status without doing anything, until the termination is completed.

Shutdown of the OS

Every core shall be able to invoke shutdown by using the ShutdownOS function. By calling ShutdownOS only the calling core will enter the shutdown procedure.

If the user wants to shutdown all cores (more or less in parallel) ShutdownAllCores shall be used. ShutdownOS and ShutdownAllCores will not return.

The OS service ShutdownOS is not used by the AUTOSAR mode management in AUTOSAR R4.0. The function is offered for users that run the OS on cores without RTE and without mode management.

Requirements

[SWS_Os_00616]

[SRS_Os_80001]

[SRS_Os_80007]

ShutdownOS shall be callable from each core running an AUTOSAR OS.

[SWS_Os_00617]

[SRS_Os_80007]

ShutdownOS shall shutdown the core on which it was called.

[SWS_Os_00618]

[SRS_Os_80013]

The OS shall not start Tasks of an OS-Application once the shutdown procedure has been entered on a particular core.

[SWS_Os_00619]

[SRS_Os_80013]

The AUTOSAR OS function ShutdownOS shall be callable in parallel on multiple cores.

[SWS_Os_00620]

[SRS_Os_80021]

ShutdownOS shall release all spinlocks which are occupied by the calling core.

[SWS_Os_00621]

[SRS_Os_80007]

ShutdownAllCores shall be callable from each core running an AUTOSAR OS.

Waiting for Events

The Event waiting mechanism must be adapted to the new Multi-Core spinlock functionality:

A Task might be de-scheduled when calling WaitEvent, in which case it would not be able to release the spinlock. WaitEvent must therefore check if the calling Task holds a spinlock. As with Resources, spinlocks cannot be occupied by Tasks in wait state.

Requirements

[SWS_Os_00622]

[SRS_Os_80021]

The AUTOSAR Operating System WaitEvent API service shall check if it has been called while the calling Task has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the Task shall not enter the wait state.

Calling trusted functions

Functions can be declared as trusted as part of an OS-Application. They can then only be executed through the CallTrustedFunction API function. Assuming that the access rights are configured accordingly, a Task from OS-Application A can call a trusted function from OS-Application B.

On a Multi-Core system, these trusted function calls from one OS-Application to another are limited to the same core.

Requirements

[SWS_Os_00623]

[SRS_Os_80013]

The OS API function CallTrustedFunction shall return E_OS_ACCESS in extended status if the target trusted function is part of an OSApplication on another core.

Invoking reschedule

The Schedule API service must be adapted to the new Multi-Core spinlock functionality in the same manner as WaitEvent.

A Task shall not actively force a de-scheduling while it occupies spinlocks.

Requirements

[SWS_Os_00624]

[SRS_Os_80021]

The AUTOSAR Operating System Schedule API service shall check if it has been called while the calling Task has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not be called.

Resource handling

The GetResource function allows mutual exclusion between Tasks on the same core. The OS generator shall check offline that the Tasks are not on different cores.(see 7.9.29) and the GetResource function will check this requirement online.

The priority ceiling protocol (used by GetResource) temporarily changes the priority of a Task. Such an approach fails on Multi-Core systems as the priorities are local to each core. Therefore the ceiling protocol is not sufficient to protect a critical section against access from different cores.

[SWS_Os_00801]

[SRS_Os_80021]

If Spinlocks and Resources are locked by a Task/ISR they have to be unlocked in strict LIFO order. ReleaseResource shall return E_OS_NOFUNC if the unlock order is violated. No other functionality shall be performed.

[SWS_Os_00851]

[ ]

If OsUseResScheduler is TRUE, the OS generation tool shall create a virtual instance of RES_SCHEDULER for each configured core.

[SWS_Os_00852]

[ ]

It shall be possible for tasks running on different cores to occupy their own instance of RES_SCHEDULER at the same time.

[SWS_Os_00853]

[ ]

The ceiling priority of each instance of RES_SCHEDULER shall prevent the execution of any other task on the core on which it is occupied but shall have no effect on the scheduling on any other core.

[SWS_Os_00854]

[ ]

If OsUseResScheduler is FALSE AND the configuration contains a resource called RES_SCHEDULER, the configured resource shall behave the same as any other configured resource.

[SWS_Os_00855]

[ ]

It shall be possible to configure a LINKED resource that links to RES_SCHEDULER. In a multi-core configuration with OsUseResScheduler=TRUE, the linkage shall be to the instance of RES_SCHEDULER on the core to which the LINKED resource is assigned.

The CoreID

Every HW assigns a unique physical Id to a core. The physical core Id is the only way to distinguish between cores. The physical core Ids of a |¡§?C are not necessarily consecutive and do not necessarily start with zero.

The SW requires a mechanism to identify a core, e.g. to use core specific variables. Because the physical core Id usually cannot be used as a direct array index for core specific variables, a logical CoreID is necessary to map physical core Ids to array indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID is sufficient.

The mapping of OS-Applications and other SW objects to cores is specified in the configuration files. All such mappings shall be HW independent and therefore shall not be based on the physical core Id but on the logical CoreID.

The function GetCoreID internally maps the physical core Id to the logical CoreID. The mapping is implementation specific. GetCoreID can be either a C function or a macro.

Requirements

[SWS_Os_00625]

[SRS_Os_80006]

The AUTOSAR Operating System API function GetCoreID shall be callable before StartOS.

[SWS_Os_00627]

[SRS_Os_80001]

An implementation shall define a set of constants OS_CORE_ID_ <No> of the type CoreIdType with <No> a value from 0 to OsNumberOfCores - 1.

[SWS_Os_00628]

[SRS_Os_80001]

An implementation shall offer a constant OS_CORE_ID_MASTER of the type CoreIdType that refers to the master core.

Counters, background & rationale

A Counter is represented by a counter value, measured in "ticks", and some counter specific constants.

Similarly to Single-Core situation, each operating system (on each core) offers at least one Counter that is derived from a timer. Therefore, it is possible to define several Counters which belong to different OS-Applications and either resides on the same or different cores.

Multi-Core restrictions on Counters

The AUTOSAR OS can only increment Counters on the core on which it resides. A Counter which is assigned to an OS-Application X cannot be incremented by an OS-Application Y if X and Y are assigned to different cores.

Requirements

[SWS_Os_00629]

[SRS_Os_80013]

A Counter belonging to an OS-Application shall be incremented by the core on which the OS-Application resides. The Counter shall not be incremented by other cores.

[SWS_Os_00630]

[SRS_Os_80013]

It shall not be allowed to drive a ScheduleTable from a Counter, which is assigned to a different core.

[SWS_Os_00631]

[SRS_Os_80013]

It shall not be allowed to drive an Alarm from a Counter, which is assigned to a different core.

There are two different reasons for these restrictions:

Race conditions can occur when cross-core modification of Counter is allowed (one core waits for a Counter to be modified by another core).

The core which is incrementing the Counter has to check if Alarms which are based on the Counter have expired. Handling of expired Alarms is more complex when different cores manipulate the same Alarms, because mutual exclusion becomes necessary.

Synchronization of Counters

Counters are used to drive Alarms and ScheduleTables. To synchronize Alarms and ScheduleTables that reside on different cores, the corresponding Counters have to be synchronized. For example, if the hardware supports this, it is possible that corresponding free running hardware counters on different cores use the same timer (same counter value maintained by the peripheral) and therefor provide the same timebase on different cores. Software Counters can then get advanced by alarms attached to these core local corresponding hardware counters, e.g. to drive synchronized ScheduleTables on different cores. The quality of the synchronicity depends on the hardware architecture and on the system configuration. .

Alarms

The Alarm mechanism of the AUTOSAR Operating System provides services to activate Tasks, set Events, increment Counters, or call an Alarm call-back (OsAlarmCallbackName).

As stated above, Alarms can only be bound to a Counter which resides on the same core. Tasks can be activated and Events can be set with an Alarm action regardless of the core to which the Task is bound. The access rights defined by OS-Applications have to be respected, however. Additionally it shall be allowed to manipulate Alarms when they are bound to other cores. The API-services SetRelAlarm, SetAbsAlarm, and CancelAlarm can be used to manipulate parameters of Alarms on other cores.

Requirements

[SWS_Os_00632]

[SRS_Os_80018]

If an Alarm expires, it shall be allowed to activate a Task on a different core.

[SWS_Os_00633]

[SRS_Os_80018]

If an Alarm expires, it shall be allowed to set an Event on a different core.

[SWS_Os_00634]

[SRS_Os_80018]

The AUTOSAR Operating System shall process an Alarm on the core on which its corresponding OS-Application resides.

[SWS_Os_00635]

[SRS_Os_80013]

Alarm callbacks shall be executed on the core to which the Alarm is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback are not allowed ([SWS_Os_00242]).

[SWS_Os_00636]

[SRS_Os_80013]

SetRelAlarm shall also work on an Alarm that is bound to another core.

[SWS_Os_00637]

[SRS_Os_80013]

SetAbsAlarm shall also work on an Alarm that is bound to another core.

[SWS_Os_00638]

[SRS_Os_80013]

CancelAlarm shall also work on an Alarm that is bound to another core.

[SWS_Os_00639]

[SRS_Os_80013]

GetAlarmBase shall also work on an Alarm that is bound to another core.

[SWS_Os_00640]

[SRS_Os_80013]

GetAlarm shall also work on an Alarm that is bound to another core.

ScheduleTables

Similarly to Alarms, ScheduleTables can be used to activate Tasks and set Events. As with Alarms, a ScheduleTable can only be bound to a Counter which resides on the same core.

To simplify system startup, it should be possible to start ScheduleTables on other cores. The system designer is responsible for the correct handling of ScheduleTables. For example, ScheduleTables can be controlled from one core.

Requirements

[SWS_Os_00641]

[SRS_Os_80018]

A ScheduleTable shall be able to activate a Task bound on a core other than the one upon which the ScheduleTables resides.

[SWS_Os_00642]

[SRS_Os_80018]

A ScheduleTable shall be able to set an Event on a core other than the one upon which the ScheduleTables resides

[SWS_Os_00643]

[SRS_Os_80013]

The AUTOSAR Operating System shall process a ScheduleTable on the core on which its corresponding OS-Application resides.

[SWS_Os_00644]

[SRS_Os_80018]

The API call StartScheduleTableAbs shall be able to start ScheduleTables of OS-Applications residing on other cores.

[SWS_Os_00645]

[SRS_Os_80013]

The API call StartScheduleTableRel shall be able to start ScheduleTables of OS-Applications residing on other cores.

[SWS_Os_00646]

[SRS_Os_80013]

The API call StopScheduleTable shall be able to stop ScheduleTables of OS-Applications residing on other cores.

[SWS_Os_00647]

[SRS_Os_80013]

The API service GetScheduleTableStatus shall be able to get the status of a ScheduleTable that is part of an OS-Application residing on a different core.

The spinlock mechanism

With the Multi-Core concept, a new mechanism is needed to support mutual exclusion for Tasks on different cores. This new mechanism shall not be used between Tasks on the same core because it makes no sense. In such cases the AUTOSAR Operating System returns an error.

A SpinlockType, which is similar to OSEK’s ResourceType, shall be used. Spinlocks are configured offline.

A spinlock is a busy waiting mechanism that polls a (lock) variable until it becomes available. Typically, this requires an atomic test and set functionality, the details of which are implementation specific.

Once a lock variable is occupied by a Task/Category 2 ISR, other Tasks/Category 2 ISRs on other cores shall be unable to occupy the lock variable. The spinlock mechanism will not de-schedule these other Tasks while they poll the lock variable. However it might happen that a Task/ISR with a higher priority becomes ready while the lock variable is being polled. In such cases the spinning Task will be interfered. This is illustrated in figure 7.20.

A user can protect a Task against such a situation by, for example, rapping the spinlock with SuspendAllInterrupts, so that it cannot be interfered by other Tasks. The OS can do this automatically for the caller - see OsSpinlockLockMethod.

A second deadlock situation can be created by nested spinlocks calls, as illustrated in figure 7.21.

To avoid deadlocks it is not allowed to nest different spinlocks. Optionally if spinlocks shall be nested, a unique order has to be defined. Spinlocks can only be taken in this order whereas it is allowed to skip individual spinlocks. Cycles are not allowed within the defined order. This is illustrated in figure 7.22.

This figure 7.22 shows an example in which two Tasks have access to a set of spinlocks S1 - S6. It is allowed to occupy the spinlocks in the predefined order and it is allowed to skip spinlocks. If multiple spinlocks are occupied at the same time, locking and unlocking has to occur in strict LIFO order

The spinlock mechanism is not deadlock free by itself. The order in which spinlocks from Tasks/ISRs are requested has to be mentioned in the configuration description. If a Task occupies a spinlock, scheduling shall be restricted.

Note: AUTOSAR does not prescribe which algorithms are used to implement spinlocks. Since users may want to analyze the timing behavior (e.g. lock times) an implementation shall document the real behavior.

Requirements

[SWS_Os_00648]

[SRS_Os_80018]

[SRS_Os_80021]

The AUTOSAR Operating System shall provide a spinlock mechanism that works across cores.

[SWS_Os_00649]

[SRS_Os_80018]

[SRS_Os_80021]

The AUTOSAR Operating System shall provide a GetSpinlock function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock shall keep on trying to occupy the spinlock until it succeeds.

[SWS_Os_00650]

[SRS_Os_80018]

[SRS_Os_80021]

GetSpinlock shall be callable from Task level.

[SWS_Os_00651]

[SRS_Os_80021]

GetSpinlock shall be callable from Category 2 ISR level.

The behavior of GetSpinlock is undefined if called from a category 1 ISR.

[SWS_Os_00652]

[SRS_Os_80018]

[SRS_Os_80021]

The AUTOSAR Operating System shall provide a TryToGetSpinlock function which occupies a spinlock. If the spinlock is already occupied by a Task, TryToGetSpinlock shall return.

[SWS_Os_00653]

[SRS_Os_80018]

[SRS_Os_80021]

TryToGetSpinlock shall be callable from Task level.

[SWS_Os_00654]

[SRS_Os_80018]

[SRS_Os_80021]

TryToGetSpinlock shall be callable from Category 2 ISR level.

[SWS_Os_00655]

[SRS_Os_80018]

[SRS_Os_80021]

The AUTOSAR Operating System shall provide a ReleaseSpinlock function which releases an occupied spinlock. If the spinlock is not occupied an error shall be returned.

[SWS_Os_00656]

[SRS_Os_80018]

[SRS_Os_80021]

ReleaseSpinlock shall be callable from Task level.

[SWS_Os_00657]

[SRS_Os_80018]

[SRS_Os_80021]

ReleaseSpinlock shall be callable from Category 2 ISR level.

[SWS_Os_00658]

[SRS_Os_80018]

[SRS_Os_80021]

The AUTOSAR Operating System shall generate an error if a Task tries to occupy a spinlock that is assigned to a Task/Category 2 ISR on the same core (including itself).

[SWS_Os_00659]

[SRS_Os_80018]

[SRS_Os_80021]

The AUTOSAR Operating System shall generate an error if an Category 2 ISR tries to occupy a spinlock that is assigned to a Task/Category 2 ISR on the same core.

[SWS_Os_00660]

[SRS_Os_80018]

[SRS_Os_80021]

A unique order in which multiple spinlocks can be occupied by a Task/Category 2 ISR on one core should be configurable in the AUTOSAR Operating System. This might be realized by the configuration item (OsSpinlockSuccessor{NEXT_SPINLOCK}) where NEXT_SPINLOCK refers to the consecutive spinlock. (See OsSpinlockSuccessor)

[SWS_Os_00661]

[SRS_Os_80018]

[SRS_Os_80021]

The AUTOSAR Operating System shall generate an error if a Task/Category 2 ISR on a core, where the same or a different Task/ISR already holds a spinlock, tries to seize another spinlock that has not been configured as a direct or indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuccessor configuration parameter) or if no successor is configured.

Offline checks

AUTOSAR Resources cannot be shared between Tasks/ISRs on different cores. The OS generator has to check if a user tries to assign a Resource to Tasks on different cores and stop the generation process with an error.

Counters cannot be accessed from OS-Applications on different cores. The OS generator has to reject configurations that violate this rule.

The linked list of spinlocks must be free of cycles to allow correct nesting of spinlocks in order to prevent deadlocks.

The OS generator tool must check that an OS-Application does not get assigned to a non-existing core. Additional checks at configuration time, e.g. by an AUTOSAR description editor are recommended.

Requirements

[SWS_Os_00662]

[SRS_Os_80021]

The OS generator tool shall return with an error if it detects a Resource referred to by any Tasks or ISRs assigned to different cores.

[SWS_Os_00663]

[SRS_Os_80013]

The OS generator tool shall return with an error if an Alarm is assigned to a Counter on a different core.

[SWS_Os_00664]

[SRS_Os_80013]

The OS generator tool shall return with an error if a Counter on a different core shall be incremented as an Alarm action.

[SWS_Os_00665]

[SRS_Os_80013]

The OS generator tool shall return with an error if a ScheduleTable is assigned to a Counter on a different core.

[SWS_Os_00666]

[SRS_Os_80021]

The OS generator tool shall return with an error if the linked list of spinlocks is not free of cycles.

[SWS_Os_00667]

[SRS_Os_80005]

The OS generator tool shall check the assignment of OsApplications (including the Tasks assigned to the OsApplication) to cores and return an error in case any of these cores does not exist.

Auto start Objects

Before scheduling starts the AUTOSAR Operating System5 activates all auto-start objects that are configured. This mechanism shall work similar on a Multi-Core system. Before scheduling starts, the Multi-Core OS shall activate all configured auto-start objects on the respective core. Due to the fact that OS-Applications are defined as the locatable entity no further configuration container is required. Auto-start objects are already configured as part of an OS-Application.

Requirements

[SWS_Os_00668]

[SRS_Os_80006]

The AUTOSAR Operating System shall automatically activate all auto-start Tasks configured for the current AppMode, with respect to the core, before the initial start of the scheduling.

[SWS_Os_00669]

[SRS_Os_80006]

The AUTOSAR Operating System shall automatically activate all auto-start Alarms configured for the current AppMode, with respect to the core, before the initial start of the scheduling.

[SWS_Os_00670]

[SRS_Os_80006]

The AUTOSAR Operating System shall automatically activate all auto-start ScheduleTables configured for the current AppMode, with respect to the core, before the initial start of the scheduling.

Inter-OS-Application Communicator (IOC)

Background & Rationale

IOC stands for Inter OS-Application Communicator.

The "IOC" is responsible for the communication between OS-Applications and in particular for the communication crossing core or memory protection boundaries. Its internal functionality is closely connected to the Operating System.

There are use cases where 1 to N IOC code instances needs to be generated on top of the OS code which is used by multiple different Software Clusters. As those Software Clusters use different IOC configurations, as a consequence the OS code shall not include any code depending on a specific IOC configuration.

To ensure compatibility between IOC and OS code, there is still a dependency in that it is necessary to use the same OS configuration for the generation of the different IOC code Instances. Furthermore, the OS and IOC code should be generated from an OS Generator coming from the same vendor.

[SWS_Os_00671]

[SRS_Os_80020]

The IOC implementation shall be part of the Operating System The IOC is a third type of communication, in addition to

Intra OS-Application communication: Always handled within the RTE

Inter ECU communication: Already available via well-defined interfaces to the communication stack (COM)

IOC mode: This is the mode where the OS generator is invoked with a configuration parameter to generate the IOC code only.

OS mode: This is the mode where the OS generator is invoked with a configuration parameter to generate the OS code only.

Default mode: This is the current behavior where the IOC code is generated along with OS code.

[SWS_Os_00831] DRAFT

[SRS_Os_80020]

The OS Generator shall provide configuration parameters allowing IOC communication code ("IOC mode") to be generated separately from OS code (("OS mode").

[SWS_Os_00831] means that the OS Generator shall be able to produce only OS code or only IOC code in a single invocation.

[SWS_Os_00832] DRAFT

[SRS_Os_80020]

The Operating System in the Host Software Cluster shall be able to handle multiple IOC code Instances related to different Software Clusters.

[SWS_Os_00833] DRAFT

[SRS_Os_80020]

When the OS generator is invoked in "OS mode" it shall only generate the OS code. Thereby the OS code shall not include any code that depends on a specific IOC configuration, because different Clusters will use different IOC configurations with the same OS code.

Please note that it is mandatory to use the same OS configuration for the generation of the different IOC instances to ensure compatibility between the IOC and OS code.

[SWS_Os_00834] DRAFT

[SRS_Os_80020]

When the OS generator is invoked in "IOC mode" it shall only generate the IOC code. Thereby the name of the C module containing the generated IOC code shall be Ioc.c and the name of the header file containing the generated IOC APIs shall be Ioc.h.

Requirements [SWS_Os_00833] and [SWS_Os_00834] ensure that OS and IOC can be generated independently from each other but linked together while building the ECU instance /Machine.

[SWS_Os_00835] DRAFT

[SRS_Os_80020]

If the IOC is configured, there shall be a function IocInit responsible for the initialization of the data structures of the IOC.

Memory protection boundaries are a characteristic of OS-Applications and special communication mechanisms are needed to cross them. Multi-Core systems may also need additional measures to make communication between cores safe.

All AUTOSAR software, both BSW and software components, must belong to an OSApplication (see 7.9.3), but not necessarily to the same one. It is expected that the BSW will be trusted code, but it shall be defined as one or more OS-Applications.

The IOC provides communication services between OS-Applications and in particular over core boundaries in Multi-Core systems. Because the cross-core communication is always an inter-OS-Application communication, the two mechanisms are combined. An inter OS-Application communication may not necessarily require a cross core communication, however.

Communication between OS-Applications is expected to be more frequent than inter ECU communication. This would be the case when existing; closely related Software Components and their runnable entities are distributed to two or more cores to increase system performance. Meeting timing constraints is expected to become more difficult, when runnables which have been designed to run on a single core are distributed over several cores.

In systems with only one core, the IOC can be omitted completely, if just one OSApplication is available, or if no OS-Application uses memory protection mechanisms.

The IOC does not provide standardized support for measurement of IOC channels.

IOC - General purpose

The IOC provides communication services which can be accessed by clients which need to communicate across OS-Application boundaries on the same ECU or Software Cluster.

The RTE uses IOC services to communicate across such boundaries. All communication must be routed through the RTE on sender (or client) and on receiver (or server) side.

Direct access to IOC services by clients other than the RTE is currently not supported, but possible, if the client (e.g. a CDD) provides a hand written or generated IOC Configuration Description as specified and specific callback functions if necessary. Only sender/receiver communication is supported however by the IOC.

To keep the RTE as hardware independent as possible, all inter OS-Application and inter core communication mechanisms and implementation variants are encapsulated in the IOC. The IOC internal functionality is dependent on hardware architecture properties, in particular on the memory architecture.

The IOC has to guarantee data consistency in inter OS-Application and inter core (Multi-Core systems) communication, this means in particular:

In queued communication the sequential order of communication operations shall remain unchanged. In the N:1 communication case, the order of the messages from the different sources is a property of the implementation.

The content of all data sent in one communication operation shall remain unchanged, i.e. each communication operation shall be treated as atomic operation.

The lock mechanism (interrupt locks; spinlocks; lock free implementation; ...) which is used by the IOC to guarantee the data consistency is not standardized.

IOC functionality

Communication

The IOC provides sender-receiver (signal passing) communication only. The RTE (or adapted BSW modules in a future release of this specification) translates Client-Server invocations and response transmissions into Sender-Receiver communication.

1:1, N:1 and N:M (unqueued only) communication are supported by the IOC.

The IOC allows the transfer of one data item per atomic communication operation. A data item can either be a value for atomic basic data types or a reference for complex data structures. The data structure must be implemented as a single memory block, however. This way the data item can be transmitted in one piece. The IOC does not need to know the internal data structure. The basic memory address and length (which can be calculated from the type of the data item) is sufficient. The IOC does, e.g., not support a conversion of endianness between cores.

Transferring more than one data item in one operation is also supported for 1:1 communication only. In this case several types and memory addresses have to be used by the IOC function. The advantage compared to sequential IOC calls is that mechanisms to open memory protection boundaries and to notify the receiver have to be executed just once. Additionally, all data items are guaranteed to be consistent, because they are transferred in one atomic operation.

The IOC provides both, unqueued (Last-is-Best, data semantics) or queued (First-InFirst-Out, event semantics) communication operations. If present, the IOC internal queue has a configurable length.

Each atomic communication operation gets specified individually by its own description block in a Configuration Description with regard to sender, receiver, data type(s), notification, and queuing.

Notification

The IOC optionally notifies the receiver as soon as the transferred data is available for access on the receiver side, by calling a configured callback function which gets provided by the user of the communication.

A possible implementation is to trigger an interrupt (Category 2 ISR) mechanism to invoke the callback function from the ISR on receiver side, or to use a microcontroller supplied trap. The callback function shall be efficient and compact, because it is called from within the ISR.

In certain cases, it might not be necessary to trigger an ISR to notify the receiver. The IOC generator can then select the appropriate IOC internal notification method based on the hardware architecture and other constraints. This might be more efficient than an ISR for communication between OS-Applications on the same core.

The notification might be handled completely by the client of the IOC, e.g. when the RTE calls the IOC send function, and then notifies the receiver side RTE that new data are available from the IOC. In this case, the IOC is not affected at all by the details of the notification mechanism.

In case such alternative solutions prove to be more efficient, the IOC internal notification might get removed in future AUTOSAR releases.

IOC interface

The interface between RTE and IOC shall be similar to the interface between Software Components and the RTE, i.e. by generating specific interfaces for each communication operation instead of providing a generic API.

This supports optimization methods (like function inlining or replacing function calls by macros) much better than standardized interfaces. Most of the optimization can be performed offline at code generation time instead of consuming valuable real-time resources.

There is a unique set of IOC service APIs (at least to send and receive data) for each data communication specified in the IOC Configuration Description. Each service API gets generated and can be identified by a unique Id for each data communication. In case of N:1 communication, each sender must use its own API.

The same IOC service API and hence the same 1:1 communication can get used by more than one runnable inside the same SWC both on sender and on receiver side. However, the IOC functions are not reentrant, because otherwise e.g. spinlock errors could occur in case the IOC uses spinlocks in Multi-Core systems. The same IOC API must therefore only be called sequentially. This is no problem, if all runnable entities are scheduled within the same Task, otherwise the caller is responsible to guarantee that the same IOC API is not called again before it returns from a different invocation.

Software Components may access the IOC only via RTE. Only the RTE decides which communication services to use to support the communication needs of Software Components.

Direct access to IOC services by BSW modules is not supported, but allowed for CDDs and other modules, if unavoidable. The clients have to provides a hand written or generated IOC Configuration Description as specified. In case of notification of the receiver, a specific callback function has to be specified and provided by the client. Only sender/receiver communication is supported however by the IOC.

IOC internal structure

This section gives some hints on possible IOC implementation options.

The IOC may enter the privileged mode to cross the protection boundaries between OS-Applications. The IOC therefore has to be part of the OS. Note that functionality that is placed in the kernel context might be non-interruptible by Tasks or Category 2 ISR. The functionality can be interrupted by Cat1 ISRs, however.

The IOC send service writes data into a buffer located in a memory area which is shared with the receiving communication partners (This is one possible implementation example using shared memory). Depending on the hardware architecture and other constraints, different implementation options might be available within the IOC. These options shall be transparent to the client (RTE), however.

The IOC ensures data consistency, i.e. there is a protection against concurrent access to the same data from all senders and the receiver for protection against inconsistent behavior and data corruption. The implementation can be hardware dependent.

In systems with shared memory, there can be a specific communication buffer for each data item in a memory section which is shared between the sending and receiving OS-Applications.

If an IOC communication with event semantics (queued) is configured the length of the queue shall be defined.

IOC configuration and generation

Data element specific interfaces between RTE and IOC require extensive code generation. Instead of generating the IOC together with the RTE, a sequential code generation process is used, to separate generic RTE code generation and hardware dependent IOC code generation as much as possible. The following steps shall be performed:

Step 1: Specify all information about the allocation of Software Components to OS-Applications and cores in the ECU Configuration Description file.

Step 2: Generate the RTE. The RTE generator creates data element specific IOC services calls and the corresponding IOC Configuration Description blocks (XML format) to specify the communication relations for each data element.

Step 3: Generate the IOC code, according to the IOC Configuration Description (Step 2) while considering the hardware description files. Additionally, generate a header file (Ioc.h) for inclusion in RTE.c to provide definitions, function prototypes and macros.

Each atomic communication has to be specified in the IOC Configuration Description in a standardized XML format. There is one description block per communication operation specifying:

Unique identifier

Data type(s)

Sender properties

Receiver properties

Name of callback function on receiver side in case of notification.

Whether communication is queued or unqueued (last is best)

In case of queued communication: Length of the queue

For details see chapter 10.3

For each inter-OS-Application communication, the RTE generator creates one or more calls to an IOC function to send or receive data, and adds a corresponding description block to the IOC Configuration Description.

There are possibly multiple sources which contribute to the IOC configuration (e.g., RTE, CDD). The main input will come from the RTE generator. Other sources for the IOC Configuration Description (not supported in this specification revision) might be BSW module configuration tools or non-AUTOSAR components, which are allowed to use BSW services.

In ECUs or Software Clusters with only one OS-Application, the IOC Configuration Description can be omitted.

[SWS_Os_00824]

[ ]

All the data allocated by the OS for the IOC communication shall be wrapped with the memory allocation keywords mechanism

#define OS_<IE>_START_SEC_<sadm>
#include "Os_MemMap.h"

<IOC buffers>

#define OS_<IE>_STOP_SEC_<sadm>
#include "Os_MemMap.h"

where <IE> is the shortName of the sending OsApplication configured in OsIocSendingOsApplicationRef of the respective OsIocCommunication channel, and <sadm> is the shortName of the referred swAddrMethod, if configured in OsMemoryMappingCodeLocationRef of the respective OsIocDataProperties within the OsIocCommunication channel. If the OsMemoryMappingCodeLocationRef is not defined the OS is permitted to select an appropriate swAddrMethod.

IOC integration examples

This section describes two typical use cases that show how the IOC can support communication between OS-Applications. In both examples the OS-Applications are located on different cores of a Multi-Core system.

Example 1 - 1:1 sender/receiver communication without notification

One Software Component sends data items in event semantics (queued) to another Software Component located on a different core. A runnable entity on the receiver side is invoked periodically (e.g. by an Alarm) and receives the data via RTE (see figure 7.24).

Because the communication crosses core boundaries, the RTE invokes the IOC to transfer the data from core 0 to core 1.

On the sending side, the

Rte_Send_<port>_<item> (..., <data>)

call is mapped to an

IocSend_<Id> (<data>)

call.

In this example, the IocSend service writes the data into a buffer, located in a shared memory area which can get read by the receiver via the IOC.

On the receiving side, the receiving runnable gets invoked periodically. The

Rte_Receive_<port>_<item> (..., <data>)

call is mapped to an

IocReceive_<Id> (<data>)

call to read data from the IOC internal queue. An additional queue within the RTE is not necessary for 1:1 communication.

The IOC generator generates all the send and receive functions. The functions might be defined as macros for optimization purposes.

This kind of port to port communication without notification is suitable for:

Sender/receiver communication

Queued or unqueued communication

1:1 communication.

Example 2 - N:1 client/server communication with receiver notification by RTE

One Software Component invokes a service operation that is provided by another Software Component located on a different core. A runnable entity on the receiver side is activated to calculate the result (see figure 7.25).

The RTE realizes the service on client side by mapping the client/server call to a sender/receiver communication. Because the communication crosses core boundaries, the RTE uses the IOC to transfer the data from Core 0 to Core 1.

On the sending side, the

Rte_Call_<port>_<op> (..., <data>)

call is mapped to a

IocSend_<Id> (<data>)

call to transmit the parameters over the IOC to the core hosting the server runnable.

After writing the data into the IOC internal queue buffer, the Rte_Call function uses an OS call to notify the receiver by activating the server Task on the receiving core. This Task is provided by the RTE. This Task body is responsible for reading the data from the IOC buffer by calling IocReceive function and for forwarding the data to the server runnable. Depending on the return value of the IOC function, the IocReceive and server runnable calls might be repeated several times to empty the IOC internal queued buffer (if specified).

The result of the service on Core 1 is transferred back to the client on Core 0 in a similar way. The communication path of the result is not displayed in figure 7.25.

This kind of port to port communication with notification by the RTE is suitable for:

Sender/receiver communication with notification

Client/server communication. In this case the RTE has to provide services to map the server call into 1:1 sender/receiver communication for the server call and another sender/receiver communication to return the result to the client

Queued or unqueued communication

1:1 communication, if the receiver does not poll for data periodically (In this case, the solution in example 1 might have been more suitable)

N:1 communication.

Future extensions

Some features are not supported by the first release of this specification, but might get added in a later release:

In the future, the IOC will handle direct and efficient communication among BSW modules or between BSW modules and Software Components (via the RTE) located in different OS applications. Additional support of direct access from BSW modules to IOC services will be added.

Other notification options (like activation of a specified Task on receiver side) might be added later to the IOC.

System Scalability

Background & Rationale

In order to customize the operating system to the needs of the user and to take full advantage of the processor features the operating system can be scaled according to the following scalability classes

Note:

OS-Applications: see [SWS_Os_00764], see [SWS_Os_00764].

Requirements

[SWS_Os_00240]

[SRS_Os_11012]

[SRS_Os_11016]

If an implementation of a lower scalability class supports features of higher classes then the interfaces for the features must comply with this Operating System software specification.

[SWS_Os_00241]

[SRS_Os_11012]

[SRS_Os_11016]

The Operating System module shall support the features according to the configured scalability class. (See table 7.4)

[SWS_Os_00327]

[ ]

The Operating System module shall always use extended status in Scalability Class 3 and 4.

Hook Functions

Background & Rationale

Hook routines as defined in OSEK OS run at the level of the Operating System module and therefore can only belong to the trusted environment. Furthermore, these hook routines are global to the system (system-specific) and will probably be supplied by the ECU integrator.

In AUTOSAR however, each OS-Application may have the need to execute application specific code e.g. initialize some hardware in its own additional (application-specific) startup hook. These are called application specific hook routines. In general the application specific hooks have the same properties as the hook routines described in the OSEK OS specification. Differences are described below.

Requirements

[SWS_Os_00439]

[ ]

The Operating System module shall provide the OSEK error macros (OSError...()) to all configured error hooks AND there shall be two (like in OIL) global configuration parameters to switch these macros on or off.

StartupHook

[SWS_Os_00060]

[ ]

If an application-specific startup hook is configured for an OSApplication <App>, the Operating System module shall call StartupHook_<App> on startup of the Operating System module.

[SWS_Os_00226]

[ ]

The Operating System module shall execute an applicationspecific startup hook with the access rights of the associated OS-Application.

[SWS_Os_00236]

[ ]

If both a system-specific and one (or more) application specific startup hook(s) are configured, the Operating System module shall call the systemspecific startup hook before the application-specific startup hook(s).

ShutdownHook

[SWS_Os_00112]

[ ]

If an application-specific shutdown hook is configured for an OSApplication <App>, the Operating System module shall call ShutdownHook_<App> on shutdown of the OS.

[SWS_Os_00225]

[ ]

The Operating System module shall execute an applicationspecific shutdown hook with the access rights of the associated OS-Application.

[SWS_Os_00237]

[ ]

If both a system-specific and one (or more) application specific shutdown hook(s) are configured, the Operating System module shall call the systemspecific shutdown hook after the application-specific shutdown hook(s).

ErrorHook

[SWS_Os_00246]

[SRS_Os_11013]

When an error occurs AND an application-specific error hook is configured for the faulty OS-Application <App>, the Operating System module shall call that application-specific error hook ErrorHook_<App> after the system specific error hook is called (if configured).

[SWS_Os_00085]

[ ]

The Operating System module shall execute an applicationspecific error hook with the access rights of the associated OS-Application.

[SWS_Os_00367]

[ ]

Operating System module's services which do not return a StatusType - except ActivateTaskAsyn and SetEventAsyn - shall not raise the error hook(s).

Hardware peripheral access

Background & Rationale

On some MCU architectures, there are memory mapped hardware registers (peripheral area), which are only accessible in specific modes (e.g. in privileged mode). As long as a Tasks/ISRs is running with full hardware access they can directly access these registers. If memory protection is used by the Operating System, Task/ISRs of nontrusted Os-Applications cannot access such registers directly because this would be recognized as a memory violation by the Operating System.

To allow access to such registers even from non-trusted applications the Operating Systems offers the following APIs to read, write and modify registers:

ReadPeripheral8

ReadPeripheral16

ReadPeripheral32

WritePeripheral8

WritePeripheral16

WritePeripheral32

ModifyPeripheral8

ModifyPeripheral16

ModifyPeripheral32

In order to control the access to the registers the access has to be configured for each OsApplication. By this the Os can check during run-time if a caller has sufficient rights.

Requirements

Check access to peripheral registers

[SWS_Os_00806]

[SRS_Os_11005]

The Operating System shall only execute access to peripheral registers via APIs Read PeripheralX, WritePeripheralX and ModifyPeripheralX if :

parameter Address is in range of OsPeripheralAreaStartAddress and OsPeripheralAreaEndAddress

parameter Area is valid

the caller is configured to have sufficient rights (OsPeripheralAreaAccessingApplication).

Error handling of peripheral access API

[SWS_Os_00807]

[SRS_Os_11005]

If the Operating System detects an error (see [[SWS_Os_00806]]) while executing a ReadPeripheralX, WritePeripheralX and ModifyPeripheralX the OS shall return the appropriate StatusType and call the ErrorHook. Otherwise E_OK shall be returned.

Interrupt source API

Background & Rationale

The Operating System needs to guarantee the scheduling, wherefore it needs to be the only component which accesses the interrupt controller. Therefore it provides to other BSW/CDD components the interfaces DisableInterruptSource, EnableInterruptSource and ClearPendingInterrupt to give access to the interrupt control registers of category 2 ISRs.

The pair of DisableInterruptSource/EnableInterruptSource may be used for two different purposes:

A specific interrupt should be masked for a short time (potentially to avoid data consistency problems). A masked request shall be served afterwards, once the interrupt source gets enabled again.

Interrupt requests of a specific source should be ignored for a specific time (potentially a longer time e.g. while the CAN driver sleeps). After enabling the source, only new requests should be considered.

Requirements

[SWS_Os_00808]

[SRS_Os_11011]

The Operating System shall provide for each category 2 interrupt source (OsIsrCategory == CATEGORY_2) the APIs DisableInterruptSource, EnableInterruptSource and ClearPendingInterrupt.

DisableInterruptSource/EnableInterruptSource does not support nested calls.

[SWS_Os_00809]

[SRS_Os_11011]

Nested calls of interrupt source control API The Operating System shall return E_OS_NOFUNC (in EXTENDED status) in case DisableInterruptSource is called for an interrupt source which is already disabled or EnableInterruptSource is called for an interrupt source which is already enabled.

[SWS_Os_00810]

[SRS_Os_11011]

Error handling of interrupt source control API If the Operating System detects an error while executing a DisableInterruptSource, EnableInterruptSource and ClearPendingInterrupt the OS shall return the appropriate StatusType and call the ErrorHook. Otherwise E_OK shall be returned.

[SWS_Os_00811]

[SRS_Os_11011]

A call of EnableInterruptSource shall enable the requested interrupt source by modifying the interrupt controller registers. Additionally it shall clear the interrupt pending flag.

[SWS_Os_00812]

[SRS_Os_11011]

A call of DisableInterruptSource shall disable the requested interrupt source by modifying the interrupt controller registers.

[SWS_Os_00813]

[SRS_Os_11011]

A call of ClearPendingInterrupt shall clear the interrupt pending flag by modifying the respective interrupt controller registers.

[SWS_Os_00814]

[SRS_Os_11011]

Clearing of pending interrupts shall be restricted to clearing the pending flag in the interrupt controller.

Note:

This does not necessarily guarantee that the interrupt request is cleared successfully, i.e. the ISR may still be serviced afterwards. (This may happen due to racing conditions or as the request needs to be cleared in the requesting hardware unit also.)

Error classification

AUTOSAR BSW modules normally report their errors to Det (development errors) or Dem (production errors). The OS handles errors differently (see also [2]) and does not report its errors to Dem/Det. If a reporting of errors to Dem/Det is needed the user can perform these actions in the ErrorHook.

The following table contains all error codes which might be reported from the OS (besides those already defined in [2])

[SWS_Os_91025]

[SRS_BSW_00480]

ARTI Debug Information

[SWS_Os_00858]

[SRS_Os_12001]

The OS shall create an ARTI module description file.

[SWS_Os_00829]

[SRS_Os_12003]

ARTI module description file shall support all ORTI containers.

The ARTI Debug Information intends to enable the attached tool to evaluate and display information about the operating system, its state, its performance, the different Task states, the different operating system objects etc.

Additionally the ARTI Debug Information contains dynamic information as a set of attributes that are represented by formulas to access corresponding dynamic values. Formulas for dynamic data access are comprised of constants, operations, and symbolic names within the target file. To obtain internal values of the required OS objects, the debug tool can then evaluate the given formula.

OS ARTI Objects

It describes a set of attributes for system objects and a method for interpreting the data obtained. The types defined in the section are specified to allow the debugger to determine the target memory access method as well as the best way of displaying the retrieved data. In most cases the information that the user will require to see is a textual description of an attribute rather than the actual value read from the variable.

An example of this is as follows; when a user requests the current state of a Task he will expect to see something like RUNNING, WAITING, READY or SUSPENDED, instead of the actual numeric value that is used by the OS to represent this information internally. For this reason a mapping is specified, which allows a kernel manufacturer to describe how an internal OS value must be mapped to a descriptive value.

ArtiOs

ArtiHwCore

ArtiOsAlarm

ArtiOsContext

ArtiOsIsr

ArtiOsResource

ArtiOsMessageContainer

ArtiOsStack

ArtiOsTask

These objects are declared in Arti containers with definitions named "*Class". The instances of these objects are placed in the same Arti container with definitions named "*Instance".

ARTI Hook Macros

[SWS_Os_00836]

[RS_ARTIFO_00014]

[SRS_Os_12002]

The OS shall incorporate special macros that can be used by an ARTI trace tool to insert tracing functionality of any kind.

[SWS_Os_00837]

[RS_ARTIFO_00014]

[SRS_Os_12002]

The hooks for an AUTOSAR CP OS shall follow the general structure of ARTI macros: ARTI_TRACE(_contextName, _className, _instanceName, instanceParameter, _eventName, eventParameter);

Some of the parameters are using literal text (Token) rather than a symbolic identifier. This allows a macro definition concatenating these parameters to more specific macros. Passing and evaluating all parameters at run-time would be very costly especially by means of run-time consumption. Here is a possible implementation of the generic ARTI_TRACE macro as it could be defined by a ARTI trace tool vendor to match the interface of his trace tool:

#define ARTI_TRACE(_contextName, _className, _instanceName, instanceParameter, \
_eventName, eventParameter) \
ARTI_TRACE ## _ ## _className ## _ ## _eventName ## _ ## _instanceName## _ \
## _contextName ( (instanceParameter), (eventParameter) )

Such an implementation will generate one hook for all the possible combinations of _className, _eventName and _contextName and pass only parameters instance_id and event_value at run-time.

The parameters' meanings are described in the following.

_contextName Token, literal text, name of the context. One of the following:

NOSUSP indicating that the hook gets called in a context where interrupts are disabled

SPRVSR indicating that the called hook may disable interrupts

USER indicating the called hook cannot disable interrupts

_className Token, literal text, name of the class of macros. Predefined classes for an AUTOSAR OS are:

AR_CP_OS_APPLICATION starts and stops the application

AR_CP_OS_TASK schedules Tasks

AR_CP_OS_CAT2ISR dispatches Category 2 interrupts

AR_CP_OS_SERVICECALLS calls service routines

AR_CP_OS_SPINLOCK calls spinlocks

AR_CP_OS_PROTECTIONHOOK calls ProtectionHook

_instanceName Short name of the OS instance as defined in the ARXML.

instanceParameter Index [uint32] 0..4294967295 of the CPU core as seen by the OS (<Core Index>). Should always start with 0 and count up consecutively. This might be equal to the index of the physical core, but doesn’t have to be.

_eventName Token, literal text, name of the event as defined for a particular class.

eventParameter A [uint32] 0..4294967295 value as an argument to an event.

Therefore all ARTI macros for an AUTOSAR OS do compile the following template:

ARTI_TRACE(_contextName, <AR OS Class Name>, <OS Short Name>, <CoreIndex>, \

<Event Name>, <Event Parameter>)

Example of hook call in OS:

ARTI_TRACE( NOSUSP, AR_CP_OS_TASK, OS1, (uint32)GetCoreID(), OsTask_Activation, \

(uint32)GetTaskID());

Example of preprocessed output:

ARTI_TRACE_NOSUSP_AR_CP_OS_TASK_OS1_OsTask_Activation((uint32)GetCoreID(), \

(uint32)GetTaskID());

Class AR_CP_OS_APPLICATION

[SWS_Os_00838]

[RS_Arti_00029]

The OS shall create events of class AR_CP_OS_APPLICATION to allow tracing of OS applications [as defined for the AUTOSAR Classic Platform]

The states used by ARTI are based on the states of OS-Applications, see figure 7.10 in chapter Background & Rationale 7.6.1 for details.

States used by ARTI:

Transitions used by ARTI:

[SWS_Os_00839]

[RS_ARTIFO_00015]

ARTI macros of the class AR_CP_OS_APPLICATION shall compile the following template:

ARTI_TRACE(_contextName, AR_CP_OS_APPLICATION, <OS Short Name>, <CoreID>, \

<Event Name>, <Application ID>)

The <Core ID> for any event shall represent the core id where the corresponding application is running on.

The <Event Name> should follow the transition table above.

The <Application ID> shall be a numeric identifier of the OS Application.

Class AR_CP_OS_TASK

ARTI needs to trace all Task states and all state transitions within the OS. For some timing parameters (e.g. the "runtime" of a Task, which goes from started to terminated), the simple "ready" state of the OS is not enough. Tools evaluating the timings need to reconstruct a more complex state diagram by calculating the transitions from history. To be compatible to the pure OS state diagram, AR_CP_OS_TASK refers to this state model, knowing that tools need to postprocess the event flow to get all relevant information. However, if an OS implementation can provide a more detailed state diagram, ARTI allows to define more events that won’t need postprocessing and allow earlier synchronization of the trace if it is truncated (limited trace buffers). This state diagram is then handled with the class "AR_CP_OSARTI_TASK". If possible, the second state machine is to be preferred.

AR_CP_OS_TASK

[SWS_Os_00840]

[RS_Arti_00030]

The OS shall create events of class AR_CP_OS_TASK to allow tracing of Tasks.

The following state diagram shows the states and transitions as defined by the OS:

Transitions used by ARTI:

AR_CP_OSARTI_TASK

The class AR_CP_OSARTI_TASK contains events allowing the tracing of OS Tasks with an enhanced state model.

The following states diagram shows the state machine as used by ARTI:

States used by ARTI:

Transitions used by ARTI:

[SWS_Os_00841]

[RS_ARTIFO_00015]

ARTI macros of the classes AR_CP_OS_TASK and AR_CP_OSARTI_TASK shall compile the following templates:

ARTI_TRACE(_contextName, AR_CP_OS_TASK, <OS Short Name>, <Core ID>, <Event Name>, \
<Task ID>)
ARTI_TRACE(_contextName, AR_CP_OSARTI_TASK, <OS Short Name>, <Core ID>, \
<Event Name>, <Task ID>)

The <Core ID> for any event shall represent the core id where the corresponding Task is scheduled on.

The <Event Name> should follow the transition table above.

The <Task ID> shall be a numeric identifier of the OS Task.

Class AR_CP_OS_CAT2ISR

[SWS_Os_00849]

[RS_Arti_00031]

The OS shall create events to trace all states of Cat2Isrs and all state transitions within the OS ("Cat2Isr" refers to a category 2 interrupt service routine).

For some timing parameters (e.g. the interrupt pending time), the simple Category 2 interrupt start/stop of the OS is not enough. Tools evaluating the timings need to reconstruct a more complex state diagram by calculating the transitions from history. To be compatible to the OS, AR_CP_OS_CAT2ISR refers to this state model, knowing that tools need to postprocess the event flow to get all relevant information. However, if an OS implementation can provide a more detailed state diagram, ARTI allows to define more events that won't need postprocessing and allow earlier synchronization of the trace if it is truncated (limited trace buffers). This state diagram is then handled with the class "AR_CP_OSARTI_CAT2ISR". If possible, the second state machine is to be preferred.

AR_CP_OS_CAT2ISR

The class AR_CP_OS_CAT2ISR contains events allowing the tracing of Category 2 interrupts as defined for the AUTOSAR Classic Platform.

The following state diagram shows the states and transitions as defined by the OS:

Transitions used by ARTI:

AR_CP_OSARTI_CAT2ISR

The class AR_CP_OSARTI_CAT2ISR contains events allowing the tracing of Category 2 interrupts with an enhanced state model.

The following state diagram shows the state machine as used by ARTI:

States used by ARTI:

Transitions used by ARTI:

[SWS_Os_00842]

[RS_ARTIFO_00015]

ARTI macros of the classes AR_CP_OS_CAT2ISR and AR_CP_ OSARTI_CAT2ISR shall compile the following template:

ARTI_TRACE(_contextName, AR_CP_OS_CAT2ISR, <OS Short Name>, <Core Index>, \
<Event Name>, <Cat2Isr Index>)
ARTI_TRACE(_contextName, AR_CP_OSARTI_CAT2ISR, <OS Short Name>, <CoreIndex>, \
<Event Name>, <Cat2Isr Index>)

The <Core Index> for any event shall represent the core index where the corresponding Category 2 interrupt is scheduled on.

The <Event Name> should follow the transition table above.

The <Cat2Isr Index> shall be a numeric identifier of the Category 2 interrupt.

Class AR_CP_OS_SERVICECALLS

[SWS_Os_00843]

[RS_Arti_00032]

The OS shall create events of class AR_CP_OS_SERVICECALLS when entering and exiting the service call from an application context.

These hooks shall only be called, if the service call is called from an application context. It shall not be called, if the service call is used within the OS context.

The events apply only to the entries and exits of the service calls, not to the objects (and their states) handled by the service call.

[SWS_Os_00844]

[RS_ARTIFO_00015]

ARTI macros of the class AR_CP_OS_SERVICECALLS shall compile the following template:

ARTI_TRACE(_contextName, AR_CP_OS_SERVICECALLS, <OS Short Name>, <CoreIndex>, \

<eventName>, <eventParameter>)

The <Core Index> for any event in the following table shall represent the core id where the corresponding service call is called.

The <eventName> is a string literal composed of a prefix "OsServiceCall", the service call name and "_Start" or "_Return" for the entry or exit of the service call. E.g. when ActivateTask is called, the event names on entry and exit are OsServiceCall_ ActivateTask_Start rsp. OsServiceCall_ActivateTask_Return.

The <eventParamter> is an uint32 representation of either one of the function parameters or the return value. It depends on the service call and is listed in the following table:

If the eventParameter of a returning service call is not of type StatusType, and if the service call does not return E_OK, the hook shall be called with a non-valid value as eventParameter, to give the hook consuming tool the possibility to detect the failure of the call.

Class AR_CP_OS_SPINLOCK

[SWS_Os_00845]

[RS_Arti_00033]

The OS shall create events of class AR_CP_OS_SPINLOCK to allow tracing of OS spinlocks and all state transistions within the OS.

These macros mark an event of an actual state change, not the OS service call. (E.g. getting a spinlock may happen later than requesting it; a request to release may not cause a release if it is already released.)

[SWS_Os_00846]

[RS_ARTIFO_00015]

ARTI macros of the class AR_CP_OS_SPINLOCK shall compile the following template:

ARTI_TRACE(_contextName, AR_CP_OS_SPINLOCK, <OS Short Name>, <CoreIndex>, \

<_eventName>, <eventParameter>)

The <Core Index> for any event in the following table shall represent the core id where the corresponding service call is called.

The following events are part of the class AR_CP_OS_SPINLOCK:

Class AR_CP_OS_HOOK

[SWS_Os_00856]

[RS_Arti_00034]

The OS shall create events of class AR_CP_OS_HOOK when entering and exiting the hook function.

[SWS_Os_00857]

[RS_Arti_00034]

[RS_ARTIFO_00015]

ARTI macros of the class AR_CP_OS_HOOK shall compile the following template:

ARTI_TRACE(_contextName, AR_CP_OS_HOOK, <OS Short Name>, <Core Index>, \

<eventName>, <eventParameter>)

The <Core Index> for any event in the following table shall represent the core id on which the corresponding hook function is executed.

The <eventName> is a string literal composed of the prefix OsHook, the hook function name and _Start or _Return for the entry or exit of the hook function. E.g. when the ErrorHook is called, the event names on entry and exit are OsHook_ErrorHook_Start respectively OsHook_ErrorHook_Return.

The <eventParamter> is an uint32 representation of either the function parameter or the return value. It depends on the hook function and is listed in the following table:

The ARTI hook which indicates the exit of the ProtectionHook (e.g. eventName is OsHook_ProtectionHook_Return) shall be invoked after the OS has checked the ReturnValue of the ProtectionHook (based on the requirements described in chapter 7.8.2., for example [SWS_Os_00506] or [SWS_Os_00475]). The eventParameter of this ARTI hook shall reflect the action which is taken by the OS as a result of the return value of the ProtectionHook.

API specification

This chapter contains the APIs offered by the operating system. Note that not all services are available in all scalability classes, and that the behavior of some services is extended for specific scalability classes. For example, API to relatively start a ScheduleTable has an additional check if the ScheduleTable allows implicit synchronization. This check is only performed in SC2 and SC4 where synchronization of ScheduleTables is supported.

Constants

Error codes of type StatusType

The following constants are available in a multi-core environment.

[SWS_Os_91007]

[ ]

[SWS_Os_91002]

[ ]

Additional constants are in section 7.15 and [2].

Macros

OSMEMORY_IS_READABLE(<AccessType>)

OSMEMORY_IS_WRITEABLE(<AccessType>)

OSMEMORY_IS_EXECUTABLE(<AccessType>)

OSMEMORY_IS_STACKSPACE(<AccessType>)

These macros return a value not equal to zero if the memory is readable / writable / executable or stack space. The argument of the macros must be of type AccessType. Typically the return value of the service CheckTaskMemoryAccess (or CheckISRMemoryAccess) is used as argument for these macros.

Type definitions

ApplicationType (for OS-Applications)

[SWS_Os_00772]

[ ]

[SWS_Os_00826]

[SRS_Os_80005]

The range of valid OS-Applications described by ApplicationType shall be zero-based and consecutive. The Value of INVALID_OSAPPLICATION shall lie outside the range of valid OS-Application IDs.

Note:

The OS may use other representations internally for a performance optimal implementation.

ApplicationStateType

[SWS_Os_00773]

[ ]

ApplicationStateRefType

[SWS_Os_00774]

[ ]

TrustedFunctionIndexType

[SWS_Os_00775]

[ ]

TrustedFunctionParameterRefType

[SWS_Os_00776]

[ ]

AccessType

[SWS_Os_00777]

[ ]

ObjectAccessType

[SWS_Os_00778]

[ ]

ObjectTypeType

[SWS_Os_00779]

[ ]

MemoryStartAddressType

[SWS_Os_00780]

[ ]

MemorySizeType

[SWS_Os_00781]

[ ]

ISRType

[SWS_Os_00782]

[ ]

ScheduleTableType

[SWS_Os_00783]

[ ]

ScheduleTableStatusType

[SWS_Os_00784]

[ ]

ScheduleTableStatusRefType

[SWS_Os_00785]

[ ]

ProtectionReturnType

[SWS_Os_00787]

[ ]

RestartType

[SWS_Os_00788]

[ ]

PhysicalTimeType

[SWS_Os_00789]

[ ]

CoreIdType

[SWS_Os_00790]

[ ]

[SWS_Os_00825]

[SRS_Os_80011]

The range of valid Core-IDs described by CoreIdType shall be zero-based and consecutive.

SpinlockIdType

[SWS_Os_00791]

[ ]

TryToGetSpinlockType

[SWS_Os_00792]

[ ]

IdleModeType

[SWS_Os_00793]

[ ]

AreaIdType

[SWS_Os_91000]

[ ]

Function definitions

The availability of the following services is defined in table 7.4. The use of these services may be restricted depending on the context they are called from. See table 7.1 for details.

GetApplicationID

[SWS_Os_00016]

[ ]

[SWS_Os_00261]

[ ]

GetApplicationID shall return the application identifier to which the executing Task/ISR/hook was configured.

[SWS_Os_00262]

[ ]

If no OS-Application is running, GetApplicationID shall return INVALID_OSAPPLICATION.

[SWS_Os_00514]

[ ]

Availability of GetApplicationID: Available in Scalability Classes 3 and 4 and in multi-core systems.

GetCurrentApplicationID

[SWS_Os_00797]

[ ]

[SWS_Os_00798]

[ ]

GetCurrentApplicationID shall return the application identifier in which the current Task/ISR/hook is executed.

[SWS_Os_00799]

[ ]

If no OS-Application is running, GetCurrentApplicationID shall return INVALID_OSAPPLICATION.

[SWS_Os_00800]

[ ]

Availability of GetCurrentApplicationID: Available in Scalability Classes 3 and 4.

GetISRID

[SWS_Os_00511]

[ ]

[SWS_Os_00263]

[ ]

If called from category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID shall return the identifier of the currently executing ISR.

[SWS_Os_00264]

[ ]

If its caller is not a category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID shall return INVALID_ISR.

[SWS_Os_00515]

[ ]

Availability of GetISRID: Available in all Scalability Classes.

CallTrustedFunction

[SWS_Os_00097]

[ ]

[SWS_Os_00265]

[ ]

If <FunctionIndex> is a defined function index, CallTrustedFunction shall call the function <FunctionIndex> out of a list of implementation specific trusted functions with the protection settings of the OS-Application which provides the trusted function AND shall return E_OK after completion.

[SWS_Os_00312]

[ ]

Caveats of CallTrustedFunction:

The called trusted function must conform to the following C prototype: void TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndex Type,TrustedFunctionParameterRefType); (The arguments are the same as the arguments of CallTrustedFunction).

Normally, a user will not directly call this service, but it will be part of some standard interface, e.g. a standard I/O interface.

It is the duty of the called trusted function to check rights of passed parameters, especially if parameters are interpreted as out parameters.

It should be noted that the CallTrustedFunction does not disable timing protection for the Task which called the service. This may lead to timing faults (calls of the ProtectionHook) even inside of a trusted OS-Application. It is therefore recommended to use CallTrustedFunction only for stateless functions (e.g. functions which do not write or do not have internal states)

[SWS_Os_00266]

[ ]

When CallTrustedFunction calls the function <FunctionIndex>, that function shall be executed with the same processor mode, memory protection boundaries and the service protection limitations of the OS-Application to which it belongs. The notion of "current application" shall remain that of the calling Task or Category 2 ISR.

Reaction to timing protection can be defined to terminate the OS-Application. If a Task is inside CallTrustedFunction and Task rescheduling takes place within the same OS-Application, the newly running higher priority Task may cause timing protection and terminate the OS-Application, thus indirectly aborting the trusted function. To avoid this, the scheduling of other Tasks which belong to the same OS-Application as the caller needs to be restricted, as well as the availability of interrupts of the same OSApplication.

[SWS_Os_00565]

[ ]

When CallTrustedFunction is called and the caller of CallTrustedFunction is supervised with timing protection, the Operating System shall delay any timing protection errors until the CallTrustedFunction returns to a OsApplication with OsTrustedApplicationDelayTimingViolationCall == FALSE.

[SWS_Os_00564]

[ ]

If such a violation is detected inside a nested call sequence of CallTrustedFunction of a Task, the delay shall last until the return of CallTrustedFunction to an OsApplication with OsTrustedApplicationDelayTimingViolationCall == FALSE.

[SWS_Os_00563]

[ ]

The OperatingSystem shall not schedule any other Tasks which belong to the same OS-Application as the non-trusted caller of the service. It shall be done by priority ceiling. Also interrupts of Category 2 which belong to the same OS-Application shall be disabled during the execution of the service.

[SWS_Os_00364]

[ ]

If CallTrustedFunction calls the trusted function from a Category 2 ISR context, that function shall continue to run on the same interrupt priority and be allowed to call all system services defined for Category 2 ISR.

[SWS_Os_00365]

[ ]

If CallTrustedFunction calls the trusted function from a Task context, that function shall continue to run on the same priority and be allowed to call all system services defined for Tasks.

[SWS_Os_00292]

[ ]

If the function index <FunctionIndex> in a call of CallTrustedFunction is undefined, CallTrustedFunction shall return E_OS_SERVICEID.

[SWS_Os_00516]

[ ]

Availability of CallTrustedFunction: Available in Scalability Classes 3 and 4.

CheckISRMemoryAccess

[SWS_Os_00512]

[ ]

[SWS_Os_00267]

[ ]

If the ISR reference <ISRID> in a call of CheckISRMemoryAccess is valid, CheckISRMemoryAccess shall return the access rights of the ISR on the specified memory area.

[SWS_Os_00313]

[ ]

If an access right (e.g. "read") is not valid for the whole memory area specified in a call of CheckISRMemoryAccess, CheckISRMemoryAccess shall yield no access regarding this right.

[SWS_Os_00268]

[ ]

If the ISR reference <ISRID> is not valid, CheckISRMemoryAccess shall yield no access rights.

[SWS_Os_00517]

[ ]

Availability of CheckISRMemoryAccess: Available in Scalability Classes 3 and 4.

CheckTaskMemoryAccess

[SWS_Os_00513]

[ ]

[SWS_Os_00269]

[ ]

If the Task reference <TaskID> in a call of CheckTaskMemoryAccess is valid, CheckTaskMemoryAccess shall return the access rights of the Task on the specified memory area.

[SWS_Os_00314]

[ ]

If an access right (e.g. "read") is not valid for the whole memory area specified in a call of CheckTaskMemoryAccess, CheckTaskMemoryAccess shall yield no access regarding this right.

[SWS_Os_00270]

[ ]

If the Task reference <TaskID> in a call of CheckTaskMemoryAccess is not valid, CheckTaskMemoryAccess shall yield no access rights.

[SWS_Os_00518]

[ ]

Availability of CheckTaskMemoryAccess: Available in Scalability Classes 3 and 4

CheckObjectAccess

[SWS_Os_00256]

[ ]

[SWS_Os_00271]

[ ]

If the OS-Application <ApplID> in a call of CheckObjectAccess has access to the queried object, CheckObjectAccess shall return ACCESS.

[SWS_Os_00272]

[ ]

If the OS-Application <ApplID> in a call of CheckObjectAccess has no access to the queried object, CheckObjectAccess shall return NO_ACCESS.

[SWS_Os_00423]

[ ]

If in a call of CheckObjectAccess the object to be examined is not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckObjectAccess shall return NO_ACCESS.

[SWS_Os_00519]

[ ]

Availability of CheckObjectAccess: Available in Scalability Classes 3 and 4.

CheckObjectOwnership

[SWS_Os_00017]

[ ]

[SWS_Os_00273]

[ ]

If the object <ObjectType> specified in a call of CheckObjectOwnership exists, CheckObjectOwnership shall return the identifier of the OSApplication to which the object belongs.

[SWS_Os_00274]

[ ]

If in a call of CheckObjectOwnership the specified object <ObjectType> is invalid OR the argument of the type (the ". . .") is invalid OR the object does not belong to any OS-Application, CheckObjectOwnership shall return INVALID_ OSAPPLICATION.

[SWS_Os_00520]

[ ]

Availability of CheckObjectOwnership: Available in Scalability Classes 3 and 4 and in multi-core systems.

StartScheduleTableRel

[SWS_Os_00347]

[ ]

[SWS_Os_00275]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of StartScheduleTableRel is not valid, StartScheduleTableRel shall return E_OS_ID.

[SWS_Os_00452]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of StartScheduleTableRel is implicitely synchronized (OsScheduleTblSyncStrategy = IMPLICIT), StartScheduleTableRel shall return E_OS_ID.

[SWS_Os_00332]

[ ]

If <Offset> in a call of StartScheduleTableRel is zero StartScheduleTableRel shall return E_OS_VALUE.

[SWS_Os_00276]

[ ]

If the offset <Offset>) is greater than OsCounterMaxAllowedValue of the underlying Counter minus the Initial Offset, StartScheduleTableRel shall return E_OS_VALUE.

[SWS_Os_00277]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of StartScheduleTableRel is not in the state SCHEDULETABLE_STOPPED, StartScheduleTableRel shall return E_OS_STATE.

[SWS_Os_00278]

[ ]

If the input parameters of StartScheduleTableRel are valid and the state of ScheduleTable <ScheduleTableID> is SCHEDULETABLE_STOPPED, then StartScheduleTableRel shall start the processing of a ScheduleTable <ScheduleTableID>. The Initial Expiry Point shall be processed after <Offset> + Initial Offset ticks have elapsed on the underlying Counter. The state of <ScheduleTable ID> is set to SCHEDULETABLE_RUNNING before the service returns to the caller.

[SWS_Os_00521]

[ ]

Availability of StartScheduleTableRel: Available in all Scalability Classes.

StartScheduleTableAbs

[SWS_Os_00358]

[ ]

[SWS_Os_00348]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of StartScheduleTableAbs is not valid, StartScheduleTableAbs shall return E_OS_ID.

[SWS_Os_00349]

[ ]

If the <Start> in a call of StartScheduleTableAbs is greater than the OsCounterMaxAllowedValue of the underlying Counter, StartScheduleTableAbs shall return E_OS_VALUE.

[SWS_Os_00350]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of StartScheduleTableAbs is not in the state SCHEDULETABLE_STOPPED, StartScheduleTableAbs shall return E_OS_STATE.

[SWS_Os_00351]

[ ]

If the input parameters of StartScheduleTableAbs are valid and <ScheduleTableID> is in the state SCHEDULETABLE_STOPPED, StartScheduleTableAbs shall start the processing of ScheduleTable <ScheduleTableID> when the underlying Counter next equals <Start> and shall set the state of <Schedule TableID> to

SCHEDULETABLE_RUNNING (for a non-synchronized / Explicitly synchronized ScheduleTable) OR

SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS (for implicitly synchronized ScheduleTable)

before returning to the user. (The Initial Expiry Point will be processed when the underlying Counter next equals <Start>+Initial Offset).

[SWS_Os_00522]

[ ]

Availability of StartScheduleTableAbs: Available in all Scalability Classes.

StopScheduleTable

[SWS_Os_00006]

[ ]

[SWS_Os_00279]

[ ]

If the ScheduleTable identifier <ScheduleTableID> in a call of StopScheduleTable is not valid, StopScheduleTable shall return E_OS_ID.

[SWS_Os_00280]

[ ]

If the ScheduleTable with identifier <ScheduleTableID> is in state SCHEDULETABLE_STOPPED when calling StopScheduleTable, StopScheduleTable shall return E_OS_NOFUNC.

[SWS_Os_00281]

[ ]

If the input parameters of StopScheduleTable are valid, StopScheduleTableshall set the state of <ScheduleTableID> to SCHEDULETABLE_STOPPED and (stop the ScheduleTable <ScheduleTableID> from processing any further expiry points and) shall return E_OK.

[SWS_Os_00523]

[ ]

Availability of StopScheduleTable: Available in all Scalability Classes.

NextScheduleTable

[SWS_Os_00191]

[SRS_Os_00099]

[SWS_Os_00282]

[ ]

If the input parameter <ScheduleTableID_From> or <ScheduleTableID_To> in a call of NextScheduleTable is not valid, NextScheduleTable shall return E_OS_ID.

[SWS_Os_00330]

[ ]

If in a call of NextScheduleTable ScheduleTable <Schedule TableID_To> is driven by different Counter than ScheduleTable <ScheduleTable ID_From> then NextScheduleTable shall return an error E_OS_ID.

[SWS_Os_00283]

[ ]

If the ScheduleTable <ScheduleTableID_From> in a call of NextScheduleTable is in state SCHEDULETABLE_STOPPED OR in state SCHEDULETABLE_NEXT, NextScheduleTable shall leave the state of <ScheduleTable_ From> and <ScheduleTable_To> unchanged and return E_OS_NOFUNC.

[SWS_Os_00309]

[ ]

If the ScheduleTable <ScheduleTableID_To> in a call of NextScheduleTable is not in state SCHEDULETABLE_STOPPED, NextScheduleTable shall leave the state of <ScheduleTable_From> and <ScheduleTable_To> unchanged and return E_OS_STATE.

[SWS_Os_00484]

[ ]

If OsScheduleTblSyncStrategy of <ScheduleTableID_To> in a call of NextScheduleTable is not equal to the OsScheduleTblSyncStrategy of <ScheduleTableID_From> then NextScheduleTable shall return E_OS_ID.

[SWS_Os_00284]

[ ]

If the input parameters of NextScheduleTable are valid then NextScheduleTable shall start the processing of ScheduleTable <ScheduleTableID_To> <ScheduleTableID_From>.FinalDelay ticks after the Final Expiry Point on <ScheduleTableID_From> is processed and shall return E_OK. NextScheduleTable shall process the Initial Expiry Point on <ScheduleTableID_To> at <ScheduleTableID_ From>.Final Delay + <ScheduleTable_To>.Initial Offset ticks after the Final Expiry Point on <ScheduleTableID_From> is processed .

[SWS_Os_00324]

[ ]

If the input parameters of NextScheduleTable are valid AND the <ScheduleTableID_From> already has a "next" ScheduleTable then NextScheduleTableshall replace the previous "next" ScheduleTable with <ScheduleTableID_To> and shall change the old "next" ScheduleTable state to SCHEDULETABLE_STOPPED.

[SWS_Os_00505]

[ ]

If OsScheduleTblSyncStrategy of the ScheduleTables <ScheduleTableID_From> and <ScheduleTableID_To> in a call of NextScheduleTable is EXPLICIT and the Operating System module already synchronizes <ScheduleTableID_From>, NextScheduleTable shall continue synchonization after the start of processing <ScheduleTableID_To>.

[SWS_Os_00453]

[ ]

If the <ScheduleTableID_From> in a call of NextScheduleTable is stopped, NextScheduleTable shall not start the "next" ScheduleTable and change its state to SCHEDULETABLE_STOPPED.

[SWS_Os_00524]

[ ]

Availability of NextScheduleTable: Available in all Scalability Classes.

StartScheduleTableSynchron

[SWS_Os_00201]

[SRS_Os_11002]

[SWS_Os_00387]

[ ]

If in a call of StartScheduleTableSynchron the ScheduleTable <ScheduleTableID> is not valid OR the ScheduleTable <ScheduleTable ID> is not explicitly synchronized (OsScheduleTblSyncStrategy != EXPLICIT) StartScheduleTableSynchron shall return E_OS_ID.

[SWS_Os_00388]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of StartScheduleTableSynchron is not in the state SCHEDULETABLE_STOPPED, StartScheduleTableSynchron shall return E_OS_STATE.

[SWS_Os_00389]

[ ]

If <ScheduleTableID> in a call of StartScheduleTableSynchron is valid, StartScheduleTableSynchron shall set the state of <Schedule TableID> to SCHEDULETABLE_WAITING and start the processing of ScheduleTable <ScheduleTableID> after the synchronization count of the ScheduleTable is set via SyncScheduleTable. The Initial Expiry Point shall be processed when (DurationSyncValue)+InitialOffset ticks have elapsed on the synchronization Counter where:

Duration is <ScheduleTableID>.OsScheduleTableDuration

SyncValue is the <Value> parameter passed to the SyncScheduleTable

InitialOffset is the shortest expiry point offset in <ScheduleTableID>

[SWS_Os_00525]

[ ]

Availability of StartScheduleTableSynchron: Available in Scalability Classes 2 and 4.

SyncScheduleTable

[SWS_Os_00199]

[SRS_Os_11002]

[SWS_Os_00454]

[ ]

If the <ScheduleTableID> in a call of SyncScheduleTable is not valid OR ScheduleTable can not be explicitely synchronized (OsScheduleTblSyncStrategy is not equal to EXPLICIT) SyncScheduleTable shall return E_OS_ID.

[SWS_Os_00455]

[ ]

If the <Value> in a call of SyncScheduleTable is greater or equal than the OsScheduleTableDuration, SyncScheduleTable shall return E_OS_VALUE.

[SWS_Os_00456]

[ ]

If the state of the ScheduleTable <ScheduleTableID> in a call of SyncScheduleTable is equal to SCHEDULETABLE_STOPPED or SCHEDULETABLE_NEXT SyncScheduleTable shall return E_OS_STATE.

[SWS_Os_00457]

[ ]

If the parameters in a call of SyncScheduleTable are valid, SyncScheduleTable shall provide the Operating System module with the current synchronization count for the given ScheduleTable. (It is used to synchronize the processing of the ScheduleTable to the synchronization Counter.)

[SWS_Os_00526]

[ ]

Availability of SyncScheduleTable: Available in Scalability Classes 2 and 4.

SetScheduleTableAsync

[SWS_Os_00422]

[ ]

[SWS_Os_00362]

[ ]

If SetScheduleTableAsync is called for a running ScheduleTable, the Operating System module shall stop further synchronization until a SyncScheduleTable call is made.

[SWS_Os_00323]

[ ]

If SetScheduleTableAsync is called for a running ScheduleTable the Operating System module shall continue to process expiry points on the ScheduleTable.

[SWS_Os_00458]

[ ]

If OsScheduleTblSyncStrategy of <ScheduleTableID> in a call of SetScheduleTableAsync is not equal to EXPLICIT OR if <ScheduleTable ID> is invalid then SetScheduleTableAsync shall return E_OS_ID.

[SWS_Os_00483]

[ ]

If the current state of the <ScheduleTableID> in a call of SetScheduleTableAsync equals to SCHEDULETABLE_STOPPED, SCHEDULETABLE_NEXT or SCHEDULETABLE_WAITING then SetScheduleTableAsync shall return E_OS_STATE.

[SWS_Os_00300]

[ ]

If the current state of <ScheduleTableID> in a call of SetScheduleTableAsync equals SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS (or SCHEDULETABLE_RUNNING) then SetScheduleTableAsync shall set (or keep in case of SCHEDULETABLE_RUNNING) the status of <ScheduleTableID> to SCHEDULETABLE_RUNNING.

[SWS_Os_00527]

[ ]

Availability of SetScheduleTableAsync: Available in Scalability Classes 2 and 4.

GetScheduleTableStatus

[SWS_Os_00227]

[SRS_Os_11002]

[SWS_Os_00289]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of GetScheduleTableStatus is NOT started, GetScheduleTableStatus shall pass back SCHEDULETABLE_STOPPED via the reference parameter <ScheduleStatus> AND shall return E_OK.

[SWS_Os_00353]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of GetScheduleTableStatus was used in a NextScheduleTable call AND waits for the end of the current ScheduleTable, GetScheduleTableStatus shall return SCHEDULETABLE_NEXT via the reference parameter <ScheduleStatus> AND shall return E_OK.

[SWS_Os_00354]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of GetScheduleTableStatus is configured with explicit synchronization AND <ScheduleTableID> was started with StartScheduleTableSynchronAND no synchronization count was provided to the Operating System, GetScheduleTableStatus shall return SCHEDULETABLE_WAITING via the reference parameter <ScheduleStatus> AND shall return E_OK.

[SWS_Os_00290]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of GetScheduleTableStatus is started AND synchronous, GetScheduleTableStatus shall pass back SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS via the reference parameter <ScheduleStatus> AND shall return E_OK.

[SWS_Os_00291]

[ ]

If the ScheduleTable <ScheduleTableID> in a call of GetScheduleTableStatus is started AND NOT synchronous (deviation is not within the precision interval OR the ScheduleTable has been set asynchronous), GetScheduleTableStatus shall pass back SCHEDULETABLE_RUNNING via the reference parameter ScheduleStatus AND shall return E_OK.

[SWS_Os_00293]

[ ]

If the identifier <ScheduleTableID> in a call of GetScheduleTableStatus is NOT valid, GetScheduleTableStatus shall return E_OS_ID.

[SWS_Os_00528]

[ ]

Availability of GetScheduleTableStatus: Available in all Scalability Classes.

IncrementCounter

[SWS_Os_00399]

[ ]

[SWS_Os_00285]

[ ]

If the input parameter <CounterID> in a call of IncrementCounter is not valid OR the Counter is a hardware Counter, IncrementCounter shall return E_OS_ID.

[SWS_Os_00286]

[SRS_Os_11020]

If the input parameter of IncrementCounter is valid, IncrementCounter shall increment the Counter <CounterID> by one (if any alarm connected to this Counter expires, the given action, e.g. Task activation, is done) and shall return E_OK.

[SWS_Os_00321]

[ ]

If in a call of IncrementCounter an error happens during the execution of an alarm action, e.g. E_OS_LIMIT caused by a Task activation, IncrementCounter shall call the error hook(s), but the IncrementCounter service itself shall return E_OK.

[SWS_Os_00529]

[ ]

Caveats of IncrementCounter: If called from a Task, rescheduling may take place.

[SWS_Os_00530]

[ ]

Availability of IncrementCounter: Available in all Scalability Classes.

GetCounterValue

[SWS_Os_00383]

[SRS_Frt_00025]

[SWS_Os_00376]

[ ]

If the input parameter <CounterID> in a call of GetCounterValue is not valid, GetCounterValue shall return E_OS_ID.

[SWS_Os_00377]

[SRS_Frt_00033]

If the input parameter <CounterID> in a call of GetCounterValue is valid, GetCounterValue shall return the current tick value of the Counter via <Value> and return E_OK.

[SWS_Os_00531]

[ ]

Caveats of GetCounterValue: Note that for counters of OsCounterType = HARDWARE the real timer value (the - possibly adjusted - hardware value, see [SWS_Os_00384]) is returned, whereas for counters of OsCounterType = SOFTWARE the current "software" tick value is returned.

[SWS_Os_00532]

[ ]

Availability of GetCounterValue: Available in all Scalability Classes.

GetElapsedValue

[SWS_Os_00392]

[SRS_Frt_00025]

[SWS_Os_00381]

[ ]

If the input parameter <CounterID> in a call of GetElapsedValue is not valid GetElapsedValue shall return E_OS_ID.

[SWS_Os_00391]

[ ]

If the <Value> in a call of GetElapsedValue is larger than the max allowed value of the <CounterID>, GetElapsedValue shall return E_OS_VALUE.

[SWS_Os_00382]

[SRS_Frt_00034]

If the input parameters in a call of GetElapsedValue are valid, GetElapsedValue shall return the number of elapsed ticks since the given <Value> value via <ElapsedValue> and shall return E_OK.

[SWS_Os_00460]

[ ]

GetElapsedValue shall return the current tick value of the Counter in the <Value> parameter.

[SWS_Os_00533]

[ ]

Caveats of GetElapsedValue:If the timer already passed the <Value> value a second (or multiple) time, the result returned is wrong. The reason is that the service can not detect such a relative overflow.

[SWS_Os_00534]

[ ]

Availability of GetElapsedValue: Available in all Scalability Classes.

TerminateApplication

[SWS_Os_00258]

[SRS_Os_11022]

[SRS_Os_11023]

[SWS_Os_00493]

[ ]

If the input parameter <Application> in a call of TerminateApplication is not valid TerminateApplication shall return E_OS_ID.

[SWS_Os_00459]

[ ]

If the <RestartOption> in a call of TerminateApplication is invalid, TerminateApplication shall return E_OS_VALUE.

[SWS_Os_00494]

[ ]

If the input parameter <Application> in a call of TerminateApplication is valid AND the caller belongs to a non-trusted OS-Application AND the caller does not belong to <Application> TerminateApplication shall return E_OS_ACCESS.

[SWS_Os_00507]

[ ]

If the state of <Application> in a call of TerminateApplication is APPLICATION_TERMINATED TerminateApplication shall return E_OS_STATE.

[SWS_Os_00508]

[ ]

If the state of <Application> in a call of TerminateApplication is APPLICATION_RESTARTING and the caller does not belong to the <Application> then TerminateApplication shall return E_OS_STATE.

[SWS_Os_00548]

[ ]

If the state of <Application> in a call of TerminateApplication is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND the <RestartOption> is equal RESTART then TerminateApplication shall return E_OS_STATE.

[SWS_Os_00287]

[SRS_Os_11023]

If the parameters in a call of TerminateApplication are valid and the above criteria are met TerminateApplication shall terminate <Application> (i.e. to kill all Tasks, disable the interrupt sources of those ISRs which belong to the OS-Application and free all other OS resources associated with the application) AND shall activate the configured OsRestartTask of <Application> if <RestartOption> equals RESTART. If no OsRestartTask is configured, no restart shall happen. If the <Application> is restarted, its state is set to APPLICATION_RESTARTING otherwise to APPLICATION_TERMINATED. If the caller belongs to <Application> TerminateApplication shall not return, otherwise it shall return E_OK.

[SWS_Os_00535]

[ ]

Caveats of TerminateApplication:

If no applications are configured the implementation shall make sure that this service is not available.

Tasks and interrupts that are owned by a trusted application can terminate any OS-Application. Tasks and interrupts that are owned by a non-trusted application can only terminate their owning OS-Application.

Note:

Although trusted OS-Application can be forcibly terminated by Tasks/Interrupts of other trusted OS-Applications it is not recommended. This may have further impacts, e.g. to users who are currently part of such an OS-Application via a CallTrustedFunction call.

[SWS_Os_00536]

[ ]

Availability of TerminateApplication: Available in Scalability Classes 3 and 4.

AllowAccess

[SWS_Os_00501]

[ ]

[SWS_Os_00497]

[ ]

If the state of the OS-Application of the caller of AllowAccess is not APPLICATION_RESTARTING AllowAccess shall return E_OS_STATE.

[SWS_Os_00498]

[ ]

If the state of the OS-Application of the caller of AllowAccess is APPLICATION_RESTARTING, AllowAccess shall set the state to APPLICATION_ACCESSIBLE and allow other OS-Applications to access the configured objects of the callers OS-Application.

[SWS_Os_00547]

[ ]

Availability of AllowAccess: Available in Scalability Classes 3 and 4.

GetApplicationState

[SWS_Os_00499]

[ ]

[SWS_Os_00495]

[ ]

If the <Application> in a call of GetApplicationState is not valid GetApplicationState shall return E_OS_ID.

[SWS_Os_00496]

[ ]

If the parameters in a call of GetApplicationState are valid, GetApplicationState shall return the state of OS-Application <Application> in <Value>.

[SWS_Os_00537]

[ ]

Availability of GetApplicationState: Available in Scalability Classes 3 and 4.

GetNumberOfActivatedCores

[SWS_Os_00672]

[SRS_Os_80001]

The function GetNumberOfActivatedCores shall be callable from within a Task and an Category 2 ISR. Otherwise the behavior is unspecified.

[SWS_Os_00673]

[SRS_Os_80001]

The return value of GetNumberOfActivatedCores shall be less or equal to the configured value of OsNumberOfCores.

GetCoreID

[SWS_Os_00674]

[SRS_Os_80001]

[SWS_Os_00675]

[SRS_Os_80001]

The function GetCoreID shall return the unique logical CoreID of the core on which the function is called. The mapping of physical cores to logical Core IDs is implementation specific.

StartCore

[SWS_Os_00676]

[SRS_Os_80006]

[SWS_Os_00677]

[SRS_Os_80006]

The function StartCore shall start one core that shall run under the control of the AUTOSAR OS.

[SWS_Os_00678]

[SRS_Os_80006]

Calls to the StartCore function after StartOS shall return with E_OS_ACCESS and the core shall not be started.

[SWS_Os_00679]

[SRS_Os_80006]

If the parameter CoreIDs refers to a core that was already started by the function StartCore the related core is ignored and E_OS_STATE shall be returned.

[SWS_Os_00681]

[SRS_Os_80006]

There is no call to the ErrorHook if an error occurs during StartCore.

GetSpinlock

[SWS_Os_00686]

[SRS_Os_80021]

[SWS_Os_00687]

[SRS_Os_80021]

The function GetSpinlock shall occupy a spinlock. If the spinlock is already occupied the function shall busy wait until the spinlock becomes available.

[SWS_Os_00688]

[SRS_Os_80021]

The function GetSpinlock shall return E_OK if no error was detected. The spinlock is now occupied by the calling Task/Category 2 ISR on the calling core.

[SWS_Os_00689]

[SRS_Os_80021]

The function GetSpinlock shall return E_OS_ID if the parameter SpinlockID refers to a spinlock that does not exist.

[SWS_Os_00690]

[SRS_Os_80021]

The function GetSpinlock shall return E_OS_INTERFERENCE_DEADLOCK if the spinlock referred by the parameter Spinlock ID is already occupied by a Task/Category 2 ISR on the same core.

[SWS_Os_00691]

[SRS_Os_80021]

The function GetSpinlock shall return E_OS_NESTING_DEADLOCK if the sequence by which multiple spinlocks are occupied at the same time on one core do not comply with the configured order.

[SWS_Os_00692]

[SRS_Os_80021]

The function GetSpinlock shall return E_OS_ACCESS if the accessing OS-Application was not listed in the configuration (OsSpinlock).

[SWS_Os_00693]

[SRS_Os_80021]

It shall be allowed to call the function GetSpinlock while interrupts are disabled.

[SWS_Os_00694]

[SRS_Os_80021]

It shall be allowed to call the function GetSpinlock while a Resource is occupied.

ReleaseSpinlock

[SWS_Os_00695]

[SRS_Os_80021]

[SWS_Os_00696]

[SRS_Os_80021]

The function ReleaseSpinlock shall release a spinlock that has been occupied by the same (calling) Task. If the related GetSpinlock call used configured locks (OsSpinlockLockMethod) the function shall also perform the undo of the used lock.

[SWS_Os_00697]

[SRS_Os_80021]

The function ReleaseSpinlock shall return E_OK if no error was detected. The spinlock is now free and can be occupied by the same or other Tasks.

[SWS_Os_00698]

[SRS_Os_80021]

The function ReleaseSpinlock shall return E_OS_ID if the parameter SpinlockID refers to a spinlock that does not exist.

[SWS_Os_00699]

[SRS_Os_80021]

The function ReleaseSpinlock shall return E_OS_STATE if the parameter SpinlockID refers to a spinlock that is not occupied by the calling Task.

[SWS_Os_00700]

[SRS_Os_80021]

The function ReleaseSpinlock shall return E_OS_ACCESS if the Task has no access to the spinlock referred by the parameter SpinlockID.

[SWS_Os_00701]

[SRS_Os_80021]

The function ReleaseSpinlock shall return E_OS_NOFUNC if the Task tries to release a spinlock while another spinlock (or Resource) has to be released before. No functionality shall be performed.

TryToGetSpinlock

[SWS_Os_00703]

[SRS_Os_80021]

[SWS_Os_00704]

[SRS_Os_80021]

The function TryToGetSpinlock shall atomically test the availability of the spinlock and if available occupy it. The result of success is returned.

[SWS_Os_00705]

[SRS_Os_80021]

The function TryToGetSpinlock shall set the OUT parameter "Success" to TRYTOGETSPINLOCK_SUCCESS if the spinlock was successfully occupied, and TRYTOGETSPINLOCK_NOSUCCESS if not. In both cases E_OK shall be returned.

[SWS_Os_00706]

[SRS_Os_80021]

If the function TryToGetSpinlock does not return E_OK, the OUT parameter "Success" shall be undefined.

[SWS_Os_00707]

[SRS_Os_80021]

The function TryToGetSpinlock shall return E_OS_ID if the parameter SpinlockID refers to a spinlock that does not exist.

[SWS_Os_00708]

[SRS_Os_80021]

The function TryToGetSpinlock shall return E_OS_INTERFERENCE_DEADLOCK if the spinlock referred by the parameter Spinlock ID is already occupied by a Task on the same core.

[SWS_Os_00709]

[SRS_Os_80021]

The function TryToGetSpinlock shall return E_OS_NESTING_DEADLOCK if a Task tries to occupy a spinlock while holding a different spinlock in a way that may cause a deadlock.

[SWS_Os_00710]

[SRS_Os_80021]

The function TryToGetSpinlock shall return E_OS_ACCESS if the Task has no access to the spinlock referred by the parameter SpinlockID.

[SWS_Os_00711]

[SRS_Os_80021]

It shall be allowed to call the function TryToGetSpinlock while interrupts are disabled.

[SWS_Os_00712]

[SRS_Os_80021]

It shall be allowed to call the function TryToGetSpinlock while a Resource is occupied.

ShutdownAllCores

[SWS_Os_00713]

[SRS_Os_80007]

[SRS_BSW_00336]

[SWS_Os_00714]

[SRS_Os_80007]

A synchronized shutdown shall be triggered by the API function ShutdownAllCores.

[SWS_Os_00715]

[SRS_Os_80007]

ShutdownAllCores shall not return.

[SWS_Os_00716]

[SRS_Os_80007]

If ShutdownAllCores is called from non trusted code the call shall be ignored.

ControlIdle

[SWS_Os_00769]

[SRS_Os_80022]

[SWS_Os_00770]

[SRS_Os_80023]

The function ControlIdle shall return E_OK if no error was detected and the parameters are valid.

[SWS_Os_00771]

[SRS_Os_80023]

The function ControlIdle shall return E_OS_ID if the parameter CoreID or IdleMode is invalid (e.g. refered core does not exist; idle mode is not known). In single core systems the check of CoreID shall be omitted.

[SWS_Os_00802]

[SRS_Os_80023]

If the core (given by CoreID) is already in another idle mode (different to the given IdleMode) the new IdleMode shall become effective the next time that core enters the idle mode.

ReadPeripheral8

[SWS_Os_91013]

[SRS_Os_11005]

ReadPeripheral16

[SWS_Os_91015]

[SRS_Os_11005]

ReadPeripheral32

[SWS_Os_91014]

[SRS_Os_11005]

WritePeripheral8

[SWS_Os_91010]

[SRS_Os_11005]

WritePeripheral16

[SWS_Os_91012]

[SRS_Os_11005]

WritePeripheral32

[SWS_Os_91011]

[SRS_Os_11005]

ModifyPeripheral8

[SWS_Os_91016]

[SRS_Os_11005]

ModifyPeripheral16

[SWS_Os_91018]

[SRS_Os_11005]

ModifyPeripheral32

[SWS_Os_91017]

[SRS_Os_11005]

EnableInterruptSource

[SWS_Os_91020]

[SRS_Os_11011]

DisableInterruptSource

[SWS_Os_91019]

[SRS_Os_11011]

ClearPendingInterrupt

[SWS_Os_91021]

[SRS_Os_11011]

ActivateTaskAsyn

[SWS_Os_91022]

[SRS_Os_80015]

[SWS_Os_00818]

[SRS_Os_80015]

Availability of ActivateTaskAsyn: Available in systems which support OS-Applications.

Note:

If during the Task activation an error occurs, and the caller is already gone (e.g. callers OS-Application is already terminated, OR callers core is shutting down OR ...) calls to error hooks are dropped and no reporting is done.

SetEventAsyn

[SWS_Os_91023]

[SRS_Os_80015]

[SWS_Os_00819]

[SRS_Os_80015]

Availability of SetEventAsyn: Available in systems which support OS-Applications.

Note:

If during the event setting an error occurs and the caller is already gone (e.g. callers OS-Application is already terminated, OR callers core is shutting down OR ...) calls to error hooks are dropped and no reporting is done.

IOC

Imported types

In this chapter all types included from the following modules are listed:

[SWS_Os_91029]

[ ]

[SWS_Os_00827]

[SRS_Os_80020]

If an ImplementationDataType is defined with the typeEmitter empty or set to RTE and is used for IOC communication, the IOC shall include Rte_ Type.h.

[SWS_Os_00828]

[SRS_Os_80020]

If an ImplementationDataType is defined with the typeEmitter != RTE and does end with ".h" and is used for IOC communication, the IOC shall include specified header file.

Type definitions

None

Constants

Function definitions

[SWS_Os_00805]

[SRS_Os_80020]

The optional length parameter of the API shall be generated if the VariableDataPrototype is of type dynamic and no size indicator is used in the according ApplicationArrayDataType.

IocInit (DRAFT)

[SWS_Os_91026]{DRAFT}

[ ]

IocSend/IocWrite

The IocWrite API call is generated for "data" (unqueued) semantics and the IocSend API call is generated for "event" (queued) semantics.

[SWS_Os_00718]

[SRS_Os_80020]

[SWS_Os_91003]

[ ]

General:

[SWS_Os_00719]

[SRS_Os_80020]

IocSend/IocWrite is asynchronous in that way it shall not have to wait for the reception of the data on the receiving side to return from execution.

[SWS_Os_00720]

[SRS_Os_80020]

The IocSend/IocWrite function shall not return until the data given in parameter have been completely physically sent over the communication medium. For example in case of communication over shared RAM, an IocSend/IocWrite shall return when all data have been copied in the target shared RAM.

[SWS_Os_00721]

[SRS_Os_80020]

In case of "event" (queued) semantic, the IocSend function shall guarantee the order of delivery. In case of senders from different cores, the order in which messages are received will be determined by the implementation.

[SWS_Os_00722]

[SRS_Os_80020]

The IocSend/IocWrite function shall support mechanism to guarantee data-Integrity during transmission. The IocSend/IocWrite function shall solve the crossing of the protection boundaries of OS-Applications. It has to be generated in case of intra-core and inter-core communication.

[SWS_Os_00820]

[ ]

The IocSend/IocWrite function shall be wrapped with the memory allocation keywords mechanism

#define OS_<IE>_START_SEC_CODE
#include "Os_MemMap.h"

<IocSend, IocWrite>

#define OS_<IE>_STOP_SEC_CODE
#include "Os_MemMap.h"

where <IE> is the shortName of the sending OsApplication configured in OsIocSendingOsApplicationRef of the respective OsIocCommunication channel.

Parameters:

[SWS_Os_00723]

[SRS_Os_80020]

The IN <Data> parameter of the IocSend/IocWrite function shall be passed by value for primitive data types, as an pointer to the array base type for arrays and by reference for all other types.

[SWS_Os_00724]

[SRS_Os_80020]

For data passed as an pointer to the array base type or by reference, the IocSend/IocWrite function shall guarantee upon return that the parameter is safe for re-use.

Returned values:

[SWS_Os_00725]

[SRS_Os_80020]

The IocSend/IocWrite function shall return IOC_E_OK if the data was passed successfully to the communication service.

[SWS_Os_00726]

[SRS_Os_80020]

In case of "event" semantic the IocSend function shall return IOC_E_LIMIT if an IOC internal transmission buffer became full (Case: Receiver is slower than sender or/and configured internal IOC buffer size is too small). If this error occurs the IOC internal buffer could not be filled with the parameter. In that case this error shall produce an IOC_E_LOST_DATAOverlayed Error on the receiver side at the next data reception (s. SWS_Os_00745).

Internal structures:

[SWS_Os_00727]

[SRS_Os_80020]

In case of "event" semantic the IOC shall configure its internal transmission buffer size with the value of the attribute OsIocBufferLength.

IocSendGroup/IocWriteGroup

The IocWriteGroup API call is generated for "data" (unqueued) semantics and the IocSendGroup API call is generated for "event" (queued) semantics.

[SWS_Os_00728]

[SRS_Os_80020]

[SWS_Os_91004]

[ ]

General:

[SWS_Os_00729]

[SRS_Os_80020]

IocSendGroup/IocWriteGroup is asynchronous in that way it shall not have to wait for the reception of the data on the receiving side to return from execution.

[SWS_Os_00730]

[SRS_Os_80020]

The IocSendGroup/IocWriteGroup function shall not return until the data given in parameter have been completely physically sent over the communication medium. For example in case of communication over shared RAM, an IocSendGroup/IocWriteGroup shall return when all data have been copied in the target shared RAM.

[SWS_Os_00731]

[SRS_Os_80020]

In case of "event" semantic, the IocSendGroup function shall guarantee the order of delivery.

[SWS_Os_00732]

[SRS_Os_80020]

The IocSendGroup/IocWriteGroup function shall support mechanisms to guarantee data-Integrity during transmission. The IocSendGroup/IocWriteGroup function shall solve the crossing of the protection boundaries of OS-Applications. It has to be generated in case of intra-core and inter-core communication.

[SWS_Os_00821]

[ ]

The IocSendGroup/IocWriteGroup function shall be wrapped with the memory allocation keywords mechanism

#define OS_<IE>_START_SEC_CODE
#include "Os_MemMap.h"

<IocSendGroup, IocWriteGroup>

#define OS_<IE>_STOP_SEC_CODE
#include "Os_MemMap.h"

where <IE> is the shortName of the sending OsApplication configured in OsIocSendingOsApplicationRef of the respective OsIocCommunication channel.

Parameters:

[SWS_Os_00733]

[SRS_Os_80020]

The IN <DataN> parameters of the IocSendGroup/IocWriteGroup function shall be passed by values for primitive data types, as pointer to the array base type for arrays and by references for all other types.

[SWS_Os_00734]

[SRS_Os_80020]

For data passed as an pointer to the array base type or by reference, the IocSendGroup/IocWriteGroup function shall guarantee upon return that the parameter is safe for re-use.

Returned values:

[SWS_Os_00735]

[SRS_Os_80020]

The IocSendGroup/IocWriteGroup function shall return IOC_ E_OK if the data was passed successfully to the communication service.

[SWS_Os_00736]

[SRS_Os_80020]

In case of "event" semantic the IocSendGroup function shall return IOC_E_LIMIT if an IOC internal transmission buffer got full (Case: Receiver is slower than sender or/and configured internal IOC buffer size is too small). If this error occurs the IOC Internal buffer could not be filled with the parameter. In that case this error produces an IOC_E_LOST_DATAOverlayed Error on the receiver side at the next data reception.

Internal structures:

[SWS_Os_00737]

[SRS_Os_80020]

In case of "event" semantic the IOC shall configure its internal transmission buffer size with the value of the attribute OsIocBufferLength.

IocReceive/IocRead

The IocRead API call is generated for "data" and the IocReceive API call is generated for "events".

[SWS_Os_00738]

[SRS_Os_80020]

[SWS_Os_91005]

[ ]

General:

[SWS_Os_00739]

[SRS_Os_80020]

A successful call to the IocReceive/IocRead function indicates that data has been received successfully in the OUT <Data> given in parameter. The IocReceive/IocRead function has to be generated in case of intra-core and inter-core communication.

[SWS_Os_00822]

[ ]

The IocReceive/IocRead function shall be wrapped with the memory allocation keywords mechanism

#define OS_<IE>_START_SEC_CODE
#include "Os_MemMap.h"

<IocReceive, IocRead>

#define OS_<IE>_STOP_SEC_CODE
#include "Os_MemMap.h"

where <IE> is the shortName of the reading OsApplication configured in OsIocReceivingOsApplicationRef of the respective OsIocCommunication channel.

[SWS_Os_00740]

[SRS_Os_80020]

If the OsIocReceiverPullCB attribute is defined with a callback function name, the IOC shall call this function on the receiving core for each data transmission.

Parameters:

[SWS_Os_00741]

[SRS_Os_80020]

In case of "data" semantic the IocRead function shall always be able to deliver the last available datum. In case of senders from different cores, the precision of the order might be limited by the hardware and implementation.

[SWS_Os_00742]

[SRS_Os_80020]

The IocReceive/IocRead function shall guarantee upon returning from execution that the reference given in parameter is safe for use.

[SWS_Os_00803]

[SRS_Os_80020]

The OUT <Data> parameter of the IocReceive/IocRead function shall be passed as an pointer to the array base type for arrays and by reference for all other types.

Returned values:

[SWS_Os_00743]

[SRS_Os_80020]

The IocReceive/IocRead function shall return IOC_E_OK if the data was received successfully in the OUT <Data> parameter.

[SWS_Os_00744]

[SRS_Os_80020]

In case of "event" semantic and if no data is available the function IocReceive shall return IOC_E_NO_DATA.

[SWS_Os_00745]

[SRS_Os_80020]

In case of "event" semantic an IOC_E_LOST_DATAOverlayed Error shall be returned by the IocReceive function if the IOC communication service refused an IocSend request from sender due to an internal buffer overflow. There is no error in the data returned in parameter.

IocReceiveGroup/IocReadGroup

The IocReadGroup API call is generated for "data" and the IocReceiveGroup API call is generated for "events".

[SWS_Os_00746]

[SRS_Os_80020]

[SWS_Os_91006]

[ ]

General:

[SWS_Os_00747]

[SRS_Os_80020]

A successful call to the IocReceiveGroup/IocReadGroup function indicates that data has been received successfully in the given parameters. The IocReceiveGroup/IocReadGroup function has to be generated in case of intracore and inter-core communication.

[SWS_Os_00823]

[ ]

The IocReceiveGroup/IocReadGroup function shall be wrapped with the memory allocation keywords mechanism

#define OS_<IE>_START_SEC_CODE
#include "Os_MemMap.h"

<IocReceiveGroup, IocReadGroup>

#define OS_<IE>_STOP_SEC_CODE
#include "Os_MemMap.h"

where <IE> is the shortName of the reading OsApplication configured in OsIocReceivingOsApplicationRef of the respective OsIocCommunication n channel.

[SWS_Os_00748]

[SRS_Os_80020]

If the OsIocReceiverPullCB attribute is defined with a callback function name, the IOC shall call this function on the receiving core for each data transmission.

Parameters:

[SWS_Os_00749]

[SRS_Os_80020]

In case of "data" semantic the IocReadGroup function shall always be able to deliver the last available datum.

[SWS_Os_00750]

[SRS_Os_80020]

The IocReceiveGroup/IocReadGroup function shall guarantee upon returning from execution that the references given in parameters are safe for use.

[SWS_Os_00804]

[ ]

The OUT <DataN> parameters of the IocReceiveGroup/ IocReadGroup function shall be passed as pointer to the array base type for arrays and by references for all other types.

Returned values:

[SWS_Os_00751]

[SRS_Os_80020]

The IocReceiveGroup/IocReadGroup function shall return IOC_E_OK if the data was received successfully in the list of references given in parameter.

[SWS_Os_00752]

[SRS_Os_80020]

In case of "event" semantic and if no data is available the function IocReceiveGroup shall return IOC_E_NO_DATA.

[SWS_Os_00753]

[SRS_Os_80020]

In case of "event" semantic an IOC_E_LOST_DATAOverlayed Error shall be returned by the IocReceiveGroup function if the IOC communication service refused an IocSendGroup request from sender due to an internal buffer overflow. There is no error in the data returned in parameter.

IocEmptyQueue

[SWS_Os_00754]

[SRS_Os_80020]

General:

[SWS_Os_00755]

[SRS_Os_80020]

The function IocEmptyQueue_<IocId> shall be present for all IOC elements with queued semantics.

[SWS_Os_00756]

[SRS_Os_80020]

The function IocEmptyQueue_<IocId> shall delete all contents from the associated data queue. The IocEmptyQueue should be generated in a more efficient way than an iterative call to an IocReceive function.

Expected Interfaces

In this chapter all interfaces required from other modules are listed.

Mandatory Interfaces

There are no mandatory interfaces for the IOC.

Optional Interfaces

ReceiverPullCB

[SWS_Os_00757]

[SRS_Os_80020]

[SWS_Os_00758]

[SRS_Os_80020]

The <ReceiverPullCB> function name shall be defined within a configuration file for each IOC communication in the OsIocReceiverPullCB attribute.

[SWS_Os_00759]

[SRS_Os_80020]

The name of the callback shall be unique over the micro controller. For this purpose the following example can be considered as orientation for the IOC user: Example: Rte_IocReceiveCB_<IocId>.

[SWS_Os_00760]

[SRS_Os_80020]

The <ReceiverPullCB> function on the receiver side is using the access rights of the receiving OsApplication.

Note:

This means that such a callback cannot be reused by another OsApplication.

[SWS_Os_00761]

[SRS_Os_80020]

This notification mechanism shall be supported for both queued and unqueued communication semantic.

The owner of the <ReceiverPullCB> function shall pay attention that the execution time of the function shall not last too long. It shall be possible to call this function from an IOC-ISR.

Hook functions

Hook functions are called by the operating system if specific conditions are met. They are provided by the user. Besides the ProtectionHook below, the hooks from [8] and/or extensions from 7.12 may be called by the OS.

ProtectionHook

[SWS_Os_00538]

[ ]

Depending on the return value the Operating System module will either:

forcibly terminate the Task/Category 2 ISR which causes the problem OR

forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional with restart) OR

shutdown the system OR

do nothing

(see 7.8.2)

[SWS_Os_00308]

[ ]

If ProtectionHook returns an invalid value, the Operating System module shall take the same action as if no protection hook is configured.

[SWS_Os_00542]

[ ]

Availability of ProtectionHook: Available in Scalability Classes 2, 3 and 4.

Application specific StartupHook

[SWS_Os_00539]

[ ]

The application specific StartupHook is always called after the standard StartupHook (see [SWS_Os_00236]). If more than one OS-Application is configured which use startup hooks, the order of calls to the startup hooks of the different OSApplications is not defined.

[SWS_Os_00543]

[ ]

Availability of StartupHook_<App>: Available in Scalability Classes 3 and 4.

Application specific ErrorHook

[SWS_Os_00540]

[ ]

If the general ErrorHook is configured, the general ErrorHook is called before the application specific error hook is called (see [SWS_Os_00246]).

[SWS_Os_00544]

[ ]

Availability of ErrorHook_<App>: Available in Scalability Classes 3 and 4.

Application specific ShutdownHook

[SWS_Os_00541]

[ ]

If the general ShutdownHook is configured, the general ShutdownHook is called after all application specific shutdown hook(s) are called (see [SWS_Os_00237]). If more OS-Applications with an application specific shutdown hook exist the order of calls to these application specific shutdown hooks is not defined.

[SWS_Os_00545]

[ ]

Availability of ShutdownHook_<App>: Available in Scalability Classes 3 and 4.

Service Interfaces

Port interface of Os

[SWS_Os_91027]

[ ]

Client-Server-Interfaces

Os_Service

[SWS_Os_00560]

[ ]

Implementation Data Types

[SWS_Os_00794]

[ ]

[SWS_Os_00786]

[ ]

Sequence diagrams

Sequence chart for calling trusted functions

The above sequence describes a call to the CallTrustedFunction service. It starts with a user who calls a service which requires itself a call to a trusted function. The service then packs the argument for the trusted function into a structure and calls CallTrustedFunction with the ID and the pointer as arguments. Afterwards the OS checks if the access to the requested service is valid. If no access is granted E_OS_SERVICEID is returned. Otherwise the trusted service itself is called and the function checks the arguments for access right, etc.

Sequence chart for usage of ErrorHook

The above sequence chart shows the sequence of error hook calls in case a service does not return with E_OK. Note that in this case the general error hook and the OSApplication specific error hook are called.

Sequence chart for ProtectionHook

The sequence shows the flow of control if a protection error occurs. Depending on the return values of the ProtectionHook, either the faulty Task/ISR is forcibly terminated or the OS-Application is forcibly terminated or the system is shut down. If the action is to terminate the faulty OS-Application an option is to start afterwards the restart Task, which can do a cleanup, etc.

Sequence chart for StartupHook

The above sequence shows the flow of control during the startup of the OS. Like in OSEK OS the user calls the StartOS service to start the OS. During the startup the startup hooks are called in the above order. The rest of the startup sequence is identical to the defined behaviour of OSEK OS.

Sequence chart for ShutdownHook

The above sequence shows the behaviour in case of a shut down. The flow is the same as in OSEK OS with the exception that the shut down hooks of the OS-Applications are called before the general ShutdownHook is called. Note that the specific shutdown hooks of the application are not allowed to block, they must return to the caller.

Sequence diagrams of Sender Receiver communication over the IOC

Last-is-best communication

The 9.6 shows a sequence of successful and failure cases in the interaction between the IOC and the RTE in case of last-is-best communication ("data" semantic).

Queued communication without pull callback

The figure 9.7 shows the interaction between IOC and RTE with a focus on the congestion control for a queued communication.

The defined communication has no callback functionality for data reception, has an internal buffer size of 2 data elements, no waitpoints are defined and the implicated OS-Applications are located on different cores.

Queued communication with pull callback

The figure 9.8 shows the interaction between IOC and RTE in case of a queued communication with an activated callback functionality. The RTE might handle notification internally and might therefore not provide any callback functions, but a similar scenario will occur in case of communication between CDDs on different cores. The receiving CDD will provide the callback function in this case.

The defined communication has no waitpoints and describes a communication implicating two OS-Applications located on different cores.

Configuration specification

Rules for paramters

Some configuration parameters are configured as floating point values and sometimes these values must be rounded in order to be used. The following rules define the rounding of specific parameters:

Execution times (for the timing protection) are "round down"

Timeframes are "round down"

Containers and configuration parameters

The following chapters summarize all configuration parameters and their containers. Background information about the detailed meaning of the parameters can be found in chapters 7 and 8.

For better readability OIL names of the 2.1 OS specification are given in curly braces in the namefield of configuration parameters.

Os

OsAlarmSetEvent

OsAlarm

OsAlarmAction

OsAlarmActivateTask

OsAlarmAutostart

OsAlarmCallback

OsAlarmIncrementCounter

OsApplication

OsApplicationHooks

OsApplicationTrustedFunction

OsAppMode

OsCounter

OsEvent

OsDriver

OsHooks

OsIsr

OsIsrResourceLock

OsIsrTimingProtection

OsOS

OsPeripheralArea

OsResource

OsScheduleTable

OsScheduleTableAutostart

OsScheduleTableEventSetting

OsScheduleTableExpiryPoint

OsScheduleTableTaskActivation

OsScheduleTblAdjustableExpPoint

OsScheduleTableSync

OsSpinlock

OsTask

OsTaskAutostart

OsTaskResourceLock

OsTaskTimingProtection

OsTimeConstant

Containers and configuration parameter extensions of the IOC

This section describes the content of the IOC Configuration Description that is needed for the generation of the IOC API.

OsIoc

OsIocCommunication

OsIocSenderProperties

OsIocReceiverProperties

OsIocDataProperties

Containers and configuration parameters for ARTI

This section describes the structure (containers) and the parameters of ARTI objects related to the OS configuration. ARTI objects are defined by the MOD_ARTI model.

For a detailed description of the referenced ARTI parameters, please see chapter 10 of [9]. Also refer to application note 12.7 of this document.

ArtiHardware

<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>Vendor1ArtiHardware</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">
/AUTOSAR/Arti/ArtiHardware</DEFINITION-REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiCoreClass</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiHardware/ArtiHardwareCoreClass</DEFINITION-REF>
<...>
</ECUC-CONTAINER-VALUE>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiCore0</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiHardware/ArtiHardwareCoreInstance</DEFINITION-REF>
<...>
</ECUC-CONTAINER-VALUE>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiCore1</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiHardware/ArtiHardwareCoreInstance</DEFINITION-REF>
<...>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>

ArtiHardwareCoreClass

<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiCoreClass</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/
ArtiHardware/ArtiHardwareCoreClass</DEFINITION-REF>
<REFERENCE-VALUES>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiHardware/ArtiHardwareCoreClass/
ArtiHardwareCoreClassCurrentApplicationRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiObjectClassParameter_ArtiHwCore_CurrentApplication
</VALUE-REF>
</ECUC-REFERENCE-VALUE>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiHardware/ArtiHardwareCoreClass/
ArtiHardwareCoreClassCurrentTaskRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiObjectClassParameter_ArtiHwCore_CurrentTask</VALUE-REF>
</ECUC-REFERENCE-VALUE>
</REFERENCE-VALUES>
</ECUC-CONTAINER-VALUE>

ArtiHardwareCoreInstance

<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiCore0</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/
ArtiHardware/ArtiHardwareCoreInstance</DEFINITION-REF>
<REFERENCE-VALUES>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiHardware/ArtiHardwareCoreInstance/
ArtiHardwareCoreInstanceCurrentApplicationRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiObjectInstanceParameter_CurrentApplicationOnCore0
</VALUE-REF>
</ECUC-REFERENCE-VALUE>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiHardware/ArtiHardwareCoreInstance/
ArtiHardwareInstanceCurrentTaskRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiObjectInstanceParameter_CurrentTaskOnCore0</VALUE-REF>
</ECUC-REFERENCE-VALUE>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiHardware/ArtiHardwareCoreInstance/
ArtiHardwareCoreInstanceEcucCoreRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">
/Vendor1/Vendor1EcucEcuC/Hardware/Core0</VALUE-REF>
</ECUC-REFERENCE-VALUE>
</REFERENCE-VALUES>
</ECUC-CONTAINER-VALUE>

ArtiOs

<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>Vendor1ArtiOs</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">
/AUTOSAR/Arti/ArtiOs</DEFINITION-REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsClass_Conf</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiOs/ArtiOsClass</DEFINITION-REF>
<...>
</ECUC-CONTAINER-VALUE>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsInstance_Conf</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiOs/ArtiOsInstance</DEFINITION-REF>
<...>
</ECUC-CONTAINER-VALUE>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsTaskClass_Conf</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiOs/ArtiOsTaskClass</DEFINITION-REF>
</ECUC-CONTAINER-VALUE>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsTaskInstance_TaskHighPriority</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiOs/ArtiOsTaskInstance</DEFINITION-REF>
<...>
</ECUC-CONTAINER-VALUE>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsTaskInstance_TaskLowPriority</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">
/AUTOSAR/Arti/ArtiOs/ArtiOsTaskInstance</DEFINITION-REF>
<...>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>

ArtiOsAlarmClass

ArtiOsAlarmInstance

ArtiOsClass

<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsClass_Conf</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsClass</DEFINITION-REF>
<REFERENCE-VALUES>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsClass/ArtiOsClassAppModeRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiObjectClassParameter_ArtiOs_OsAppMode</VALUE-REF>
</ECUC-REFERENCE-VALUE>
</REFERENCE-VALUES>
</ECUC-CONTAINER-VALUE>

ArtiOsContextClass

ArtiOsContextInstance

ArtiOsInstance

<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsInstance_Conf</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsInstance</DEFINITION-REF>
<REFERENCE-VALUES>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsInstance/ArtiOsInstanceAppModeRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiObjectInstanceParameter_OsAppMode</VALUE-REF>
</ECUC-REFERENCE-VALUE>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsInstance/ArtiOsInstanceEcucRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1EcucOs/
Vendor1Os</VALUE-REF>
</ECUC-REFERENCE-VALUE>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsInstance/ArtiOsInstanceHookRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiHook_ArtiOs_TaskStart</VALUE-REF>
</ECUC-REFERENCE-VALUE>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsInstance/ArtiOsInstanceHookRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1Arti/
ArtiHook_ArtiOs_TaskStop</VALUE-REF>
</ECUC-REFERENCE-VALUE>
</REFERENCE-VALUES>
</ECUC-CONTAINER-VALUE>

ArtiOsIsrClass

ArtiOsIsrInstance

ArtiOsMessageContainerClass

ArtiOsMessageContainerInstance

ArtiOsResourceClass

ArtiOsResourceInstance

ArtiOsStackClass

ArtiOsStackInstance

ArtiOsTaskClass

<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsTaskClass_Conf</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsTaskClass</DEFINITION-REF>
<REFERENCE-VALUES>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsTaskClass/
ArtiOsTaskClassGenericComponentRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1ArtiGeneric/
ArtiGenericComponentClass_Vendor1Task</VALUE-REF>
</ECUC-REFERENCE-VALUE>
</REFERENCE-VALUES>
</ECUC-CONTAINER-VALUE>

ArtiOsTaskInstance

<ECUC-CONTAINER-VALUE>
<SHORT-NAME>ArtiOsTaskInstance_TaskHighPriority</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsTaskInstance</DEFINITION-REF>
<REFERENCE-VALUES>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsTaskInstance/
ArtiOsTaskInstanceGenericComponentRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1ArtiGeneric/
ArtiGenericComponentInstance_TaskHighPriority</VALUE-REF>
</ECUC-REFERENCE-VALUE>
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/Arti/
ArtiOs/ArtiOsTaskInstance/
ArtiOsTaskInstanceEcucRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/Vendor1/Vendor1EcucOs/
TaskHighPriority</VALUE-REF>
</ECUC-REFERENCE-VALUE>
</REFERENCE-VALUES>
</ECUC-CONTAINER-VALUE>

Published Information

For details refer to the chapter 10.3 “Published Information” in [4].

Generation of the OS

Read in configuration

[SWS_Os_00172]

[ ]

The generator shall provide the user the ability of reading the information of a selectable configuration file.

Consistency check

The conistency check can issue warnings or errors. Warnings mean that the generation is completed successfully, only indicating a not advisable configuration. Errors mean that the generation is not performed.

[SWS_Os_00173]

[ ]

The generator shall provide the user the ability of performing a consistency check of the current configuration.

[SWS_Os_00050]

[ ]

If service protection is required and OsStatus is not equal to EXTENDED (all the associated error handling is provided), the consistency check shall issue an error.

[SWS_Os_00045]

[ ]

If timing protection is configured together with OSEK OS Category 1 interrupts, the consistency check shall issue a warning.

[SWS_Os_00562]

[ ]

If timing protection is configured together with OsPreTaskHook or OsPostTaskHook the consistency check shall issue a warning.

[SWS_Os_00320]

[ ]

If configured attributes do not match the configured scalability class (e.g. defining an execution time budget in Tasks or Category 2 ISRs and selected scalability class is 1) the consistency check shall issue a warning.

[SWS_Os_00311]

[ ]

If OsScalabilityClass is SC3 or SC4, or system is Multi-Core, AND a Task OR Category 2 ISR OR Counters OR Alarms OR ScheduleTables does not belong to exactly one OS-Application the consistency check shall issue an error.

[SWS_Os_00361]

[ ]

If OsScalabilityClass is SC3 or SC4, or system is Multi-Core, AND a Category 1 ISR does not belong to exactly one trusted OS-Application the consistency check shall issue an error.

[SWS_Os_00177]

[ ]

If OsScalabilityClass is SC3 or SC4, or system is Multi-Core, AND an interrupt source that is used by the OS is assigned to an OS-Application, the consistency check shall issue an error.

[SWS_Os_00303]

[ ]

If OsAlarmIncrementCounter is configured as action on alarm expiry AND the alarm is driven directly or indirectly (a cyclic chain of alarm actions with OsAlarmIncrementCounter) by that Counter, the consistency check shall issue a warning.

[SWS_Os_00328]

[ ]

If OsStatus is STANDARD and OsScalabilityClass is SC3 or SC4 the consistency check shall issue an error.

[SWS_Os_00343]

[ ]

If OsScalabilityClass is SC3 or SC4, or system is Multi-Core, AND a Task is referenced within a ScheduleTable object AND the OS-Application of the ScheduleTable has no access to the Task, the consistency check shall issue an error.

[SWS_Os_00344]

[ ]

If OsScalabilityClass is SC3 or SC4, or system is Multi-Core, AND a Task is referenced within an alarm object AND the OS-Application of the alarm has no access to the Task, the consistency check shall issue an error.

[SWS_Os_00440]

[ ]

If a ScheduleTable has OsScheduleTblSyncStrategy = IMPLICIT and the OsCounterMaxAllowedValue+1 of the associated Counter is not equal to the duration of the ScheduleTable then the consitency check shall issue an error.

[SWS_Os_00461]

[ ]

If OsScalabilityClass is SC2, SC3 or SC4 AND Alarm Callbacks are configured the conistency check shall isuue an error.

[SWS_Os_00850]

[ ]

If OsUseResScheduler is TRUE AND the configuration contains a resource called RES_SCHEDULER, the generation tool shall ignore the configured RES_SCHEDULER.

Generating operating system

[SWS_Os_00179]

[ ]

If the consistency check of the read-in configuration file has not run free of errors, the generator shall not generate/configure the operating system.

[SWS_Os_00336]

[SRS_Os_11019]

The generator shall generate a relocatable memory section containing the interrupt vector table.

[SWS_Os_00370]

[SRS_Frt_00022]

The generator shall print out information about timers used internally by the OS during generation (e.g. on console, list file).

[SWS_Os_00393]

[SRS_Frt_00047]

The generator shall create conversation macros to convert counter ticks (given as argument) into real time. The format of the macro is OS_TICKS2 <Unit>_<Counter>(ticks) whereas <Unit> is one of NS (nanoseconds), US (microseconds), MS (milliseconds) or SEC (seconds) and <Counter> is the name of the Counter; E.g. OS_TICKS2MS_MyCounter()).

[SWS_Os_00815]

[SRS_BSW_00351]

The OS code shall wrap each declaration of Task, ISR, trusted functions, alarm callbacks and hook functions with the Memory Mapping Allocation Keywords macros.

#define OS_START_SEC_<sadm>
#include "Os_MemMap.h"

<Task, ISR, trusted functions or hook functions declaration>

#define OS_STOP_SEC_<sadm>
#include "Os_MemMap.h"

where <sadm> is the shortName of the SwAddrMethod if configured (e.g. in OsMemoryMappingCodeLocationRef).

Application Notes

Hooks

In OSEK OS, PreTask & PostTask Hooks run at the level of the OS with unrestricted access rights and therefore must be trusted. It is strongly recommended that these hook routines are only used during debugging and are not used in a final product.

When an OS-Application is killed the shutdown and startup hooks of the OS-Application are not called. Cleanup of OS-Application specific data can be done in the restart Task.

All application-specific hook functions (startup, shutdown and error) must return (blocking or endless loops are not acceptable).

Providing Trusted Functions

Address checking shall be done before data is accessed. Special care must be taken if parameters passed by reference point to the stack space of a Task or interrupt, because this address space might no longer belong to the Task or interrupt when the address is used.

The following code fragment shows an example how a trusted function is called and how the checks should be done.

struct parameter_struct 
{
    type1 name1, 
    type2 name2, 
    StatusType return_value
};

/* This service is called by the user and uses a trusted function */
StatusType system_service( type1 parameter1, type2 parameter2)
{
    /* store parameters in a structure (parameter1 and parameter2) */
    struct parameter_struct local_struct;

    local_struct.name1 = parameter1;
    local_struct.name2 = parameter2;

    /* call CallTrustedFunction with appropriate index and pointer to structure */
    if (CallTrustedFunction(SYSTEM_SERVICE_INDEX, &local_struct) != E_OK)
        return (FUNCTION_DOES_NOT_EXIST);

    return (local_struct.return_value);
}

/* The CallTrustedFunction() service switches to the privileged mode. Note that the 
   example is only a fragment! */
StatusType CallTrustedFunction( TrustedFunctionIndexType ix, TrustedFunctionParameterRefType ref)
{
    /* check for legal service index and return error if necessary */
    if (ix > MAX_SYSTEM_SERVICE)
        return (E_OS_SERVICEID);

    /* some implementation specific magic happens: the processor is set to privileged mode indirectly 
       call target function based on the index */
    (*(system-service_list[ix]))(ix, ref);

    /* some implementation specific magic happens: the processor is set to non-privileged mode */
    return (E_OK);
}

/* This part of the system service is called by CallTrustedFunction() */
void TRUSTED_system_service_part2 (TrustedFunctionIndexType a, parameter_struct *local_struct)
{
    TaskRefType task;
    type1 parameter1;
    type2 parameter2;

    if (GetTaskID(&task) != E_OK)
        task = INVALID_TASK;

    /* get parameters out of the structure (parameter1 and parameter2) */
    parameter1 = local_struct.name1;
    parameter2 = local_struct.name2;

    /* check the parameters if necessary */
    /* example is for parameter1 being an address and parameter2 being a size */
    /* example only for system_service called from tasks */
    if (GetISRID()!=INVALID_ISR)
    {
        /* error: not callable from ISR */
        local_struct.return_value = E_OS_ACCESS;
    }
    else if (OSMEMORY_IS_WRITEABLE(CheckTaskMemoryAccess(task,parameter1, parameter2)))
    {
        /* system_service_part3() is now the function as it would be if directly called 
           in a non-protected environment */
        local_struct.return_value = system_service_part3(parameter1, parameter2);
    }
    else
    {
        /* error handling */
        local_struct.return_value = E_OS_ACCESS;
    }
}

Note:

Since the service of CallTrustedFunction is very generic, it is needed to define a stub-interface which does the packing and unpacking of the arguments (as the example show). Depending on the implementation the stub interface may be (partly) generated by the generation tool.

Software Components and OS-Applications

Trusted OS-Applications can be permitted access to IO space. As software components can not be allowed direct access to the hardware, software components can not be trusted OS-Applications because this would violate this protection feature. The configuration process must ensure that this is the case.

The AUTOSAR Virtual Function Bus (VFB) specification places no restrictions on how runnables from software components are mapped to OS Tasks. However, the protection mechanisms in AUTOSAR OS apply only to OS managed objects. This means that all runnables in a Task:

Are not protected from each other at runtime

Share the same protection boundary

If runnables need to be protected they must therefore be allocated to different Tasks and those Tasks protected accordingly.

A simple rule can suffice:

"When allocating runnables to Tasks, only allocate runnables from the same software component into the same Task."

If multiple software components from the same application are to reside on the same processor, then, assuming protection is required between applications (or parts thereof) on the same processor, this rule could be modified to relax the scope of protection to the application:

"When allocating runnables to Tasks, only allocate runnables from the same application into the same Task."

If an OS-Application is killed and the restart Task is activated it can not assume that the startup of the OS-Application has finished. Maybe the fault happened in the application startup hook and no Task of the application was started so far.

Global Time Synchronization

The OS currently assumes that the global time synchronization is done by the user (unless implicit synchronization is used). This allows maximum flexibility regarding the time source. For synchronization with e.g. FlexRay some glue code may be necessary which transfer the information from the time source to the OS.

Working with FlexRay

ScheduleTables in the AUTOSAR OS may be synchronized with a global (network) time provided by FlexRay in essentially two ways:

Using the FlexRay interface's services for controlling timer interrupts related to global time to provide a "hardware" counter tick source to drive the processing of a ScheduleTable (implicit synchronization)

Using the FlexRay interface's service for accessing the current global time and passing this into the OS through the SyncScheduleTable OS service call

This section looks at the second option only.

In FlexRay time is presented as a tuple of a Cycle and a MacrotickOffset within the cycle. Cycle is an 8-bit value and MacrotickOffset is a 16-bit value.

In AUTOSAR OS a ScheduleTable is associated with an underlying Counter that has a notion of ticks. It is therefore possible to synchronize with either the Cycle or the tuple of Cycle/MacrotickOffset to give the resolution of synchronization required by the application.

If Cycle only resolution is required then an OS Counter object should be configured to have a OsCounterMaxAllowedValue equal to the maximum number of Cycles. If Cycle/MacrotickOffset is required then an OS Counter object should be configured with a OsCounterMaxAllowedValue of the maximum number of Cycles multiplied by the MacrotickOffset. This provides the OS with a time base against which a ScheduleTable can be synchronized.

Synchronization between the OS and an external global time source is provided by telling the OS the global time through the SyncScheduleTable service call. This call takes a scalar parameter of TickType so to interface this to FlexRay's representation of time a small conversion needs to be done. The following example assumes a Cycle of 255 with 65535 Macroticks per Cycle. TickType is at least 24-bits wide.

#define OSTIME(x) (TickType)(x);

FrIf_GetGlobalTime(Controller, &Cycle, &Macrotick);

SyncScheduleTable(Tbl, ((OSTIME(Cycle) << 16) + (OSTIME(Macrotick))));

Telling the ScheduleTable that GlobalTime can be done when the application detects that the FlexRay controller has lost synchronization with the network (by polling the controller sync status). The following code indicates how this can be used to force an associated ScheduleTable into the SCHEDULETABLE_RUNNING state from the SCHEDULETABLE_RUNNING_AND_SYNCHRONOUS state.

Fr_SyncStateType CurrentSyncStatus;

if (FrIf_GetSyncState(Controller, &CurrentSyncStatus) == E_OK) 
{
    if (CurrentSyncStatus == FR_ASYNC) 
    {
        SetScheduleTableAsync(Table);
    }
}

Of course, other actions are possible here, like stopping the ScheduleTable, as best fits user requirements.

Migration from OIL to XML

This version of the AUTOSAR OS specification does not directly support the configuration via OIL. The support for OIL was dropped in favour of XML because XML is the standard configuration language in AUTOSAR and is essential if configuration data has to be imported / exported from / to other AUTOSAR modules or between different tools during development.

Since OIL and XML are both ASCII formats a tool vendor may offer a possibility to import (old) OIL files and to store them as (AUTOSAR OS) XML files. Currently all known vendors support at least the import of existing OIL configurations.

Note that for showing conformance to the OSEK OS specification, each OSEK OS vendor must support OIL. This means that practically each AUTOSAR OS vendor will offer some sort of import of OIL configurations - at least to show the OSEK OS conformance.

Debug support

For the AUTOSAR OS the following information may be useful for users and should be considert for debug support (and may be published, e.g. in the BSWMD):

General information about how to retrieve the current (active) Task or ISR and their (current) priority and (current) stack.

For ISRs: Information about the name of interrupts, their mapping to the ISR identifier, the associated hardware and the used stack(s).

For Tasks: Information about the name of the Task, its identifier, the task state, the possible priorities, the event mask (if its an extended Task), the OSApplication to whom the Task belongs (if existant) and the used stack.

For Resources: Information about the name of the Resource, its mapping to the identifier, its priority and the current owner (the Task/ISR which currently holds the Resource)

For Alarms: Information about the name of the Alarm, its mapping to the identifier, the Counter to whom it belong, the action which is executed on expiry and the current state (running or stopped). In running state the next expiry in ticks and the possible cycle time shall be also published.

For Counters: Information about the name of the Counter, its mapping to the identifier, its associated alarms and the current counter value.

For SchduleTables: Information about the name of the ScheduleTable, its mapping to the identifier, its current state and the next expiry point (if the table is running).

For OS-Applications: Information about the name of the OS-Application, its mapping to the identifier, its current state and the memory sections assigned to it (if memory protection is used).

ARTI implements mechanisms to retrieve the described information (see [9]).

User documentation should contain information about the implemeted debug features.

Integration hints for peripheral protection

Peripheral protection requires configuration on the core level usually conditioned by a supervisor access. For this reason the task of the peripheral protection is assigned to the OS module.

Peripheral protection may be implemented in two ways

using MPU

using dedicated peripheral protection units of the target MCU.

When using the memory protection unit, it is reasonable if two or more protected region descriptors are available for peripheral protection mechanism. The region descriptors shall be programmed to allow access to those peripherals the current OS-Application shall work with. The defined regions shall cover all memory mapped configuration registers for the periphiherals to be protected. The advantage of using the MPU is that the configuration is the same as for memory protection. One of the disadvantages of this method is that it could be impossilbe to cover all peripheral control registers with available MPU region descriptors. The number of such descriptors is typically low.

Beware that using this method may have implication to the linker file of the project software configuration.

Second method is using a dedicated register protection schema. This method shall allow to precisely select peripherals for every OS Application. However the number of peripherals may make the register protection implementation rather bulky. Therefore it is advisable to reduce the number of protected peripherals to a reasonable value.

For both methods the configuration shall be placed into custom OS Application properties. The configuration shall be active when a Task (or ISR) of a particular OS Application is running.

Termination of OS-Applications

Inconsistencies may occur when an OsApplication is terminated and restarted, depending on its state at the termination.

A notification from an asynchronous job started before the termination of OsApplication can occur after the restart of OsApplication.

An asynchronous memory read or write started before the termination of OsApplication can occur after restart, and cause data inconsistency.

A requested mode or state to another OsApplication (e.g. from a SW-C to A BSW) can lead to unsynchronized state machines after an OsApplication restart.

Therefore some measures shall be taken to avoid these inconsistencies and guaranty a correct behavior.

Integration code shall stop all signals and signalgroups during its OsApplication restart. This ensures that no late asynchronous notification will occur after the OsApplication restart. These signals and signalgroups can be then safely restarted if needed.

A SW-C shall cancel jobs on all its memory blocks with a call to NvM_CancelJobs during the restart of its OsApplication. As the job might have already been started, the call to NvM_CancelJobs can return an error; in that case, the OsApplication shall wait until end of the job to continue. After all jobs are ensured to be cancelled, then all memory blocks shall be reset to their initial value, in order to avoid inconsistency of data which might have been written before the cancellation.

Any SW-C having responsible for requesting mode or state to BSW mode managers shall always request a default mode upon a restart of its OsApplication. Thus the BSW mode manager would not be stuck into a mode previously requested by the OsApplication before its termination. To support this task, note that RTE offers mechanisms to handle partition stop and restart wrt. mode machines. For mode managers an "error mode" to be set by RTE can be identified. For mode user partition the behaviour can also be selected. Furthermore an interaction to BswM to trigger an action list in case of partition restart can be initiated. Refer to RTE specification for details.

As a global hint, in any non-trusted OsApplication, which could be terminated, there shall always be a restart Task which does the following actions:

Cancel all jobs which can result in an asynchronous notification or shared memory, I/O access.

Reset all shared memory with a default value.

Reset any mode or state residing in another OsApplication and controlled by this given OsApplication to a default value.

Please note that some of these actions need to be performed even if an OS-Application is merely terminated and not restarted. For example, it may still be necessary to stop all signals and signal groups used by the OsApplication. Otherwise, it may happen that a bus never goes to sleep.

Consequently, in such a case it is necessary to activate the restart Task to perform the necessary cleanup even if the OS-Application is only terminated and not restarted. Calling TerminateApplication(<ownappid>,NO_RESTART) in the restart Task will finally set the OS-Application to APPLICATION_TERMINATED.

AUTOSAR Service implemented by the OS

Scope of this Chapter

This chapter is an addition to the specification of the Operating System. Whereas the other parts of the specification define the behavior and the C-interfaces of the OS module, this chapter formally specifies the corresponding AUTOSAR Service in terms of the SWC Template. The interfaces described here will be visible on the VFB and are used by the RTE generator to create the glue code between the application software (SWC) and the OS.

Package

The following definitions are interpreted to be in

ARPackage AUTOSAR/Services/Os

Overview

The AUTOSAR Operating System is normally not used directly by SWCs. Even the other BSW modules which are below the RTE are using the BSW Scheduler to have access to OS services. The BSW Scheduler of course uses the OS to implement its features, e.g. critical sections.

Nevertheless there is one case where it makes sense to allow SWCs access to services of the OS:

Timer services

Since the number of timers in an ECU is limited it make sense to share these units across several SWCs. The functionality of the timer services of the OS which are offered to the SWCs are:

A service to get the current value of a - hardware or software - Counter

A service which calculates the time difference between the current timer value and a given (previouls read) timer value

Both services will return real time values instead of ticks. This limits the access to the services to those counters which are counting time. Other counters e.g. counting errors or angles are not accessible.

Specification of the Ports and Port Interfaces

The detailed port interface can be found in chapter 8.8.

The notation of possible error codes resulting from server calls follows the approach in the meta-model. It is a matter of the RTE specification [10], how those error codes will be passed via the actual API.

Outlook on Memory Protection Configuration

As stated before, memory protection configuration is not standardized yet. Nevertheless it seems helpful to contribute a recommendation in this chapter, how the configuration might work.

Configuration Approach

Both, SW-Components and BSW modules, map code and variables to dedicated, disjoined memory sections (see meta-class ObjectFileSection in chapter 7.3 of Software Component Template [[11]], Version 2.0.1, and module specific sections in chapter 8.2 of Specification of Memory Mapping [[12]], Version 1.0.1).

This essential precondition (avoid an inseparable conglomeration of variables in the default section) can be used to support configuration of memory protection domains:

The generator can save for each OS-Application a (processor-specific) maximum number of output sections for data in a file (to be used in the linker file).

The generator can uniquely identify the address spaces of the data output sections with symbols using the naming convention (see memory allocation keywords _STOP_SEC_VAR and _START_SEC_VAR for start and stop symbols) in the specification mentioned above.

The input data sections in the object files of an OS-Application can then be assigned to the output sections (with potential tool support). Usually, this is one segment for global data, and one segment for code.

To archieve portability, the user shall group all variables belonging to a private data section (Task/ISR or OS-Application) in separate files.

A Not applicable requirements

[SWS_Os_NA_00767]

[SRS_BSW_00344]

[SRS_BSW_00404]

[SRS_BSW_00405]

[SRS_BSW_00170]

[SRS_BSW_00419]

[SRS_BSW_00383]

[SRS_BSW_00384]

[SRS_BSW_00375]

[SRS_BSW_00406]

[SRS_BSW_00168]

[SRS_BSW_00407]

[SRS_BSW_00423]

[SRS_BSW_00337]

[SRS_BSW_00369]

[SRS_BSW_00339]

[SRS_BSW_00422]

[SRS_BSW_00417]

[SRS_BSW_00409]

[SRS_BSW_00385]

[SRS_BSW_00386]

[SRS_BSW_00437]

[SRS_BSW_00161]

[SRS_BSW_00162]

[SRS_BSW_00415]

[SRS_BSW_00325]

[SRS_BSW_00342]

[SRS_BSW_00007]

[SRS_BSW_00413]

[SRS_BSW_00347]

[SRS_BSW_00441]

[SRS_BSW_00305]

[SRS_BSW_00307]

[SRS_BSW_00310]

[SRS_BSW_00373]

[SRS_BSW_00327]

[SRS_BSW_00335]

[SRS_BSW_00350]

[SRS_BSW_00410]

[SRS_BSW_00411]

[SRS_BSW_00314]

[SRS_BSW_00301]

[SRS_BSW_00302]

[SRS_BSW_00328]

[SRS_BSW_00312]

[SRS_BSW_00006]

[SRS_BSW_00439]

[SRS_BSW_00357]

[SRS_BSW_00377]

[SRS_BSW_00378]

[SRS_BSW_00306]

[SRS_BSW_00308]

[SRS_BSW_00309]

[SRS_BSW_00358]

[SRS_BSW_00414]

[SRS_BSW_00440]

[SRS_BSW_00330]

[SRS_BSW_00009]

[SRS_BSW_00401]

[SRS_BSW_00172]

[SRS_BSW_00010]

[SRS_BSW_00333]

[SRS_BSW_00374]

[SRS_BSW_00379]

[SRS_BSW_00003]

[SRS_BSW_00318]

[SRS_BSW_00321]

[SRS_BSW_00334]

[SRS_BSW_00005]

[SRS_BSW_00331]

[SRS_BSW_00343]

[SRS_BSW_00388]

[SRS_BSW_00389]

[SRS_BSW_00390]

[SRS_BSW_00392]

[SRS_BSW_00393]

[SRS_BSW_00394]

[SRS_BSW_00395]

[SRS_BSW_00396]

[SRS_BSW_00399]

[SRS_BSW_00403]

[SRS_BSW_00416]

[SRS_BSW_00425]

[SRS_BSW_00432]

[SRS_BSW_00448]

[SRS_BSW_00449]

[SRS_BSW_00452]

[SRS_BSW_00453]

[SRS_BSW_00454]

[SRS_BSW_00456]

[SRS_BSW_00457]

[SRS_BSW_00458]

[SRS_BSW_00461]

[SRS_BSW_00462]

[SRS_BSW_00466]

[SRS_BSW_00469]

[SRS_BSW_00470]

[SRS_BSW_00471]

[SRS_BSW_00472]

[SRS_BSW_00473]

[SRS_BSW_00478]

[SRS_BSW_00479]

[SRS_BSW_00481]

[SRS_BSW_00482]

[SRS_BSW_00483]

[SRS_BSW_00484]

[SRS_BSW_00485]

[SRS_BSW_00486]

[SRS_BSW_00487]

[SRS_BSW_00490]

[SRS_BSW_00492]

[SRS_BSW_00494]

[SRS_Frt_00032]

These requirements are not applicable to this specification.

AUTOSAR_SWS_OS

Specification of Operating System

简介和功能概述

首字母缩略词、缩写和词汇表

术语表

相关文档

输入文件、相关标准及规范

相关规范

约束和假设

现有标准

术语

与 RTE 的交互

操作系统抽象层 (OSAL)

多核硬件假设

CPU 核心特性

内存功能

多核的限制

限制

硬件

编程语言

杂项

对于汽车领域的适用性

对其他模块的依赖

文件结构

代码文件结构

头文件结构

ARTI 文件结构

需求可追溯性

功能定义

操作系统（OS）

背景与理由

需求

[SWS_Os_00001]

OSEK/VDX 操作系统（OS）的限制

[SWS_Os_00242]

OSEK/VDX 操作系统（OS）中未被定义的行为

[SWS_Os_00304]

[SWS_Os_00424]

[SWS_Os_00425]

对 OSEK/VDX 操作系统（OS）的扩展

[SWS_Os_00299]

[SWS_Os_00301]

[SWS_Os_00476]

[SWS_Os_00566]

自由运行软件定时器

[SWS_Os_00374]

[SWS_Os_00384]

调度表

背景与理由

需求

调度表的结构

[SWS_Os_00401]

[SWS_Os_00402]

[SWS_Os_00403]

[SWS_Os_00404]

到期时间点的限制

[SWS_Os_00407]

[SWS_Os_00442]

[SWS_Os_00443]

[SWS_Os_00408]

对调度表的处理

[SWS_Os_00002]

[SWS_Os_00007]

[SWS_Os_00409]

[SWS_Os_00410]

[SWS_Os_00411]

[SWS_Os_00412]

重复地进行对调度表的处理

[SWS_Os_00413]

[SWS_Os_00009]

[SWS_Os_00427]

[SWS_Os_00444]

[SWS_Os_00194]

关于对调度表的处理的控制

[SWS_Os_00428]

[SWS_Os_00414]

[SWS_Os_00510]

对调度表的同步

背景与理由

需求