操作系统需求（Requirements on Operating System）

1 文档范围（Scope of this document）

本文档的目标是定义 AUTOSAR 操作系统的高层级需求。

2 如何阅读本文档（How to Read this Document）

2.1 使用的约定（Conventions to be used）

• AUTOSAR 文档中需求的表示遵循 [TPS_STDT_0078] 中指定的表格。
• 在需求中，应使用以下特定语义（基于 IETF）：

本文档中的关键字 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY 和 OPTIONAL 应按以下方式解释：

• SHALL（应当）：该定义是规范的绝对要求。
• SHALL NOT（不得）：该定义是规范的绝对禁止。
• MUST（必须）：该定义是规范的绝对要求（基于法律问题）。
• MUST NOT（禁止）：该定义是规范的绝对禁止（基于法律约束）。
• SHOULD（建议）：在特定情况下可能存在合理的理由忽略特定项，但在选择不同方案之前必须充分理解并谨慎权衡全部含义。
• SHOULD NOT（不建议）：在特定情况下该行为可能是可接受的甚至有用的，但在实现任何以此标签描述的行为之前，应充分理解其含义并谨慎权衡。
• MAY（可以）：该项是真正可选的。一个供应商可能选择包含该项，因为特定市场需要它或因为供应商认为它能增强产品，而另一个供应商可能省略相同的项。

不包含特定选项的实现应当准备好与包含该选项的另一实现互操作（尽管可能功能减少）。同样，包含特定选项的实现应当准备好与不包含该选项的另一实现互操作（当然，该选项提供的功能除外）。

2.2 缩略语与缩写（Acronyms and abbreviations）

3 需求指南（Requirements Guidelines）

应引用现有规范（以单个需求形式）。与这些规范的差异被指定为附加需求。

3.1 需求质量（Requirements quality）

所有需求应具有以下属性：

• 冗余性：需求不应在一个需求中或其他需求中重复
• 清晰性：所有需求应仅允许一种解释方式。仅可使用术语表中的技术术语。此外，必须从需求中清楚看出该声明是关于什么对象的需求。
• 原子性：每个需求应仅包含一个需求。如果需求不能拆分为进一步的需求，则它是原子的。
• 可测试性：需求应可通过分析、评审或测试进行测试。
• 可追溯性：在任何时候都应可见需求的来源和状态。
• 表述：所有需求的表述应使其可以在没有周围上下文的情况下进行解释（例如："函数 Xyz…" 而不是"该函数…"）。

3.2 需求标识（Requirements identification）

每个需求都有以 BSW（"Basic Software"，基础软件）作为前缀的唯一标识符。对于任何评审注释、意见或问题，请引用此唯一 ID 而非章节或页码！

3.3 需求状态（Requirements status）

此外，每个需求包含状态信息。状态可以是以下之一：

因此，所有完成的需求都处于"Approved"状态。

4 需求规范（Requirement Specification）

4.1 可追溯性（Traceability）

4.2 实时操作系统（Real-Time Operating System）

4.2.1 功能描述（Functional description）

嵌入式汽车 ECU 中的实时操作系统构成软件动态行为的基础。它管理任务和事件的调度、不同任务之间的数据流，并提供监控和错误处理功能。

然而，在汽车系统中，对操作系统的需求高度依赖于具体域。例如，在车身、动力总成和底盘域中，重点在于任务和报警的高效调度、共享资源的处理和截止时间监控。所使用的操作系统必须在运行时高效，内存占用小。

在多媒体和远程信息处理应用中，操作系统提供的功能集以及可用计算资源也有显著不同。除纯任务管理外，还包含复杂数据处理（例如流、闪存文件系统等）、内存管理，甚至图形用户界面。

汽车 OS 的经典域仅涵盖调度和同步的核心功能。在 AUTOSAR 架构中，上述附加功能不在 OS 的范围内。这些功能由其他 AUTOSAR 基础软件模块涵盖（例如 COM 提供通信抽象）。在 AUTOSAR 架构约束下，不可能将其他 OS（例如 QNX、VxWorks 和 Windows CE 等）的功能集集成到单一的 OS/通信/驱动结构中。因此，AUTOSAR OS 应当仅考虑核心功能。

4.2.2 核心 OS 需求（Core Operating System requirements）

4.3 静态定义调度（Statically Defined Scheduling）

4.3.1 功能概述

在许多应用中，必须静态定义彼此相关的一组任务的激活。这可能是为了保证数据流设计中的数据一致性、与时间触发网络同步、保证正确的运行时分段等。

