AUTOSAR OS 软件需求 AUTOSAR_CP_SRS_OS 翻译

本文介绍AUTOSAR OS 需求，转载自：AUTOSAR 标准

1 文档所涵盖的内容

该文档的目标是定义AUTOSAR操作系统的高级要求。

2 如何阅读本文件

2.1 需遵循的约定
AUTOSAR CP R23-11文档需求表示，遵循[TPS_STDT_00078]中指定的表格格式（见标准化模板[1]）。
在要求中，应使用以下（基于互联网工程任务组（IETF）的）特定语义。

本文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”的解释如下：”

应该 “SHALL”：这个词意味着定义是规范中的绝对要求。
不应该 “SHALL NOT”：这个短语意味着定义是规范中的绝对禁止。
必须 “MUST”：这个词意味着由于法律原因，定义是规范中的绝对要求。
绝不 “MUST NOT”：这个短语意味着由于法律约束，定义是规范中的绝对禁止。
可以 “SHOULD”：这个词或形容词“RECOMMENDED”意味着，在特定情况下可能存在忽略特定项目的合理理由，但在选择不同方案之前，必须充分理解并仔细权衡所有影响。
不可以 “SHOULD NOT”：这个短语或短语“NOT RECOMMENDED”意味着，在特定情况下，特定行为可能是可接受的或甚至有用的，但在实施任何带有此标签的行为之前，应充分理解所有影响并仔细权衡情况。
可能 “MAY”：这个词或形容词“OPTIONAL”意味着某个项目是真正可选的。一个供应商可能选择包含该项目，因为特定市场需要它，或者因为供应商认为它增强了产品，而另一个供应商可能会省略相同的项目。不包含特定选项的实现，必须准备与包含该选项的另一实现进行互操作，尽管功能可能会减少。同样，包含特定选项的实现也必须准备与不包含该选项的另一实现进行互操作（当然，除了该选项提供的功能之外）。

2.2 缩写和首字母缩略词

3 需求规范指南
应引用现有规范（作为单一需求的形式），与这些规范的差异应作为附加需求进行说明。

3.1 需求质量
所有需求应具备以下特性：

• 无冗余性
需求在同一需求内或其他需求中不得重复。

• 明确性
所有需求只能有一种解释方式。只能使用术语表[3]中的技术术语。此外，需求中必须明确指出该声明是对哪个对象的要求。
示例：
– <…>模块应/应当/可以…
– <…>模块的环境应…
– <…>配置应…
– 功能<…>应…
– <…>软件工作说明书（SWS）应…
– 硬件应…

• 原子性
每个需求只能包含一个需求。如果需求不能再进一步拆分为其他需求，则该需求是原子的。

• 可测试性
需求应通过分析、审查或测试进行验证。

• 可追溯性
需求的来源和状态应始终可见。

• 表述方式
所有需求的表述方式，应确保其能够在没有上下文的情况下被准确解释（例如，使用“功能Xyz…”而不是“此功能…”）。

3.2 需求识别

每个需求都有一个以BSW为前缀的唯一标识符。在进行任何审查注释、备注和/或提问时，请引用此唯一标识符，而不是章节或页码！

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

因此，所有最终确定的需求都处于’批准’状态

4 需求规格说明

4.1 可追溯性

4.2 实时操作系统
4.2.1 功能描述

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

然而，在汽车系统中，对操作系统的要求具有高度领域特异性。例如，在车身、动力总成和底盘领域，重点是高效的任务和警报调度、共享资源处理以及截止时间监控。所使用的操作系统必须在运行时非常高效，且内存占用小。

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

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

4.2.2 核心操作系统要求

[SRS_Os_00097] 操作系统应提供一个API，该API向后兼容OSEK操作系统的API 「
」（RS_BRF_01200 ）

[SRS_Os_11001]操作系统应提供允许故障隔离和故障恢复功能的分区「

⌋(RS_BRF_01232, RS_BRF_01234)

[SRS_Os_11018]操作系统应提供中断屏蔽功能「
」（ RS_BRF_01096)

[SRS_Os_11019]AUTOSAR操作系统生成工具应生成中断向量表「
」（)

4.3 静态定义调度
4.3.1 功能概述

在许多应用中，有必要静态地定义一组互相关联的任务的激活。这可能是为了保证基于数据流的设计中的数据一致性，与时间触发网络同步，保证正确的相对运行时等。

时间触发（Time-TRIGGERED）操作系统通常被提议作为这个问题的解决方案。然而，时间只是一个事件，因此任何事件触发的操作系统，包括OSEK OS [4]，都可以在汽车电子控制单元中实现一个用于静态调度的实时软件的调度器。

对于调度表的要求，OSEK OS提供了一个对象，该对象可以以与OSEKtime分派表相同的方式进行操作。

4.3.2 要求

[SRS_Os_00098]操作系统应提供基于时间表的静态配置调度表，作为可选服务「
」（ RS_BRF_01208)

[SRS_Os_00099]操作系统应提供一种机制，允许在不同调度表之间进行切换「
⌋(RS_BRF_01208)

[SRS_Os_11002]操作系统应提供将调度表的处理与全局系统时间基准同步的能力「

⌋(RS_BRF_01216)

4.4 监控设施

4.4.1 功能概述

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

4.4.2 要求

[SRS_Os_11003]操作系统应能够监控堆栈使用情况，并针对每个可执行对象检查堆栈溢出情况。「

⌋(RS_BRF_01232)

4.5 保护设施

4.5.1 功能概述

AUTOSAR概念要求多个来源的操作系统-应用程序在同一处理器上共存。为了防止这些操作系统-应用程序之间发生意外的交互，必须提供保护机制，使它们相互隔离。这里有两个主要用例：
对于安全关键系统，如果可以将单个操作系统-应用程序的安全案例集成到总体安全案例中，那么开发总体安全案例将变得相当容易。这只有在可以证明至少一个操作系统-应用程序中的故障不会传播到其自身边界之外并导致另一个不相关的操作系统-应用程序出现故障时才可行。
供应商只能对其软件组件和/或基础软件模块承担责任（和一定的法律责任），前提是他们的软件不会被错误地归咎于处理器范围的故障。

通过向OSEK操作系统[4]添加保护机制，可以满足这两个用例的需求。以下部分将概述保护领域。

4.5.2 内存保护要求

[SRS_Os_11005]操作系统应防止一个操作系统-应用程序修改其他操作系统-应用程序的内存。「
⌋(RS_BRF_01232，RS_SAF_31201)

[SRS_Os_11006]操作系统应允许任务和ISR在操作系统-应用程序内部交换数据。「
⌋(RS_BRF_01240)

[SRS_Os_11007]操作系统应允许操作系统-应用程序执行共享代码。「
⌋(RS_BRF_01240)
[SRS_Os_11000]操作系统可能提供支持，以保护操作系统-应用程序的内存部分，防止所有其他操作系统-应用程序进行读取访问。「
⌋(RS_BRF_02008)

4.5.3 时续保护要求

[SRS_Os_11008]操作系统不应允许任何操作系统-应用程序中的时序故障传播「
⌋(RS_BRF_01224，RS_SAF_31202)
4.5.4 服务保护要求

操作系统必须在运行时维护其自身的完整性以及它所调度运行的操作系统-应用程序的完整性。

[SRS_Os_11009]操作系统应防止因任何系统服务的调用对自身系统造成的破坏。「
⌋(RS_BRF_01232)

[SRS_Os_11010]操作系统应防止操作系统-应用程序修改不属于该应用程序的操作系统对象。「
⌋(RS_BRF_01232)

[SRS_Os_11011]操作系统应防止操作系统-应用程序直接修改由操作系统管理的控制寄存器。「
⌋(RS_BRF_01232)
[SRS_Os_11012]操作系统应为其保护功能提供可扩展性。「
⌋(RS_BRF_01232)

4.5.5 保护错误

操作系统必须能够识别何时发生了违反保护机制的错误，并且必须提供设施以便采取行动来纠正故障。然而，定义错误处理机制并不是操作系统的任务。

[SRS_Os_11013]操作系统应能够在运行时通知保护错误的发生。「
⌋(RS_BRF_01232)

[SRS_Os_11014]在发生保护错误时，操作系统应提供恢复操作，涵盖了操作系统级、操作系统与应用程序交互级以及任务/ISR级。「
⌋(RS_BRF_01248)

4.6 定时器服务

4.6.1 功能概述

定时器服务提供了用于应用程序和基础软件的软件定时器。OSEK OS [4] 中的计数器和闹钟，已经提供了定时机制的核心功能。因此，以定时器服务的形式，引入一个几乎相同的机制是没必要的。

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

4.6.2 功能要求

[SRS_Os_11020]操作系统应提供一个标准接口来触发软件计数器。「
⌋()

[SRS_Os_11021]操作系统应提供一种机制，允许从单个硬件计数器级联多个软件计数器。「
⌋()

4.7 可拓展性

4.7.1 功能概述

对于一个特定的应用程序，操作系统可以被配置为仅包含该应用程序所需的服务。这样，操作系统的资源需求就可以尽可能地小。
核心操作系统的可扩展性由OSEK OS的[4]一致性类别提供。这里定义了与AUTOSAR操作系统功能相关的可扩展性。

4.7.2 功能要求
[SRS_Os_11016]操作系统的实现应提供可扩展性，这种可扩展性可以通过生成工具进行配置。「
⌋(RS_BRF_01232)

4.8 应用错误处理

4.8.1 功能概述

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

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

本节介绍了提供操作系统-应用程序的应用程序级和系统级控制框架的要求。

4.8.2 功能要求

[SRS_Os_11022]操作系统应提供终止操作系统-应用程序的机制。「
⌋(RS_BRF_01248)

[SRS_Os_11023]操作系统应提供一种机制，通过该机制可以重新启动已终止的操作系统-应用程序「
⌋(RS_BRF_01248)

4.9 多核通用问题