时间触发的操作系统通常被提议作为此问题的解决方案。然而，时间只是一个事件，所以任何事件触发的 OS，包括 OSEK OS，都可以在汽车 ECU 中实现静态调度的实时软件调度器。

调度表的需求提供了一个 OSEK OS 对象，可以用与 OSEKtime 调度器表相同的方式操作。

4.3.2 需求

4.4 监控设施（Monitoring Facilities）

4.4.1 功能概述

监控功能在执行的适当阶段检测错误，而不是错误发生时立即检测。因此，任何监控功能都是运行时故障的检测，而不是故障的预防。

4.4.2 需求

4.5 保护设施（Protection Facilities）

4.5.1 功能概述

AUTOSAR 概念要求多源的 OS-Application 共存于同一处理器上。为了防止这些 OS-Application 之间的意外交互，必须提供保护机制使其相互隔离。主要有两种使用场景：

1. 对于安全关键系统，如果可以将各个 OS-Application 的安全论据集成为总体安全论据，则安全论据的开发将大大简化。只有当可以证明至少一个 OS-Application 中的故障不会传播超出其自身边界并导致另一个不相关 OS-Application 的故障时，这才是可行的。
2. 只有当可以确保他们的软件不会因处理器范围的故障而被错误地归咎时，供应商才会对他们的软件组件和/或基础软件模块承担责任（和一些责任）。

这两种使用场景可以通过向 OSEK OS 添加保护机制来满足。以下章节概述了保护领域。

4.5.2 内存保护需求（Memory Protection requirements）

4.5.3 时序保护需求（Timing Protection requirements）

4.5.4 服务保护需求（Service Protection requirements）

OS 必须在运行时保持其自身完整性和其调度的 OS-Application 的完整性。

4.5.5 保护错误（Protection Errors）

OS 必须能够识别何时发生了违反保护方案的错误，并且还必须提供可以采取行动来纠正故障的机制。然而，定义错误处理方案不是 OS 的任务。

4.6 定时器服务（Timer Services）

4.6.1 功能概述

定时器服务为应用和基础软件提供软件定时器。定时机制的核心已由 OSEK OS 中的计数器和报警提供。因此，以几乎相同的形式（定时器服务）引入新的机制是不必要的。

然而，为了提供通用软件定时，需要向 AUTOSAR OS 添加一些补充功能。这些在 SRS_Os_11020 和 SRS_Os_11021 中描述。

4.6.2 功能需求

4.7 可扩展性（Scalability）

4.7.1 功能概述

对于特定应用，操作系统可以配置为仅包含该应用所需的服务。因此，操作系统的资源需求尽可能小。

核心 OS 的可扩展性由 OSEK OS 的符合类提供。关于 AUTOSAR OS 功能的可扩展性在此处定义。

4.7.2 功能需求

4.8 应用错误处理（Application Error Handling）

4.8.1 功能概述

一些影响应用程序的错误可能不会导致 OS 可检测到的保护违规，但仍会导致应用程序进入无法自行恢复并继续执行的状态。检测此类错误是应用程序本身的责任，但从此类错误中恢复需要与 OS 管理的控制线程进行交互。因此，OS 需要提供应用程序可以构建内部恢复机制的机制。

核心 OSEK OS 提供了一些支持：任务可以检测内部错误并自行终止；系统可以使用报警机制来编程超时、实现基于阈值的错误检测；可以检测内部错误并可以关闭系统等。但是，核心 OS 不提供为 OS-Application 定义的逻辑应用程序实现错误恢复的方法（见 SRS_Os_11001）。

本节介绍提供应用级和系统级 OS-Application 控制框架的需求。

4.8.2 功能需求

4.9 通用多核问题（General Multi-Core issues）

4.9.1 概述

本节中的需求非常通用。它们定义了 AUTOSAR 环境将支持的多核（MC）能力的要点。从架构的角度来看，多核硬件可以以各种不同的方式管理。在一端，核可以被理解为几乎独立的 ECU；在另一端，它们可以作为几乎具有真正并行能力的单核（SC）系统呈现给用户。

在汽车系统中，对 MC 支持的需求非常依赖于具体域。高效调度、低资源消耗和短响应时间至关重要。

需求的设计方式是引入多核不会改变 AUTOSAR 的整体理念。

MC 概念允许像 SC 系统一样处理多个核，但给予在概念之外使用核的自由，例如作为专用 I/O 控制器。

4.9.2 功能需求

4.9.3 "一个 AUTOSAR 系统控制多个核" 术语的附加说明

当讨论控制多个核的 AUTOSAR 系统时（如 SRS_Os_80001），有几个含义：

• 系统应知道多个核的存在。
• 系统应负责在多个核上调度任务。
• 系统代码的部分应能够并发运行（例如通过使用可重入代码）。
• 所有 BSW ID（例如任务、事件、报警等的 ID）在核之间应唯一。
• 除非受保护机制限制，否则应允许从任何核访问共享对象（例如数据、外围单元等）。

4.9.4 "无界阻塞" 术语的附加说明

阻塞是高级运行时对象由于低级运行时对象阻止其执行（例如通过占用所需资源）而无法执行的情况。意外阻塞可能由优先级反转引起。

无界阻塞一词意味着潜在阻塞持续时间不受限制，因此无法保证所需的实时行为。

4.10 运行时对象到核的分配（Assignment of runtime objects to cores）

4.10.1 概述

在定义多核系统时，一个主要问题是运行时对象（任务和 ISR）是否可以在动态上在不同核之间更改。

动态地将运行时对象分配到不同核的能力将对系统的所有效率方面（代码大小/数据大小/速度/响应时间/实时能力）产生巨大影响。

可以将 OsApplications 绑定到核或在任务和 ISR 级别上定义核绑定。为了最小化 AUTOSAR 内多核支持的复杂性和影响，决定在 OsApplication 级别定义核绑定。

本节定义了将核绑定声明为在 MC AUTOSAR 环境中处理运行时对象的方式的需求。

4.10.2 需求

4.11 多核系统的启动（Startup of Multi-Core systems）

4.11.1 概述

本节包含关于启动的一些高层需求。根据使用的微控制器，微控制器的启动或复位行为可以有所不同。复位后最常见的行为如下：

• 只有所谓的主核开始执行，而所有其他核（从核）保持停止状态。从核需要由主核启动。
• 另一种可想象的方法是所有核在复位后并发开始执行。在这种情况下不存在主核。

唤醒机制和引导需求因微控制器和微控制器衍生品而异。

不同核上启动代码的进度不可重现；这是因为加载和存储操作的持续时间取决于总线仲裁和其他非常时间敏感的硬件效应。因此，引导代码必须以不依赖于其他核上引导进度的知识的方式设计。需要同步不同核在启动期间的状态。

4.11.2 需求

4.12 多核系统的关闭（Shutdown of Multi-Core systems）

4.12.1 概述

与启动类似，多核系统的关闭行为与单核系统的行为不同。

如果具有适当权限的运行时对象调用 "ShutdownOS"，则整个系统（MC-OS 控制的所有核）必须关闭。一旦启动关闭过程，validtasks 就不能被激活。确保在调用 "ShutdownOS" 之前完成应用和基础软件级别的任何关闭准备工作是开发者/系统集成商的责任。

4.12.2 需求

4.13 多核系统的配置（Configuration of Multi-Core systems）

4.13.1 概述

本节包含关于多核系统配置的高层需求。

4.13.2 需求

4.14 多核系统中的服务（Services in Multi-Core systems）

4.14.1 概述

以下章节定义了一组允许优化使用多核环境的机制/服务。这些服务可能由不同的 AUTOSAR BSW 模块提供。AUTOSAR_SWS_Multi-Core 定义了从哪个模块可以访问哪个服务。

4.14.2 需求

4.15 调试与跟踪（Debugging and Tracing）

4.15.1 ARTI 支持

4.15.2 跟踪支持（Tracing Support）

5 需求追溯（Requirements Tracing）

6 参考资料（References）

6.1 AUTOSAR 交付物（Deliverables of AUTOSAR）

• [AUTOSAR_GLOSSARY] 术语表，AUTOSAR_TR_Glossary.pdf
• [DOC_LAYERED_ARCH] 分层软件架构，AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
• [DOC_VFB] 虚拟功能总线，AUTOSAR_EXP_VFB.pdf
• [DOC_WP112_REQ] 基础软件模块通用需求，AUTOSAR_SRS_BSWGeneral.pdf
• [TPS_STDT_0078] 软件标准化模板，AUTOSAR_TPS_StandardizationTemplate.pdf

6.2 相关标准与规范（Related standards and norms）

6.2.1 OSEK

• [STD_OSEK_OS] ISO 17356-3: OS
• [STD_OSEK_OIL] ISO 17356-6: OIL

6.2.2 公司报告、学术著作等

• [REP_DC_PROTECTED_OS] OSEK OS 的扩展以支持受保护的应用，OSEK Support Project, DC058_02, Daimler-Chrysler AG