4.9.1 概述
本节中的要求非常通用，它们定义了将在AUTOSAR环境中支持的多核（MC）功能的核心理念。从架构的角度来看，多核硬件可以以各种不同的方式进行管理。在一种极端情况下，可以将核心视为几乎独立的ECU，而在另一种极端情况下，它们可以向用户呈现为几乎具有真正并行能力的单核系统。

在汽车系统中，对多核支持的要求非常具有领域特异性。高效的调度、低的资源消耗和短的响应时间至关重要。

这些要求的设计方式，使得多核的引入不会改变AUTOSAR的总体理念。

多核概念允许像处理单核系统一样，处理多核系统，但同时也提供了在这些概念之外使用核心的自由，例如作为专用的输入/输出（I/O）控制器。

4.9.2 功能要求

[SRS_Os_80001]操作系统应能够管理多个紧密耦合的CPU核心。「
⌋(RS_BRF_00206)

[SRS_Os_80003]多核扩展应提供与单核同等程度的可预测性。「
⌋(RS_BRF_00206)

4.9.3 术语“一个AUTOSAR系统控制多个核心”的附加描述

如[SRS_Os_80001]中所述的“一个AUTOSAR系统控制多个核心”这一术语的含义涉及多个方面，具体如下：
系统应意识到多核心的存在。
系统应负责在多核心上进行任务调度。
部分系统代码应能够并发运行（例如，使用可重入代码）
所有BSW ID（如任务、事件、报警等的ID）在多核心环境中应是唯一的。
除非受到保护机制的限制，否则应允许它从任何核心访问共享对象（例如数据、外围单元……）。

4.9.4 术语“无限阻塞”的附加描述

阻塞是指高优先级的运行时对象无法执行的情况，因为低优先级运行时对象阻止了这一点（例如，通过占用所需的资源）。

意外阻塞可能是由优先级反转引起的。

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

4.10 运行时对象到核心的分配

4.10.1 概述

在定义多核系统时，一个主要的问题是运行时对象（任务和ISR）是否能够在核心之间动态切换。

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

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

本节定义了要求，在多核AUTOSAR环境中将核心绑定指定为处理运行时对象的方式。

4.10.2 要求

[SRS_Os_80005]OsApplications以及由此产生的任务和OsISR，应静态分配给核心。「
⌋(RS_BRF_00206)

4.11 多核系统的启动

4.11.1 概述

本节包含一些关于启动的高级要求。

根据所使用的微控制器，微控制器的启动或复位行为可能有所不同。复位后最常见的行为如下：
只有所谓的主核开始执行，而所有其他核（从核）保持停止状态。从核需要由主核启动。
另一种可行的方法是所有核在复位后同时开始执行。在这种情况下，不存在主核。

不同的微控制器和微控制器衍生品的唤醒机制和引导要求各不相同。

不同核上的启动代码进度是不可重现的；这是因为加载和存储操作的时长取决于总线仲裁和硬件的其他非常敏感的时间效应。因此，必须设计启动代码，使其不依赖于对其他核上启动进度的了解。在启动期间，需要同步不同的核。

4.11.2 要求

[SRS_Os_80006]系统的初始化/重启应同步进行。「
⌋(RS_BRF_00206)

4.12 多核系统的关闭

4.12.1 概述

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

如果具有适当权限的运行时对象调用“ShutdownOS”，则整个系统（由MC-OS控制的所有核心）都必须关闭。一旦开始关闭程序，就无法激活有效任务。开发人员/系统集成商有责任在调用“ShutdownOS”之前，确保在应用程序和基础软件级别上完成所有关闭准备工作。

[SRS_Os_80007]关闭程序因由任何核心触发。「
⌋(RS_BRF_00206)

4.13 多核系统的配置

4.13.1 概述

本节包含有关系统配置在多核方面的高级要求。

4.13.2 要求

[SRS_Os_80008]它应是跨多个核心的通用操作系统配置。「

⌋(RS_BRF_00206)

[SRS_Os_80011]操作系统所管理的核心数量应该在离线状态下是可配置的。「

⌋(RS_BRF_00206)

[SRS_Os_80016]事件机制应跨核心运行。「

⌋(RS_BRF_00206)

[SRS_Os_80018]应提供同步多个核心上的任务的方法。「

⌋(RS_BRF_00206)

[SRS_Os_80020]应提供数据交换机制。「

⌋(RS_BRF_01240)

[SRS_Os_80021]AUTOSAR环境的多核扩展应支持核心之间的互斥机制，且该机制不应导致死锁。「

⌋(RS_BRF_01264)

[SRS_Os_80022]如果特定核心上没有任务要被调度，操作系统应执行用户可选择的操作。「

⌋(RS_BRF_01184)

[SRS_Os_80023]如果特定核心上没有任务要被调度，操作系统应执行一个在运行时可选的操作。「

⌋(RS_BRF_01184)

4.15 调试和追踪

4.15.1 ARTI支持

[SRS_Os_80023]操作系统应创建一个ARTI模块描述文件。「

⌋()

[SRS_Os_12003]ARTI模块描述文件应支持所有ORTI容器「

⌋(RS_Main_01025)

4.15.2 追踪支持

[SRS_Os_12002]操作系统代码应融入ARTI钩子「

⌋()