AUTOSAR 以及本文件的目标是定义 AUTOSAR 运行时环境（Run-time Environment, RTE）的需求与行为。RTE 的具体实现方式不在 AUTOSAR 考虑范围内；但所有需求与行为规范均经过内部审查，以确保至少存在一种可行实现。
+本 SRS 文档为 RTE 实施提供需求规约基础，下游的 AUTOSAR_SWS_RTE（软件规范）将以本 SRS 为基础定义具体实现 API、Generator 输入、配置参数等。
AUTOSAR 文档中需求的表示遵循 [TPS_STDT_00078] 中指定的表格格式（参见标准化模板 [1]，Support for Traceability 章节）。
+用以表达义务的措辞形式遵循 [TPS_STDT_00053]（参见标准化模板 [1]，Support for Traceability 章节）：
+运行时环境（Run-Time Environment, RTE）位于 AUTOSAR ECU 架构的核心。RTE 是 AUTOSAR 虚拟功能总线（Virtual Function Bus, VFB）针对特定 ECU 的具体实现，因此提供了应用软件组件间通信的基础设施服务，并促进对基础软件组件（包括 OS）的访问。
+应用软件组件包含与 CPU 和位置无关的系统软件。这意味着，在系统设计者施加的约束下，应用软件组件可在系统配置期间映射到任意可用 ECU。RTE 负责确保无论组件被映射到何处，组件均能通信且系统能按预期功能运行。
+RTE 既包含因组件到 ECU 的不同映射而产生的系统基础设施可变元素，也包含标准化的 RTE 服务。RTE 针对每个 ECU 生成和/或配置，以确保对 ECU 而言是最优的。
+ +下表引用 [2]（AUTOSAR_RS_StandardizationTemplate）中规约的需求，并链接到这些需求的实现（即本 SRS 中的 SRS_Rte_* 需求）。
+| 需求 | 描述 | 由（… 满足） |
|---|---|---|
[RS_BRF_00057] | AUTOSAR 应定义内存映射机制 | [SRS_Rte_00169]、[SRS_Rte_00170] |
[RS_BRF_01024] | AUTOSAR 应提供公共符号的命名规则 | [SRS_Rte_00164]、[SRS_Rte_00165]、[SRS_Rte_00166]、[SRS_Rte_00167]、[SRS_Rte_00168]、[SRS_Rte_00252] |
[RS_BRF_01136] | AUTOSAR 应支持系统启动后解析的 BSW 数据变体 | [SRS_Rte_00191]、[SRS_Rte_00201]、[SRS_Rte_00202]、[SRS_Rte_00203]、[SRS_Rte_00204]、[SRS_Rte_00206]、[SRS_Rte_00207]、[SRS_Rte_00229] |
[RS_BRF_01160] | AUTOSAR 应支持多核 MCU 上的 BSW 分布 | [SRS_Rte_00241]、[SRS_Rte_00242]、[SRS_Rte_00243] |
[RS_BRF_01216] | AUTOSAR OS 应支持将调度表同步到外部时间源 | [SRS_Rte_00232] |
[RS_BRF_01240] | AUTOSAR OS 应支持 OS-Applications 之间的通信 | [SRS_Rte_00210] |
[RS_BRF_01248] | AUTOSAR OS 应支持终止和重启 OS-Applications | [SRS_Rte_00195]、[SRS_Rte_00196]、[SRS_Rte_00223]、[SRS_Rte_00224] |
[RS_BRF_01304] | AUTOSAR RTE 应支持广播通信 | [SRS_Rte_00179]、[SRS_Rte_00183] |
[RS_BRF_01316] | AUTOSAR RTE 应支持对软件组件透明的数据转换 | [SRS_Rte_00247]、[SRS_Rte_00248]、[SRS_Rte_00249]、[SRS_Rte_00250]、[SRS_Rte_00251]、[SRS_Rte_00253] |
[RS_BRF_01320] | AUTOSAR RTE 应调度 SWC 和 BSW 模块 | [SRS_Rte_00049]、[SRS_Rte_00116]、[SRS_Rte_00211]、[SRS_Rte_00212]、[SRS_Rte_00213]、[SRS_Rte_00214]、[SRS_Rte_00215]、[SRS_Rte_00216]、[SRS_Rte_00217]、[SRS_Rte_00218]、[SRS_Rte_00219]、[SRS_Rte_00220]、[SRS_Rte_00221]、[SRS_Rte_00222]、[SRS_Rte_00229]、[SRS_Rte_00230] |
[RS_BRF_01328] | AUTOSAR RTE 应支持在已定义事件上对可执行实体的调度 | [SRS_Rte_00162]、[SRS_Rte_00163]、[SRS_Rte_00216]、[SRS_Rte_00230]、[SRS_Rte_00235] |
[RS_BRF_01376] | AUTOSAR RTE 应支持端口数据元素的自动重缩放与转换 | [SRS_Rte_00181]、[SRS_Rte_00182] |
[RS_BRF_01384] | AUTOSAR RTE 应支持数据自动范围检查 | [SRS_Rte_00180] |
[RS_BRF_01392] | AUTOSAR RTE 应支持旁路（Bypass）实现 | [SRS_Rte_00244] |
[RS_BRF_01393] | AUTOSAR RTE 应支持在 ECU 镜像生成后可选的旁路 | [SRS_Rte_00254]、[SRS_Rte_00255]、[SRS_Rte_00256]、[SRS_Rte_00257]、[SRS_Rte_00258]、[SRS_Rte_00259]、[SRS_Rte_00260] |
[RS_BRF_01394] | AUTOSAR 应支持 RTE 管理缓冲区访问的内存接口 | [SRS_Rte_00255]、[SRS_Rte_00256]、[SRS_Rte_00257]、[SRS_Rte_00258]、[SRS_Rte_00259]、[SRS_Rte_00260] |
[RS_BRF_01560] | AUTOSAR 通信应支持信号到可传输 PDU 的映射 | [SRS_Rte_00251] |
[RS_BRF_01568] | AUTOSAR 通信栈应支持固定大小与动态大小信号 | [SRS_Rte_00190] |
[RS_BRF_01616] | AUTOSAR 通信应支持信号初始值 | [SRS_Rte_00184] |
[RS_BRF_01649] | AUTOSAR 通信应支持在专用优化模块中传输大型与动态数据 | [SRS_Rte_00246] |
[RS_BRF_01816] | AUTOSAR 非易失性存储功能应基于逻辑内存块组织持久化数据 | [SRS_Rte_00176]、[SRS_Rte_00177]、[SRS_Rte_00178]、[SRS_Rte_00228]、[SRS_Rte_00245] |
[RS_BRF_02056] | AUTOSAR OS 应支持时间保护（Timing Protection） | [SRS_Rte_00193] |
[RS_BRF_02272] | AUTOSAR 应提供应用软件行为的跟踪 | [SRS_Rte_00003]、[SRS_Rte_00004]、[SRS_Rte_00005]、[SRS_Rte_00008]、[SRS_Rte_00045]、[SRS_Rte_00192] |
[RS_Main_00200] | AUTOSAR 规范应允许资源高效的实现 | [SRS_Rte_00300]、[SRS_Rte_00301]、[SRS_Rte_00302]、[SRS_Rte_00303]、[SRS_Rte_00304]、[SRS_Rte_00305]、[SRS_Rte_00306]、[SRS_Rte_00307]、[SRS_Rte_00309]、[SRS_Rte_00310]、[SRS_Rte_00311]、[SRS_Rte_00312]、[SRS_Rte_00313]、[SRS_Rte_00314]、[SRS_Rte_00315]、[SRS_Rte_00316]、[SRS_Rte_00317] |
[RS_Main_00280] | AUTOSAR 应支持标准化的汽车通信协议 | [SRS_Rte_00261] |
追溯表共 26 行 RS_BRF_NNNNN / RS_Main_NNNNN 需求；每行链接 1-18 个 SRS_Rte_* 需求 ID。
+ + + +本节需求均涉及 RTE 如何与 AUTOSAR OS 交互。AUTOSAR ECU 架构定义所有交互均通过标准化接口进行。
+ +[SRS_Rte_00020] Access to OS（访问 OS） ⌈
+Type: valid
+Description: RTE 应将 OS 的特性抽象为 AUTOSAR 软件组件的接口。仅 RTE 的服务接口应可直接用于 AUTOSAR 软件组件。
+Rationale: 应用软件组件预期与 OS 无关，因此除服务接口外，不应直接访问任何特定的 OS 函数。例如，RTE 使用基于任务的功能（任务、Resource、Event…）为应用提供可执行实体功能。OS 任务的存在不应暴露给应用。
+Dependencies: [SRS_Rte_00025]
Use Case: OS 提供标准化接口。该接口仅由软件组件通过 RTE API 访问，因此访问受 RTE 控制。OS 还提供服务接口，可由软件组件直接访问。
+Supporting Material: 虚拟功能总线规范 [3]。AUTOSAR ECU 架构为 OS 定义了标准化接口，为应用软件组件定义了 AUTOSAR 接口，因此不可能存在直接交互。
+⌋()
+[SRS_Rte_00099] Decoupling of interrupts（中断解耦） ⌈
+Type: valid
+Description: RTE 应不允许将中断上下文传播到应用软件组件。为确保低延迟时间与确定性，中断上下文可被传播到 RTE。
+Rationale: 如果应用软件组件能在中断上下文中执行，它们可能将系统调度阻塞到不可接受的时长。
+Dependencies: –
+Use Case: RTE "拦截" 中断并使可执行实体能够处理通知。可执行实体在任务上下文中执行。
+Supporting Material: 虚拟功能总线规范 [3]。本需求中的"阻塞"意为 RTE 不应挂起（Running→Waiting）执行回调的控制线程；并不意味着线程不能被抢占。即"阻塞"指"挂起"而非"抢占"。
+⌋()
+[SRS_Rte_00036] Assignment to OS Applications（分配到 OS-Application） ⌈
+Type: valid
+Description: RTE 应提供将 RTE 自身对象（RTE 事件、API）分配给 OS-Application 的能力。
+Rationale: 通过将 RTE 对象分配到 OS-Application，OS 可执行基于 OS-Application 的关闭/重启，从而最小化关闭对 RTE 的影响。
+Dependencies: –
+Use Case: ECU 集成商将 RTE 任务/中断分配到 OS-Application "Rte"，以便于 OS 层面的生命周期管理。
+Supporting Material: –
+⌋()
+[SRS_Rte_00049] Construction of task bodies（构建任务体） ⌈
+Type: valid
+Description: RTE 应为每个被 RTE 管理的 OS 任务提供"任务体"（Task Body）。该任务体应包含被映射到该任务的可执行实体的激活与运行机制。
+Rationale: 由 RTE 完全控制可执行实体在 OS 任务中的调度行为（包括：任务入口、循环体、可执行实体调度顺序、事件等待机制）。
+Dependencies: –
+Use Case: RTE Generator 为每个被声明的 OS 任务生成 void TaskName_TaskBody(void) 函数；该函数内含 while(1) 循环与 Rte_Wait/Terminate/Activate 调用。
Supporting Material: –
+⌋()
+[SRS_Rte_00193] Support for Runnable Entity execution chaining（支持可执行实体执行链） ⌈
+Type: valid
+Description: RTE 应支持在单个 OS 任务内顺序执行多个可执行实体（执行链，Execution Chain）。
+Rationale: 当多个可执行实体在功能上互不依赖但被分配到同一任务时，RTE 应能按配置顺序依次激活它们。
+Dependencies: –
+Use Case: 在一个 10 ms 任务中依次执行 Runnable A → Runnable B → Runnable C 三个可执行实体。
+Supporting Material: –
+⌋()
+[SRS_Rte_00210] Support for inter OS application communication（支持 OS-Application 间通信） ⌈
+Type: valid
+Description: RTE 应支持跨 OS-Application 边界的通信（Sender-Receiver、Client-Server、外部触发等）。
+Rationale: 多核 ECU 或单核分区 ECU 上的应用可能位于不同 OS-Application 中。RTE 必须提供跨 OS-Application 边界的通信能力。
+Dependencies: –
+Use Case: Sender SW-C 位于 OS-App Core1，Receiver SW-C 位于 OS-App Core0，RTE 必须使用 IOC（Inter-OS-Application Communicator）作为传输通道。
+Supporting Material: –
+⌋()
+本节需求均涉及 RTE 如何与 AUTOSAR COM 模块交互。
+ +[SRS_Rte_00068] Signal initial values（信号初始值） ⌈
+Type: valid
+Description: RTE 应在系统启动时为每个信号提供由系统配置定义的初始值。
+Rationale: 在 COM 模块初始化完成前，接收方应用可能读取信号值；RTE 必须保证可读取的信号值是被定义的。
+Dependencies: –
+Use Case: 接收方 SW-C 在 ECU 启动阶段读取"车速"信号；即使 COM 尚未接收到 CAN 总线数据帧，RTE 应提供配置的初始值 0 km/h。
+Supporting Material: –
+⌋()
+[SRS_Rte_00069] Communication timeouts（通信超时） ⌈
+Type: valid
+Description: RTE 应支持 Sender-Receiver 通信的超时检测机制，通知接收方应用信号在配置时间内未更新。
+Rationale: 接收方应用必须能检测到 Sender 失效或总线失效导致的信号"卡死"。
+Dependencies: –
+Use Case: 车速信号应每 100 ms 更新一次；若超过 500 ms 未更新则触发超时处理（fallback 至默认值）。
+Supporting Material: –
+⌋()
+[SRS_Rte_00073] Atomic transport of Data Elements（数据元素的原子传输） ⌈
+Type: valid
+Description: RTE 应保证超过 ECU 传输单元长度的复合数据元素在 Sender 与 Receiver 间以原子方式传输。
+Rationale: 防止接收方读到部分更新的数据（"撕裂读"，torn read）。
+Dependencies: –
+Use Case: 包含 16 字节的 Array 数据元素通过 CAN 传输；RTE 应使用双缓冲（double buffering）或临界区保护保证原子性。
+Supporting Material: –
+⌋()
+[SRS_Rte_00082] Standardized communication protocol（标准化通信协议） ⌈
+Type: valid
+Description: RTE 在跨 ECU 通信时应使用 COM 模块的标准化 API，不应直接访问任何特定总线的驱动。
+Rationale: 保持 SW-C 与总线的无关性。
+Dependencies: –
+Use Case: Sender SW-C 调用 Rte_Send_PpPort_SignalName()；RTE 通过 COM 的 Com_SendSignal() 发送，最终由 PduR 路由到 CAN/FlexRay/Ethernet。
Supporting Material: –
+⌋()
+[SRS_Rte_00091] Inter-ECU Marshalling（跨 ECU 编组） ⌈
+Type: valid
+Description: RTE 应支持将复杂数据元素（如结构体、数组）序列化/反序列化（marshalling/unmarshalling）以跨 ECU 传输。
+Rationale: 不同 ECU 可能使用不同字节序（endianness）或字长。
+Dependencies: –
+Use Case: ECU A（大端）发送 16 字节结构体至 ECU B（小端），RTE 使用 Transformer 链进行字节序转换。
+Supporting Material: –
+⌋()
+[SRS_Rte_00181] Conversion between internal and network data types（内部与网络数据类型转换） ⌈
+Type: valid
+Description: RTE 应支持内部数据类型与网络表示类型之间的自动转换（含字节序、单位换算、缩放因子等）。
+Rationale: 内部以摄氏度表示，网络以原始 ADC 值传输；RTE 应自动执行转换。
+Dependencies: –
+Use Case: 内部数据元素"温度"类型为 sint16°C，网络数据类型为 uint16（0-65535 映射 -50°C 至 200°C）。
+Supporting Material: –
+⌋()
+[SRS_Rte_00246] Support of Efficient COM for large data（支持大型数据高效 COM） ⌈
+Type: valid
+Description: RTE 应支持通过 LdCom（Large Data COM）模块传输大型数据元素（如音频、视频、固件包等）。
+Rationale: 传统 COM 难以高效处理大型数据；LdCom 通过 TP（Transport Protocol）分段传输。
+Dependencies: –
+Use Case: 通过 CAN TP 传输 4 KB 诊断数据；RTE 路由至 LdCom 而非传统 Com。
+Supporting Material: –
+⌋()
+[SRS_Rte_00251] Array based signal group handling with Com（基于数组的信号组 COM 处理） ⌈
+Type: valid
+Description: RTE 应支持使用 COM 信号组传输数组类型的数据元素。
+Rationale: 信号组（Signal Group）可包含多个信号；数组作为单一数据元素也可映射到信号组以利用其原子性保证。
+Dependencies: –
+Use Case: 8 字节 CAN 帧传输 8 字节 uint8 数组；RTE 通过 Com_SendSignalGroup 发送。
+Supporting Material: –
+⌋()
+本节需求均涉及 RTE 如何与应用软件组件（Application Software Components, ASWC）交互。
+ +[SRS_Rte_00011] Support for multiple Application Software Component instances（支持多个应用软件组件实例） ⌈
+Type: valid
+Description: RTE 应支持同一应用软件组件类型的多个实例并存，每个实例应有独立的运行状态与端口连接。
+Rationale: 同一软件组件类型可能因系统配置需要被实例化多次（如左右大灯控制），每个实例应能独立运行。
+Dependencies: –
+Use Case: 实例化 "LightCtrl" 组件两次（LeftLightCtrl、RightLightCtrl），各自处理不同端口的数据。
+Supporting Material: –
+⌋()
+[SRS_Rte_00012] Multiple instantiated AUTOSAR software components delivered as binary code shall share code（以二进制代码交付的多个实例化 AUTOSAR 软件组件应共享代码） ⌈
+Type: valid
+Description: 多个实例化的 AUTOSAR 软件组件以二进制形式交付时，应共享相同的代码段，但拥有独立的实例数据段（per-instance memory）。
+Rationale: 节省 ROM 空间（代码不复制）；隔离实例数据（每个实例独立状态）。
+Dependencies: [SRS_Rte_00013]、[SRS_Rte_00077]
Use Case: 同一二进制 LightCtrl.o 被链接到可执行文件一次；运行时由 RTE 为每个实例分配独立的 instance memory。
+Supporting Material: –
+⌋()
+[SRS_Rte_00013] Per-instance memory（每实例内存） ⌈
+Type: valid
+Description: RTE 应为每个组件实例分配独立的 per-instance memory 区域；该区域不应被同一组件类型的其他实例访问。
+Rationale: 实例间状态隔离。
+Dependencies: [SRS_Rte_00012]、[SRS_Rte_00077]
Use Case: LightCtrl_Instance1._status 与 LightCtrl_Instance2._status 物理上位于不同内存地址。
Supporting Material: –
+⌋()
+[SRS_Rte_00077] Instantiation of per-instance memory（每实例内存的实例化） ⌈
+Type: valid
+Description: RTE Generator 应基于系统配置为每个组件实例生成 per-instance memory 符号（如 ComponentName_InstanceName）。
Rationale: 编译时无法预知实例数量；由 RTE Generator 在生成时根据 ECU 配置实例化。
+Dependencies: [SRS_Rte_00013]
Use Case: Generator 解析 system.arxml 中所有 "LightCtrl" 组件实例并为每个生成 LightCtrl_LeftLightCtrl、LightCtrl_RightLightCtrl 数据结构。
Supporting Material: –
+⌋()
+[SRS_Rte_00017] Rejection of inconsistent component implementations（拒绝不一致的组件实现） ⌈
+Type: valid
+Description: RTE Generator 应在生成时拒绝与组件描述（如端口类型、接口、运行实体签名）不一致的组件实现。
+Rationale: 防止运行时因接口不匹配导致崩溃。
+Dependencies: –
+Use Case: 组件实现声明的 Runnable 签名 void Run(void) 与组件描述中 sint32 Run(sint16 param) 不一致；RTE Generator 报错并退出。
Supporting Material: –
+⌋()
+[SRS_Rte_00134] Runnable Entity categories supported by the RTE（RTE 支持的可执行实体类别） ⌈
+Type: valid
+Description: RTE 应支持以下可执行实体类别：① INIT（初始化）、② SERVER（服务端，运行于 CS 接口）、③ TRIGGERED（由触发事件激活）、④ PERIODIC（周期激活）、⑤ EVENT（由 OS Event 激活）、⑥ BACKGROUND（后台任务）。
Rationale: 完整覆盖 RTE 调度模型。
+Dependencies: –
+Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00072] Activation of Runnable Entities（可执行实体的激活） ⌈
+Type: valid
+Description: RTE 应按 RTE 事件（如数据到达、操作调用、模式切换、触发到达、周期到期）激活可执行实体。
+Rationale: RTE 事件是可执行实体激活的来源；RTE 需将事件映射到 OS 任务调度。
+Dependencies: –
+Use Case: 接收方 RTE 事件 "DataReceivedEvent" 激活可执行实体 OnVehicleSpeed()。
Supporting Material: –
+⌋()
+[SRS_Rte_00160] Debounced start of Runnable Entities（可执行实体的去抖启动） ⌈
+Type: valid
+Description: RTE 应支持在配置的"去抖时间"内累积的多个相同 RTE 事件仅触发一次可执行实体激活。
+Rationale: 避免因总线抖动导致可执行实体被频繁激活。
+Dependencies: –
+Use Case: 数据接收事件在 5 ms 内出现 3 次；去抖时间 10 ms 内仅触发 1 次可执行实体。
+Supporting Material: –
+⌋()
+[SRS_Rte_00161] Activation offset of Runnable Entities（可执行实体的激活偏移） ⌈
+Type: valid
+Description: RTE 应支持为可执行实体配置"激活偏移"（Activation Offset）—— 在 RTE 事件发生后延迟一段时间再激活可执行实体。
+Rationale: 在多任务系统中，错开可执行实体启动时间可减少峰值 CPU 负载。
+Dependencies: –
+Use Case: 周期 10 ms 的 Runnable 启动时间延迟 2 ms，避免与另一 Runnable 同时刻启动。
+Supporting Material: –
+⌋()
+[SRS_Rte_00031] Multiple Runnable Entities（多个可执行实体） ⌈
+Type: valid
+Description: RTE 应支持一个组件内定义多个可执行实体；每个可执行实体可被独立激活并独立执行。
+Rationale: 复杂组件通常需要多个可执行实体分解功能。
+Dependencies: –
+Use Case: EngineCtrl 组件包含 Init、ReadSensors、CalcTorque、WriteActuators 共 4 个可执行实体。
+Supporting Material: –
+⌋()
+[SRS_Rte_00032] Data consistency mechanisms（数据一致性机制） ⌈
+Type: valid
+Description: RTE 应提供数据一致性机制以保护超过 ECU 传输单元长度的复合数据元素不被并发访问破坏。
+Rationale: Sender 与 Receiver 端都需保护。
+Dependencies: –
+Use Case: 16 字节结构体从 Sender 端可执行实体发送到 Receiver 端可执行实体；RTE 内部使用双缓冲 + OsResource 保护。
+Supporting Material: –
+⌋()
+[SRS_Rte_00046] Support for "Executable Entity runs inside" Exclusive Areas（支持"可执行实体运行于"独占区） ⌈
+Type: valid
+Description: RTE 应允许将可执行实体分配到"独占区"（Exclusive Area）；当可执行实体运行于独占区时，独占区内的可执行实体不会被同一组件的其他可执行实体并发执行。
+Rationale: 保护组件内部共享资源不被同一组件多 Runnable 并发访问。
+Dependencies: –
+Use Case: ReadSensors 与 WriteActuators 共享私有 buffer；二者被分配到同一 Exclusive Area "MyEA" 互斥执行。
+Supporting Material: –
+⌋()
+[SRS_Rte_00142] Support for InterRunnableVariables（支持可执行实体间变量） ⌈
+Type: valid
+Description: RTE 应支持可执行实体间变量（Inter-Runnable Variable, IRV），提供同一组件内不同可执行实体间的共享数据访问。
+Rationale: 比"端口 + Sender-Receiver"开销更低；适合同一组件内紧密耦合的可执行实体通信。
+Dependencies: –
+Use Case: ReadSensors 通过 Rte_IrvRead_Buffer() 写入 IRV；CalcTorque 通过 Rte_IrvRead_Buffer() 读取。
Supporting Material: –
+⌋()
+[SRS_Rte_00033] Serialized execution of Server Runnable Entities（服务端可执行实体的串行执行） ⌈
+Type: valid
+Description: RTE 应保证同一 Server 端口的多个 Server 可执行实体被串行执行（同一 Server 端口不会被并发调用）。
+Rationale: 服务端实现的内部数据保护。
+Dependencies: –
+Use Case: 多个客户端并发调用 LightCtrl::SetBrightness()；RTE 保证同一 Server 可执行实体不被并发执行。
Supporting Material: –
+⌋()
+[SRS_Rte_00133] Concurrent invocation of Runnable Entities（可执行实体的并发调用） ⌈
+Type: valid
+Description: RTE 应允许同一组件的不同可执行实体在不同 OS 任务上并发执行（默认行为；除非通过 Exclusive Area 限制）。
+Rationale: 支持并行处理，提高 ECU 算力利用率。
+Dependencies: –
+Use Case: ReadSensors 在 5 ms 任务中运行；WriteActuators 在 10 ms 任务中运行；两者并发执行。
+Supporting Material: –
+⌋()
+[SRS_Rte_00143] Mode Switches（模式切换） ⌈
+Type: valid
+Description: RTE 应支持模式切换（Mode Switch）事件。当模式声明组中的模式发生变化时，RTE 应通知所有引用该模式的可执行实体或组件。
+Rationale: 模式切换是跨组件的同步机制；RTE 必须确保模式变更一致性。
+Dependencies: –
+Use Case: ECU 模式从 "RUN" 切换到 "POST_RUN"；RTE 通知所有注册了 "OnModeChange" 回调的可执行实体。
+Supporting Material: –
+⌋()
+[SRS_Rte_00176] Sharing of NVRAM data（NVRAM 数据共享） ⌈
+Type: valid
+Description: RTE 应支持 NVRAM 数据在多个组件间的共享访问（通过 NvBlockComponent）。
+Rationale: 持久化数据跨组件共享。
+Dependencies: [SRS_Rte_00177]
Use Case: 多个 SW-C 共享 NvBlock 中的里程计数据。
+Supporting Material: –
+⌋()
+[SRS_Rte_00180] DataSemantics range check during runtime（运行时 DataSemantics 范围检查） ⌈
+Type: valid
+Description: RTE 应在运行时对带有 DataSemantics 注解的数据元素进行范围检查；超出范围时报告错误。
+Rationale: 数据正确性保证。
+Dependencies: –
+Use Case: 车速信号被声明为 0-300 km/h；接收到 350 时 RTE 报告 RTE_E_RANGE。
+Supporting Material: –
+⌋()
+[SRS_Rte_00182] Self Scaling Signals at Port Interfaces（端口接口的自动缩放信号） ⌈
+Type: valid
+Description: RTE 应支持在端口接口定义中配置"自缩放"（Self-Scaling）参数，自动执行线性缩放（如 0.1°/bit 转换为 °）。
+Rationale: 减少应用层对原始 ADC 值的处理负担。
+Dependencies: –
+Use Case: 角度信号原始 uint16（0-65535 映射 0-360°）；RTE 内部线性缩放后应用层读到 float 0-360。
+Supporting Material: –
+⌋()
+[SRS_Rte_00236] Support for ModeInterfaceMapping（支持模式接口映射） ⌈
+Type: valid
+Description: RTE 应支持将 PPort 上的 ModeSwitch 接口映射到 RPort 接收的 ModeSwitch 事件。
+Rationale: 简化模式切换的连接配置。
+Dependencies: –
+Use Case: 模式源 SW-C 暴露 ModeSwitch PPort；多个模式接收者 SW-C 共享同一模式源。
+Supporting Material: –
+⌋()
+[SRS_Rte_00237] Time recurrent activation of Runnable Entities（可执行实体的时间重复激活） ⌈
+Type: valid
+Description: RTE 应支持基于时间触发的可执行实体周期激活（Time Recurrent Activation），区别于基于 RTE 事件的激活。
+Rationale: 周期任务是嵌入式控制的基础模式。
+Dependencies: –
+Use Case: 5 ms 周期控制任务；可执行实体每 5 ms 被 RTE 激活一次。
+Supporting Material: –
+⌋()
+本节需求均涉及 RTE 如何与基础软件组件（Basic Software Components, BSW）交互。
+ +[SRS_Rte_00152] Support for port-defined argument values（支持端口定义参数值） ⌈
+Type: valid
+Description: RTE 应支持将端口定义中的参数值（如常量、配置值）传递给 BSW 组件。
+Rationale: 端口参数化是 BSW 与 ASWC 通信的常见模式。
+Dependencies: –
+Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00022] Interaction with call-backs（与回调的交互） ⌈
+Type: valid
+Description: RTE 应支持 BSW 组件通过回调（Callout）调用 SW-C 内的可执行实体。
+Rationale: BSW 通知应用是 AUTOSAR 常见模式（如 DEM 通知、DCM 响应等）。
+Dependencies: –
+Use Case: BswM 调用 SW-C 内的可执行实体 OnBswMModeChange()。
Supporting Material: –
+⌋()
+[SRS_Rte_00062] Local access to basic software components（本地访问基础软件组件） ⌈
+Type: valid
+Description: RTE 应允许 SW-C 在同一 ECU 内通过本地（intra-ECU）端口访问 BSW 组件，无需经过 COM 栈。
+Rationale: 避免本地通信的额外开销。
+Dependencies: –
+Use Case: SW-C 直接调用 Rte_Call_NvMService_GetData() 而非经过 COM/PduR。
Supporting Material: –
+⌋()
+[SRS_Rte_00169] Map code and memory allocated by the RTE to memory sections（将 RTE 分配到的代码与内存映射到内存段） ⌈
+Type: valid
+Description: RTE 生成的代码与内存应可被映射到由用户配置的内存段（Memory Section）。
+Rationale: 与 BSW 内存映射机制一致（[SWS_MemoryMapping]）。
+Dependencies: [SRS_Rte_00170]
Use Case: RTE 代码映射到 SWC_CODE 段，RTE 数据映射到 SWC_VAR_NOINIT 段。
Supporting Material: –
+⌋()
+[SRS_Rte_00170] Provide used memory sections description（提供所用内存段描述） ⌈
+Type: valid
+Description: RTE Generator 应输出所用内存段的描述（如通过 MemMap.h 文件）。
Rationale: 集成商需要将 RTE 数据/代码放入正确的内存段（快速/慢速 ROM/RAM 等）。
+Dependencies: [SRS_Rte_00169]
Use Case: RTE Generator 生成 MemMap.h，包含 RTE_CODE、RTE_VAR、RTE_CONST 等宏。
Supporting Material: –
+⌋()
+[SRS_Rte_00177] Support of NvBlockComponentType（支持 NvBlock 组件类型） ⌈
+Type: valid
+Description: RTE 应支持 NvBlockComponent 组件类型，使 NvM 数据可通过组件端口访问。
Rationale: 抽象 NvM 服务为标准 AUTOSAR 组件接口。
+Dependencies: –
+Use Case: NvBlockComponent_Odometer 暴露读写端口；SW-C 通过端口访问里程数据。
Supporting Material: –
+⌋()
+[SRS_Rte_00228] Fan-out NvBlock callback function（扇出 NvBlock 回调函数） ⌈
+Type: valid
+Description: RTE 应支持在 NvBlock 数据就绪时通知多个 SW-C（扇出 Fan-out 模式）。
+Rationale: 多个 SW-C 可能需要监听同一 NvBlock 数据变更。
+Dependencies: –
+Use Case: NvBlock "Odometer" 数据就绪时同时通知 DisplaySWC 与 TelemetrySWC。
+Supporting Material: –
+⌋()
+[SRS_Rte_00233] Generation of the Basic Software Module Description（生成基础软件模块描述） ⌈
+Type: valid
+Description: RTE Generator 应生成 BSW 模块描述（BSWMD）以描述 RTE 内部模块（如 OS 任务、可执行实体等）。
+Rationale: BSWMD 是 BSW 模块向集成商描述自身配置的标准格式。
+Dependencies: –
+Use Case: RTE Generator 输出 Rte_Bswmd.arxml，描述 RTE 内部 OsTask、OsEvent、OsResource 等。
Supporting Material: –
+⌋()
+[SRS_Rte_00241] Support for Local or Remote Handling of BSW Service Calls on Partitioned Systems（支持分区系统上 BSW 服务调用的本地或远程处理） ⌈
+Type: valid
+Description: RTE 应在多核/分区 ECU 上支持 BSW 服务调用的本地（同分区）或远程（跨分区）处理，由配置决定。
+Rationale: 灵活的服务分布。
+Dependencies: –
+Use Case: SW-C 在 Core0 触发 NvM 服务调用；NvM 在 Core0 部署则为本地调用，部署在 Core1 则为远程调用。
+Supporting Material: –
+⌋()
+[SRS_Rte_00245] Support of Writing Strategies for NV data（支持 NV 数据的写入策略） ⌈
+Type: valid
+Description: RTE 应支持配置 NvBlock 数据的多种写入策略（同步、异步、批处理等）。
+Rationale: 不同业务场景对 NV 写入的性能与可靠性要求不同。
+Dependencies: –
+Use Case: 日志数据采用"批处理"策略（每 60s 写一次）；里程数据采用"立即写"策略（每次变化即写）。
+Supporting Material: –
+⌋()
+本节需求均涉及 RTE 如何生成 BSW 调度器（SchM, BSW Scheduler）以调度 BSW 可调度实体。
+ +[SRS_Rte_00211] Cyclic time based scheduling of BSW Schedulable Entities（基于周期时间的 BSW 可调度实体调度） ⌈
+Type: valid
+Description: RTE Generator 应为 BSW 可调度实体生成周期调度配置。
+Rationale: 与 SWC 周期任务模型一致。
+Dependencies: –
+Use Case: 5 ms 周期的 Com_MainFunction 在 SchM 中被 RTE Generator 配置到对应 OS 任务。
+Supporting Material: –
+⌋()
+[SRS_Rte_00212] Activation Offset of BSW Schedulable Entities（BSW 可调度实体的激活偏移） ⌈
+Type: valid
+Description: RTE Generator 应支持为 BSW 可调度实体配置激活偏移（Activation Offset）。
+Rationale: 错峰启动以减小峰值 CPU 负载。
+Dependencies: –
+Use Case: Com_MainFunctionTx 与 Com_MainFunctionRx 偏移 1 ms 启动，避免同时刻调用。
+Supporting Material: –
+⌋()
+[SRS_Rte_00213] Mode Switches for BSW Modules（BSW 模块的模式切换） ⌈
+Type: valid
+Description: RTE 应支持 BSW 模块对模式声明组变化的响应。
+Rationale: BSW 模块在不同模式下的行为可能不同。
+Dependencies: –
+Use Case: 模式切换至 SLEEP 时 Com 模块停止发送；BswM 触发 SchM 调用 Com_NetworkSleep。
+Supporting Material: –
+⌋()
+[SRS_Rte_00214] Common Mode handling for Basic SW and Application SW（基础软件与应用软件的公共模式处理） ⌈
+Type: valid
+Description: RTE 应允许 BSW 与 ASWC 共享同一模式声明组并由 SchM 统一处理模式变更。
+Rationale: 模式协调一致性。
+Dependencies: –
+Use Case: ECU 模式 "RUN" 是 BSW 与 ASWC 共享；BswM 与 SW-C 同时响应 RUN 模式事件。
+Supporting Material: –
+⌋()
+[SRS_Rte_00215] API for Mode switch notification to the SchM（向 SchM 通知模式切换的 API） ⌈
+Type: valid
+Description: RTE 应提供 API 使 BswM 等模式管理器可通知 SchM 模式变更。
+Rationale: 模式切换的统一入口。
+Dependencies: –
+Use Case: BswM 调用 SchM_Switch_ 触发模式切换。
Supporting Material: –
+⌋()
+[SRS_Rte_00216] Triggering of BSW Schedulable Entities by occurrence of External Trigger（外部触发到达时触发 BSW 可调度实体） ⌈
+Type: valid
+Description: RTE 应支持 BSW 可调度实体被外部 RTE 触发事件激活。
+Rationale: 跨 ECU 触发通信。
+Dependencies: –
+Use Case: 远程 ECU 发送外部触发；Dem 收到后激活相关 BSW 函数处理触发事件。
+Supporting Material: –
+⌋()
+[SRS_Rte_00230] Triggering of BSW Schedulable Entities by occurrence of Internal Trigger（内部触发到达时触发 BSW 可调度实体） ⌈
+Type: valid
+Description: RTE 应支持 BSW 可调度实体被内部 RTE 触发事件激活（同 ECU 内 SW-C→BSW）。
+Rationale: ECU 内触发通信。
+Dependencies: –
+Use Case: 同 ECU 的 SW-C 调用 Rte_Trigger_ 触发 Dem 处理。
Supporting Material: –
+⌋()
+[SRS_Rte_00217] Synchronized activation of Runnable Entities and BSW Schedulable Entities（可执行实体与 BSW 可调度实体的同步激活） ⌈
+Type: valid
+Description: RTE 应支持 SW-C 可执行实体与 BSW 可调度实体的同步激活（同时刻启动或基于同一触发）。
+Rationale: 跨 SW-C/BSW 同步。
+Dependencies: –
+Use Case: 周期 10 ms 触发 SW-C 内的 Runnable 与 Dem 的 Debounce 周期函数同时启动。
+Supporting Material: –
+⌋()
+[SRS_Rte_00218] API for Triggering BSW modules by Triggered Events（通过触发事件触发 BSW 模块的 API） ⌈
+Type: valid
+Description: RTE 应提供 API 使 SW-C 触发事件可激活 BSW 可调度实体。
+Rationale: SW-C 主动触发 BSW。
+Dependencies: –
+Use Case: SW-C 调用 Rte_Trigger_；SchM 路由到 Dem 的回调。
Supporting Material: –
+⌋()
+[SRS_Rte_00219] Support for interlaced execution sequences of Runnable Entities and BSW Schedulable Entities（支持可执行实体与 BSW 可调度实体的交错执行序列） ⌈
+Type: valid
+Description: RTE 应支持 SW-C 与 BSW 可调度实体在同一任务内交错执行。
+Rationale: 共享 OS 任务、减少上下文切换。
+Dependencies: –
+Use Case: 10 ms 任务内执行顺序：Com_MainFunctionTx → SWC_Runnable_A → Dem_MainFunction → SWC_Runnable_B。
+Supporting Material: –
+⌋()
+[SRS_Rte_00220] ECU life cycle dependent scheduling（依赖 ECU 生命周期的调度） ⌈
+Type: valid
+Description: RTE 应支持 BSW 可调度实体的生命周期与 ECU 状态机（如 EcuM 的 UP/SLEEP/STARTUP 等）联动。
+Rationale: ECU 不同状态下的 BSW 行为不同。
+Dependencies: –
+Use Case: ECU 进入 SLEEP 时 Dem_MainFunction 不再调度；ECU 唤醒后再激活。
+Supporting Material: –
+⌋()
+[SRS_Rte_00221] Support for "BSW integration" builds（支持"BSW 集成"构建） ⌈
+Type: valid
+Description: RTE Generator 应支持"BSW 集成"构建模式——独立于 SW-C 单独构建 BSW 子系统。
+Rationale: BSW 子系统的独立集成测试。
+Dependencies: –
+Use Case: BSW 集成商可使用 RTE Generator 仅生成 BSW SchM 与 stub SW-C 接口。
+Supporting Material: –
+⌋()
+[SRS_Rte_00222] Support shared exclusive areas in BSW Service Modules and the corresponding Service Component（在 BSW 服务模块与对应服务组件之间支持共享独占区） ⌈
+Type: valid
+Description: RTE 应允许 BSW 服务模块与 SW-C 服务组件共享同一 Exclusive Area 以保护共享资源。
+Rationale: BSW 与 ASWC 之间共享资源时需要协调互斥访问。
+Dependencies: –
+Use Case: SW-C 与 BSW 模块均需访问 NV 数据；二者通过共享 Exclusive Area "NVM_EA" 互斥。
+Supporting Material: –
+⌋()
+[SRS_Rte_00229] Support for Variant Handling of BSW Modules（支持 BSW 模块的变体处理） ⌈
+Type: valid
+Description: RTE 应支持 BSW 模块的预编译/链接时/后期构建变体处理。
+Rationale: 与 ASWC 变体处理一致。
+Dependencies: –
+Use Case: BSW 模块的 "Variant A" 与 "Variant B" 通过预编译宏选择。
+Supporting Material: –
+⌋()
+[SRS_Rte_00243] Support for inter-partition communication of BSW modules（支持 BSW 模块的跨分区通信） ⌈
+Type: valid
+Description: RTE 应支持 BSW 模块跨 OS-Application 分区边界的通信。
+Rationale: 多核/分区 ECU 上的 BSW 通信。
+Dependencies: –
+Use Case: Dem 在 OS-App Core0，调用 OS-App Core1 的 NvM 服务。
+Supporting Material: –
+⌋()
+本节需求均涉及 RTE 如何支持测量（Measurement）与标定（Calibration）。
+ +[SRS_Rte_00153] Support for Measurement（支持测量） ⌈
+Type: valid
+Description: RTE 应支持 A2L 描述中的测量变量——标定工具可通过 RTE 接口读取 SW-C 内部变量与可执行实体执行时间。
+Rationale: 测量是标定的基础。
+Dependencies: –
+Use Case: 标定工具通过 XCP 协议经 RTE 读取 SW-C 内部标定变量。
+Supporting Material: –
+⌋()
+[SRS_Rte_00154] Support for Calibration（支持标定） ⌈
+Type: valid
+Description: RTE 应支持 A2L 描述中的标定参数——标定工具可读写 SW-C 内部标定参数。
+Rationale: 标定参数是 ECU 调优的核心。
+Dependencies: –
+Use Case: 标定工具通过 XCP 写入新的控制参数（如 PID 控制 Kp/Ki/Kd）。
+Supporting Material: –
+⌋()
+[SRS_Rte_00156] Support for different calibration data emulation methods（支持不同标定数据仿真方法） ⌈
+Type: valid
+Description: RTE 应支持多种标定数据仿真方法：① 真实 ECU 仿真（在线）；② 离线仿真（PC 上基于 A2L）。
+Rationale: 不同开发阶段需要不同仿真方式。
+Dependencies: –
+Use Case: ECU 早期开发时使用离线仿真；ECU 硬件就绪后切换为在线仿真。
+Supporting Material: –
+⌋()
+[SRS_Rte_00157] Support for calibration parameters in NVRAM（支持 NVRAM 中的标定参数） ⌈
+Type: valid
+Description: RTE 应支持将标定参数持久化到 NVRAM；标定参数应在 ECU 掉电后保持。
+Rationale: 标定参数需持久化。
+Dependencies: –
+Use Case: 标定 Kp 值被写入 NvBlock "CalibData"；ECU 复位后仍保留新值。
+Supporting Material: –
+⌋()
+[SRS_Rte_00158] Support separation of calibration parameters（支持标定参数分离） ⌈
+Type: valid
+Description: RTE 应支持将标定参数与 SW-C 应用程序代码/数据分离（不同内存段、不同链接地址）。
+Rationale: 标定参数更新时无需重新刷写整个 ECU。
+Dependencies: –
+Use Case: 标定参数位于专用 flash 段，标定工程师可独立刷写标定数据而无需变更应用代码。
+Supporting Material: –
+⌋()
+[SRS_Rte_00159] Sharing of calibration parameters（标定参数共享） ⌈
+Type: valid
+Description: RTE 应支持多个 SW-C 共享同一标定参数。
+Rationale: 避免标定参数重复定义。
+Dependencies: –
+Use Case: 全局标定参数 "MaxVehicleSpeed" 被多个 SW-C 共享引用。
+Supporting Material: –
+⌋()
+[SRS_Rte_00189] A2L Generation Support（支持 A2L 生成） ⌈
+Type: valid
+Description: RTE Generator 应支持生成或集成 A2L 描述文件以描述 SW-C 标定参数、测量变量、可执行实体等。
+Rationale: A2L 是 ASAM MCD-1 MC / XCP 标准描述格式。
+Dependencies: –
+Use Case: RTE Generator 输出 ECU.a2l，供 INCA/CANape 标定工具导入。
Supporting Material: –
+⌋()
+[SRS_Rte_00021] Per-ECU RTE customization（每 ECU 的 RTE 定制） ⌈
+Type: valid
+Description: RTE 应能为每个 ECU 单独定制——不同 ECU 上的 RTE 可有不同配置/实现。
+Rationale: 分布式 ECU 系统的灵活性。
+Dependencies: –
+Use Case: ECU A 有 5 个 SW-C；ECU B 有 8 个 SW-C；RTE Generator 为每个生成独立的 RTE 配置。
+Supporting Material: –
+⌋()
+[SRS_Rte_00065] Deterministic generation（确定性生成） ⌈
+Type: valid
+Description: RTE Generator 对相同输入应产生相同的输出（确定性），便于版本管理、差分比较。
+Rationale: 持续集成与版本控制的需求。
+Dependencies: –
+Use Case: RTE Generator 在相同输入下产生 bit-identical 输出。
+Supporting Material: –
+⌋()
+[SRS_Rte_00028] "1:n" Sender-receiver communication（"1:n" 发送方-接收方通信） ⌈
+Type: valid
+Description: RTE 应支持一个 Sender 端口对应多个 Receiver 端口的通信模式。
+Rationale: 一对多数据分发（如广播）。
+Dependencies: –
+Use Case: 一个 SW-C 发出"车速"信号；3 个 Receiver SW-C 同时接收。
+Supporting Material: –
+⌋()
+[SRS_Rte_00131] "n:1" Sender-receiver communication（"n:1" 发送方-接收方通信） ⌈
+Type: valid
+Description: RTE 应支持多个 Sender 端口对应一个 Receiver 端口的通信模式。
+Rationale: 多源数据融合（如多个传感器输入）。
+Dependencies: –
+Use Case: 多个 SW-C 写入 "CurrentDemand" 队列；一个执行器 SW-C 读取最新值。
+Supporting Material: –
+⌋()
+[SRS_Rte_00029] "n:1" Client-server communication（"n:1" 客户端-服务端通信） ⌈
+Type: valid
+Description: RTE 应支持多个 Client 端口对应一个 Server 端口的通信模式。
+Rationale: 多客户端共享服务端。
+Dependencies: –
+Use Case: 多个 SW-C 调用同一 NvM 服务的 GetData 操作。
+Supporting Material: –
+⌋()
+[SRS_Rte_00079] Single asynchronous client-server interaction（单次异步客户端-服务端交互） ⌈
+Type: valid
+Description: RTE 应支持客户端发起异步调用（不阻塞等待服务端响应），客户端可继续执行或稍后查询结果。
+Rationale: 异步调用提高系统响应性。
+Dependencies: –
+Use Case: 客户端调用 Rte_Call_Asynchronous_ 立即返回；稍后调用 Rte_Result_ 读取结果。
Supporting Material: –
+⌋()
+[SRS_Rte_00080] Multiple requests of servers（服务端的多次请求） ⌈
+Type: valid
+Description: RTE 应支持 Server 端在处理一个请求期间接收并排队后续请求（请求队列）。
+Rationale: 异步服务端实现。
+Dependencies: –
+Use Case: Server 端请求队列深度为 4；4 个并发请求被排队依次处理。
+Supporting Material: –
+⌋()
+[SRS_Rte_00162] "1:n" External Trigger communication（"1:n" 外部触发通信） ⌈
+Type: valid
+Description: RTE 应支持一个 Trigger Sender 端口对应多个 Trigger Receiver 端口的通信模式。
+Rationale: 1 个触发源可触发多个接收方。
+Dependencies: –
+Use Case: 1 个触发源 SW-C 发送触发，3 个接收方 SW-C 同时被触发。
+Supporting Material: –
+⌋()
+[SRS_Rte_00163] Support for InterRunnableTriggering（支持可执行实体间触发） ⌈
+Type: valid
+Description: RTE 应支持同一组件内一个可执行实体触发另一个可执行实体（Inter-Runnable Triggering）。
+Rationale: 组件内可执行实体间的因果依赖。
+Dependencies: –
+Use Case: ReadSensors 完成时调用 Rte_Trigger_CalcTorque() 触发 CalcTorque Runnable。
Supporting Material: –
+⌋()
+[SRS_Rte_00235] Support queued triggers（支持队列触发） ⌈
+Type: valid
+Description: RTE 应支持配置触发队列以容纳多次未消费的触发事件。
+Rationale: 防止触发事件丢失。
+Dependencies: –
+Use Case: 触发队列深度为 4；触发被消费前可保留 4 次。
+Supporting Material: –
+⌋()
+[SRS_Rte_00025] Static communication（静态通信） ⌈
+Type: valid
+Description: RTE 应仅支持静态通信——所有通信连接必须在编译/生成时确定；RTE 不支持运行时动态创建连接。
+Rationale: 嵌入式实时系统对确定性要求高。
+Dependencies: –
+Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00144] RTE shall support the notification of mode switches via AUTOSAR interfaces（RTE 应支持通过 AUTOSAR 接口通知模式切换） ⌈
+Type: valid
+Description: RTE 应支持通过 AUTOSAR 标准化的 ModeSwitch 接口向 SW-C 通知模式切换事件。
+Rationale: 模式切换是跨组件的标准同步机制。
+Dependencies: –
+Use Case: ECU 模式从 "RUN" 切换到 "POST_RUN"；所有注册了 ModeSwitch RPort 的 SW-C 被通知。
+Supporting Material: –
+⌋()
+[SRS_Rte_00018] Rejection of invalid configurations（拒绝无效配置） ⌈
+Type: valid
+Description: RTE Generator 应拒绝无效配置（如端口不匹配、接口不一致）并报告错误。
+Rationale: 编译时检测优于运行时崩溃。
+Dependencies: –
+Use Case: RTE Generator 报告错误 "Port P1 has Sender-Receiver interface, but connected port is Client-Server"。
+Supporting Material: –
+⌋()
+[SRS_Rte_00055] RTE use of global namespace（RTE 使用全局命名空间） ⌈
+Type: valid
+Description: RTE 生成的符号应使用全局命名空间，且命名应唯一以避免冲突。
+Rationale: C 语言单命名空间限制下的可链接性。
+Dependencies: [SRS_Rte_00164]、[SRS_Rte_00165]、[SRS_Rte_00166]、[SRS_Rte_00167]
Use Case: RTE 生成的函数名 Rte_Read_PpPort_VehicleSpeed() 唯一标识。
Supporting Material: –
+⌋()
+[SRS_Rte_00164] Ensure a unique naming of generated types visible in the global namespace（确保全局命名空间中生成类型的唯一命名） ⌈
+Type: valid
+Description: RTE Generator 应确保所有生成类型在全局命名空间内具有唯一命名。
+Rationale: 避免类型冲突。
+Dependencies: [SRS_Rte_00055]
Use Case: 类型名采用 Rte_ 模式以保证唯一性。
Supporting Material: –
+⌋()
+[SRS_Rte_00165] Suppress identical "C" type re-definitions（抑制相同的 "C" 类型重复定义） ⌈
+Type: valid
+Description: RTE Generator 应避免在多个组件中重复定义相同的 C 类型。
+Rationale: 减少编译时间与代码体积。
+Dependencies: [SRS_Rte_00055]
Use Case: 类型 uint8 仅在 Rte_Type.h 中定义一次。
Supporting Material: –
+⌋()
+[SRS_Rte_00166] Use the AUTOSAR Standard Types in the global namespace if the AUTOSAR data type is mapped to an AUTOSAR Standard Type（若 AUTOSAR 数据类型映射到 AUTOSAR Standard Type，则在全局命名空间使用 AUTOSAR Standard Types） ⌈
+Type: valid
+Description: RTE 应在 AUTOSAR 数据类型映射到 AUTOSAR Standard Type 时使用 Std_Types.h 中的标准类型。
Rationale: 类型一致性。
+Dependencies: [SRS_Rte_00055]
Use Case: 内部 uint16 数据使用 uint16（来自 Std_Types.h）。
Supporting Material: –
+⌋()
+[SRS_Rte_00167] Encapsulate a Software Component local name space（封装软件组件本地命名空间） ⌈
+Type: valid
+Description: RTE 应为每个 SW-C 封装本地命名空间，避免符号污染全局命名空间。
+Rationale: 命名空间隔离。
+Dependencies: [SRS_Rte_00055]
Use Case: SW-C 内部函数 LocalFunction() 仅在 SW-C 内可见；外部通过 RTE API 访问。
Supporting Material: –
+⌋()
+[SRS_Rte_00252] Encapsulate a BSW Module local name space（封装 BSW 模块本地命名空间） ⌈
+Type: valid
+Description: RTE 应为 BSW 模块封装本地命名空间，与 SW-C 处理方式一致。
+Rationale: 命名空间一致性。
+Dependencies: [SRS_Rte_00055]
Use Case: BSW 内部函数 InternalHandler() 仅在 BSW 模块内可见。
Supporting Material: –
+⌋()
+[SRS_Rte_00126] C language support（C 语言支持） ⌈
+Type: valid
+Description: RTE 应支持以 ISO C 1999 编写的 SW-C。
+Rationale: C 是 AUTOSAR CP 的基础实现语言。
+Dependencies: [SRS_Rte_00138]
Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00138] C++ language support（C++ 语言支持） ⌈
+Type: valid
+Description: RTE 应支持以 ISO C++ 2014 编写的 SW-C。
+Rationale: 复杂业务逻辑常用 C++ 实现。
+Dependencies: [SRS_Rte_00126]
Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00051] RTE API mapping（RTE API 映射） ⌈
+Type: valid
+Description: RTE 应将抽象的 VFB 接口映射为具体的 RTE API；RTE API 的具体形式由 RTE Generator 决定（如直接函数调用、宏、内联等）。
+Rationale: 实现灵活性。
+Dependencies: –
+Use Case: RTE Generator 为 "Read VehicleSpeed" 决定是生成 Rte_Read_PpPort_VehicleSpeed() 独立函数还是宏。
Supporting Material: –
+⌋()
+[SRS_Rte_00048] RTE Generator input（RTE Generator 输入） ⌈
+Type: valid
+Description: RTE Generator 应以 AUTOSAR 系统描述（ARXML）为输入，生成 RTE 代码。
+Rationale: 与 AUTOSAR 工具链集成。
+Dependencies: –
+Use Case: RTE Generator 读取 system.arxml + ecuc.arxml。
Supporting Material: –
+⌋()
+[SRS_Rte_00023] RTE Overheads（RTE 开销） ⌈
+Type: valid
+Description: RTE 实现应最大化应用代码可用的资源（CPU、内存）；RTE 自身的开销应最小化。
+Rationale: 嵌入式资源受限。
+Dependencies: –
+Use Case: RTE 单次 Read 调用开销 < 100 ns。
+Supporting Material: –
+⌋()
+[SRS_Rte_00024] Source-code AUTOSAR software components（源代码 AUTOSAR 软件组件） ⌈
+Type: valid
+Description: RTE 应支持以源代码形式交付的 SW-C（OEM 或 Tier-1 提供 .c/.h 源文件）。
+Rationale: 源代码是 SW-C 交付的主要形式。
+Dependencies: –
+Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00140] Binary-code AUTOSAR software components（二进制代码 AUTOSAR 软件组件） ⌈
+Type: valid
+Description: RTE 应支持以预编译目标码形式交付的 SW-C（OEM 或 Tier-1 仅提供 .obj/.a 库）。
+Rationale: IP 保护场景下需二进制交付。
+Dependencies: –
+Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00083] Optimization for source-code components（源代码组件的优化） ⌈
+Type: valid
+Description: RTE Generator 应可为源代码交付的 SW-C 生成优化后的 RTE 代码（如内联、消除冗余）。
+Rationale: 性能优化。
+Dependencies: –
+Use Case: 编译器可对 RTE Generator 生成的 RTE API + SW-C 源文件进行跨文件优化。
+Supporting Material: –
+⌋()
+[SRS_Rte_00027] VFB to RTE mapping shall be semantic preserving（VFB 到 RTE 映射应保持语义） ⌈
+Type: valid
+Description: RTE Generator 将 VFB 模型映射到 RTE 实现时应保持 VFB 语义——所有 VFB 模型中的通信语义、时序、错误处理必须在 RTE 实现中保留。
+Rationale: 语义保真是基本要求。
+Dependencies: –
+Use Case: VFB 模型中 "1:n" 广播在 RTE 中通过 Com 广播实现。
+Supporting Material: –
+⌋()
+[SRS_Rte_00190] Support for variable-length Data Types（支持可变长度数据类型） ⌈
+Type: valid
+Description: RTE 应支持可变长度数据元素（如 String、Bytefield、uint8 Array 变体）。
+Rationale: 动态数据大小在某些场景下是必要的。
+Dependencies: –
+Use Case: 字符串数据元素；RTE 调用 Com_SendSignalDyn() 动态长度发送。
Supporting Material: –
+⌋()
+本节需求均涉及 RTE 如何支持 VFB 跟踪。
+ +[SRS_Rte_00005] The RTE generator shall support "trace" builds（RTE Generator 应支持"跟踪"构建） ⌈
+Type: valid
+Description: RTE Generator 应支持生成包含 VFB 跟踪代码的"跟踪"（trace）构建版本，以便在运行时记录 VFB 通信事件。
+Rationale: 跟踪构建是性能分析与问题诊断的工具。
+Dependencies: –
+Use Case: RTE Generator 生成 --trace 选项的 RTE 代码，包含 Rte_Trace_Send/Receive/Call/Return 调用。
Supporting Material: –
+⌋()
+[SRS_Rte_00045] Standardized VFB tracing interface（标准化 VFB 跟踪接口） ⌈
+Type: valid
+Description: RTE 应通过 AUTOSAR 标准化的 DLT（Diagnostic Log and Trace）接口输出 VFB 跟踪事件。
+Rationale: DLT 是 AUTOSAR 标准的跟踪消息传输机制。
+Dependencies: [SRS_Rte_00008]、[SRS_Rte_00192]
Use Case: RTE 跟踪事件通过 DLT 发送至 DLT Viewer 工具。
+Supporting Material: –
+⌋()
+[SRS_Rte_00008] VFB tracing configuration（VFB 跟踪配置） ⌈
+Type: valid
+Description: RTE 应允许通过配置选择哪些 VFB 事件被跟踪（按端口/按接口粒度）。
+Rationale: 减少跟踪开销。
+Dependencies: [SRS_Rte_00045]
Use Case: 仅跟踪 "VehicleSpeed" 信号；其他信号不跟踪。
+Supporting Material: –
+⌋()
+[SRS_Rte_00192] Support multiple trace clients（支持多跟踪客户端） ⌈
+Type: valid
+Description: RTE 应支持多个跟踪客户端同时消费 VFB 跟踪事件。
+Rationale: 多工具可同时分析跟踪（如示波器 + 跟踪分析器）。
+Dependencies: [SRS_Rte_00045]
Use Case: DLT Viewer 与 ECU 内部日志同时接收 RTE 跟踪事件。
+Supporting Material: –
+⌋()
+[SRS_Rte_00003] Tracing of sender-receiver communication（发送方-接收方通信的跟踪） ⌈
+Type: valid
+Description: RTE 应能跟踪 Sender-Receiver 通信的 Send/Receive 事件，包含端口名、数据元素、时间戳。
+Rationale: 数据流可视化。
+Dependencies: –
+Use Case: 跟踪日志显示 "Rte_Trace_Send: P1.VehicleSpeed=120 km/h at t=1234ms"。
+Supporting Material: –
+⌋()
+[SRS_Rte_00004] Tracing of client-server communication（客户端-服务端通信的跟踪） ⌈
+Type: valid
+Description: RTE 应能跟踪 Client-Server 通信的 Call/Return 事件，包含操作名、参数、返回值。
+Rationale: 服务调用可视化。
+Dependencies: –
+Use Case: 跟踪日志显示 "Rte_Trace_Call: LightCtrl.SetBrightness(50) -> RTE_E_OK"。
+Supporting Material: –
+⌋()
+[SRS_Rte_00052] Initialization and finalization of components（组件的初始化与终止） ⌈
+Type: valid
+Description: RTE 应为每个 SW-C 生成初始化（Init()）与终止（DeInit() 或 Exit()）函数。
Rationale: ECU 启动/关闭时需初始化所有组件。
+Dependencies: [SRS_Rte_00116]
Use Case: EcuM 在启动时按依赖顺序调用所有 SW-C 的 Rte_Call_。
Supporting Material: –
+⌋()
+[SRS_Rte_00070] Invocation order of Runnable Entities（可执行实体的调用顺序） ⌈
+Type: valid
+Description: RTE 应允许在配置中定义同一组件内可执行实体的调用顺序（Init 阶段、Normal 阶段、Shutdown 阶段）。
+Rationale: 初始化依赖顺序。
+Dependencies: –
+Use Case: Component Init 阶段按 InitCalibration → InitSensor → InitActuator 顺序调用。
Supporting Material: –
+⌋()
+[SRS_Rte_00239] Support rule-based initialization of composite DataPrototypes and compound primitive DataPrototypes（支持复合 DataPrototypes 与组合 primitive DataPrototypes 的基于规则的初始化） ⌈
+Type: valid
+Description: RTE 应支持基于规则的复合数据元素初始化（如按类型、按范围、按默认值）。
+Rationale: 复杂数据结构的初始值生成。
+Dependencies: –
+Use Case: 结构体字段按默认规则（如 0、max、INF）初始化。
+Supporting Material: –
+⌋()
+[SRS_Rte_00240] Support of init runnables for initialization purposes（支持用于初始化的 init 可执行实体） ⌈
+Type: valid
+Description: RTE 应支持 SW-C 显式声明 init 类型可执行实体用于自定义初始化。
+Rationale: 标准初始化外的定制初始化需求。
+Dependencies: –
+Use Case: SW-C 定义 MyCustomInitRunnable 用于业务级初始化。
Supporting Material: –
+⌋()
+[SRS_Rte_00100] Compiler independent API（编译器独立 API） ⌈
+Type: valid
+Description: RTE 生成的 API 应与编译器无关——使用标准 C/C++ 语言特性，不依赖特定编译器扩展。
+Rationale: 跨工具链可移植性。
+Dependencies: [SRS_Rte_00168]
Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00168] Typing of RTE API（RTE API 的类型化） ⌈
+Type: valid
+Description: RTE 生成的 API 应使用 AUTOSAR 数据类型（如 uint16、sint32）而非原生 C 类型（int、short）。
+Rationale: 类型一致性（避免 int = 16/32/64 位的歧义）。
+Dependencies: [SRS_Rte_00100]
Use Case: API 签名 Std_ReturnType Rte_Read_PpPort_Signal(uint16* data)。
Supporting Material: –
+⌋()
+[SRS_Rte_00059] RTE API shall pass "in" primitive data types by value（RTE API 应以值方式传递"in" primitive 数据类型） ⌈
+Type: valid
+Description: RTE API 在传递 "in" 方向的 primitive 数据类型（如 uint8/sint16/boolean）时应以值方式传参。
+Rationale: primitive 类型按值传递性能更优。
+Dependencies: –
+Use Case: Std_ReturnType Op(boolean enabled, uint8 level)。
Supporting Material: –
+⌋()
+[SRS_Rte_00060] RTE API shall pass "in" composite data types by reference（RTE API 应以引用方式传递"in" 复合数据类型） ⌈
+Type: valid
+Description: RTE API 在传递 "in" 方向的复合数据类型（如结构体、数组）时应以 const 引用方式传参。
+Rationale: 避免大结构体复制。
+Dependencies: –
+Use Case: Std_ReturnType Op(const MyStruct* inData)。
Supporting Material: –
+⌋()
+[SRS_Rte_00061] "in/out" and "out" parameters（"in/out" 与 "out" 参数） ⌈
+Type: valid
+Description: RTE API 对 "in/out" 与 "out" 方向参数应使用指针传参（不强制 const）。
+Rationale: 允许函数修改输出。
+Dependencies: –
+Use Case: Std_ReturnType Op(uint8* inOutValue, sint16* outResult)。
Supporting Material: –
+⌋()
+[SRS_Rte_00115] API for data consistency mechanism（数据一致性机制的 API） ⌈
+Type: valid
+Description: RTE 应提供 API 以支持数据一致性机制（如显式 Enter/Exit Exclusive Area）。
+Rationale: 应用级显式互斥保护。
+Dependencies: –
+Use Case: Rte_Enter_。
Supporting Material: –
+⌋()
+[SRS_Rte_00075] API for accessing per-instance memory（访问每实例内存的 API） ⌈
+Type: valid
+Description: RTE 应提供 API 以访问 per-instance memory 中的 SW-C 实例变量。
+Rationale: SW-C 内部实例数据访问。
+Dependencies: [SRS_Rte_00013]
Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00107] Support for INFORMATION_TYPE attribute（支持 INFORMATION_TYPE 属性） ⌈
+Type: valid
+Description: RTE 应支持 Sender-Receiver 接口的 INFORMATION_TYPE 属性——定义数据元素语义（如 ENUMERATION、STRUCTURE）。
Rationale: 数据元素语义提示。
+Dependencies: –
+Use Case: INFORMATION_TYPE = uint8 ENUMERATION (0..7)。
Supporting Material: –
+⌋()
+[SRS_Rte_00108] Support for INIT_VALUE attribute（支持 INIT_VALUE 属性） ⌈
+Type: valid
+Description: RTE 应支持 INIT_VALUE 属性——为数据元素定义初始值。
Rationale: 信号初始值定义。
+Dependencies: –
+Use Case: INIT_VALUE = 0（数据元素初始为 0）。
Supporting Material: –
+⌋()
+[SRS_Rte_00109] Support for RECEIVE_MODE attribute（支持 RECEIVE_MODE 属性） ⌈
+Type: valid
+Description: RTE 应支持 RECEIVE_MODE 属性——定义 RPort 接收模式（如 STANDARD / LAST_IS_BEST / QUEUED）。
Rationale: 接收行为控制。
+Dependencies: –
+Use Case: RECEIVE_MODE = LAST_IS_BEST（最新值覆盖）。
Supporting Material: –
+⌋()
+[SRS_Rte_00110] Support for BUFFERING attribute（支持 BUFFERING 属性） ⌈
+Type: valid
+Description: RTE 应支持 BUFFERING 属性——定义 Sender 端口是否缓冲数据（UNBUFFERED / BUFFERED）。
Rationale: 发送行为控制。
+Dependencies: –
+Use Case: BUFFERING = BUFFERED（多次调用仅发送最新值）。
Supporting Material: –
+⌋()
+[SRS_Rte_00111] Support for CLIENT_MODE attribute（支持 CLIENT_MODE 属性） ⌈
+Type: valid
+Description: RTE 应支持 CLIENT_MODE 属性——定义 Client 端操作调用模式（同步 SYNC / 异步 ASYNC）。
Rationale: 客户端调用模式控制。
+Dependencies: –
+Use Case: CLIENT_MODE = ASYNC（异步调用）。
Supporting Material: –
+⌋()
+[SRS_Rte_00121] Support for FILTER attribute（支持 FILTER 属性） ⌈
+Type: valid
+Description: RTE 应支持数据元素的 FILTER 属性——定义数据接收时的过滤规则（如 ALWAYS、NEVER、ON_CHANGE、MASKED_NEW_DIFFERS_MASKED_OLD）。
Rationale: 数据过滤减少无效通信。
+Dependencies: –
+Use Case: FILTER = ON_CHANGE（仅当数据变化时通知）。
Supporting Material: –
+⌋()
+[SRS_Rte_00147] Support for communication infrastructure timeout notification（支持通信基础设施超时通知） ⌈
+Type: valid
+Description: RTE 应支持在通信基础设施（如 COM）发生超时时通知 SW-C。
+Rationale: 通信可靠性监控。
+Dependencies: –
+Use Case: CAN 总线超时 → 通知 SW-C 触发 fallback。
+Supporting Material: –
+⌋()
+[SRS_Rte_00078] Support for Data Element Invalidation（支持数据元素失效） ⌈
+Type: valid
+Description: RTE 应支持数据元素失效（Invalidation）机制——Sender 端显式标记信号为"无效"；Receiver 端可检测无效状态。
+Rationale: 信号有效性传递。
+Dependencies: –
+Use Case: Sensor 失效时 Sender 调用 Rte_Invalidate_PpPort_Signal()；Receiver 读取 isUpdated 标志。
Supporting Material: –
+⌋()
+[SRS_Rte_00122] Support for Transmission Acknowledgement（支持传输确认） ⌈
+Type: valid
+Description: RTE 应支持 Sender 在数据被成功传输（如收到 CAN Tx Confirmation）后获得通知。
+Rationale: 传输可靠性确认。
+Dependencies: –
+Use Case: CAN Tx 确认 → RTE 调用 Sender SW-C 的回调通知"已发送"。
+Supporting Material: –
+⌋()
+[SRS_Rte_00094] Communication and Resource Errors（通信与资源错误） ⌈
+Type: valid
+Description: RTE 应在通信或资源错误（如超时、内存不足、接口不可用）时向 SW-C 返回 RTE_E_* 错误码。
+Rationale: 错误处理标准化。
+Dependencies: [SRS_Rte_00084]
Use Case: RTE_E_TIMEOUT、RTE_E_LIMIT、RTE_E_COM_STOPPED 等。
+Supporting Material: –
+⌋()
+[SRS_Rte_00084] Support infrastructural errors（支持基础设施错误） ⌈
+Type: valid
+Description: RTE 应支持报告基础设施级错误（如 OS 错误、内存分配失败）。
+Rationale: 系统级错误检测。
+Dependencies: [SRS_Rte_00094]
Use Case: RTE 检测到 OsTask 创建失败时报告 RTE_E_OS_ERROR。
+Supporting Material: –
+⌋()
+[SRS_Rte_00123] The RTE shall forward application level errors from server to client（RTE 应将服务端应用级错误转发至客户端） ⌈
+Type: valid
+Description: RTE 应将 Server 端返回的应用级错误（如 APPLICATION_ERROR）原样转发给调用方 Client。
Rationale: 应用级错误处理一致性。
+Dependencies: –
+Use Case: Server 端操作返回 0x10 E_NOT_OK；Client 端通过 Rte_Result 获得相同错误码。
Supporting Material: –
+⌋()
+[SRS_Rte_00124] API for application level errors during Client Server communication（Client-Server 通信中应用级错误的 API） ⌈
+Type: valid
+Description: RTE 应提供 API 以报告 Client-Server 通信中的应用级错误（APPLICATION_ERROR 类型）。
Rationale: 错误传递 API。
+Dependencies: –
+Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00089] Independent access to interface elements（接口元素的独立访问） ⌈
+Type: valid
+Description: RTE 应允许 SW-C 通过独立 API 访问同一接口的不同数据元素，而非一次访问整个接口。
+Rationale: 细粒度访问提升性能与可读性。
+Dependencies: –
+Use Case: Rte_Read_P1_VehicleSpeed() 单独访问 VehicleSpeed 数据元素。
Supporting Material: –
+⌋()
+[SRS_Rte_00137] API for mismatched ports（不匹配端口的 API） ⌈
+Type: valid
+Description: RTE 应在 RPort 与 PPort 接口不匹配时返回适当的错误码。
+Rationale: 错误检测与安全。
+Dependencies: –
+Use Case: 配置错误 → RTE 返回 RTE_E_INTERFACE_ERROR。
Supporting Material: –
+⌋()
+[SRS_Rte_00139] Support for unconnected ports（支持未连接端口） ⌈
+Type: valid
+Description: RTE 应支持未连接端口（Unconnected Port）—— PPort 或 RPort 未连接到任何对端。
+Rationale: 灵活的配置与变体支持。
+Dependencies: –
+Use Case: 某可选 SW-C 未部署；其 PPort 标记为 Unconnected；RTE 不调用但 API 仍存在。
+Supporting Material: –
+⌋()
+[SRS_Rte_00200] Support of unconnected R-Ports（支持未连接的 RPort） ⌈
+Type: valid
+Description: RTE 应支持 RPort 未连接到任何 PPort 的情况，调用 RPort API 时返回特殊值或 RTE_E_UNCONNECTED 错误。
+Rationale: 与 [SRS_Rte_00139] 互补，针对 RPort 端。
+Dependencies: [SRS_Rte_00139]
Use Case: –
+Supporting Material: –
+⌋()
+[SRS_Rte_00155] API to access calibration parameters（访问标定参数的 API） ⌈
+Type: valid
+Description: RTE 应提供 API 以使 SW-C 可访问 A2L 标定参数。
+Rationale: 标定参数运行时访问。
+Dependencies: –
+Use Case: Rte_CData_Get_Kp(&value) 读取标定参数 Kp。
Supporting Material: –
+⌋()
+[SRS_Rte_00183] RTE Read API returning the dataElement value（返回数据元素值的 RTE 读 API） ⌈
+Type: valid
+Description: RTE 应提供 Read API 直接返回数据元素值（与通过指针参数返回的 API 形式区分）。
+Rationale: API 灵活性。
+Dependencies: –
+Use Case: uint16 Rte_Read_P1_VehicleSpeed(void) 直接返回值。
Supporting Material: –
+⌋()
+[SRS_Rte_00185] RTE API with Rte_IFeedback（带 Rte_IFeedback 的 RTE API） ⌈
+Type: valid
+Description: RTE API 应通过 Rte_IFeedback 返回额外的状态信息（如是否更新过、源 ECU 标识等）。
Rationale: 增强的反馈信息。
+Dependencies: –
+Use Case: Std_ReturnType Op(uint16* data, Rte_IFeedback* fb)。
Supporting Material: –
+⌋()
+[SRS_Rte_00203] API to read system constant（读取系统常量的 API） ⌈
+Type: valid
+Description: RTE 应提供 API 以读取系统常量（SystemConstant）。
+Rationale: 系统配置常量访问。
+Dependencies: –
+Use Case: Rte_Const_Get_PlatformEndianness() 读取字节序常量。
Supporting Material: –
+⌋()
+[SRS_Rte_00242] Support for Cross-Core Exclusive Areas（支持跨核独占区） ⌈
+Type: valid
+Description: RTE 应支持跨核 Exclusive Area——在多核 ECU 上跨核互斥的临界区保护。
+Rationale: 多核互斥。
+Dependencies: –
+Use Case: Rte_Enter_GlobalEA(); 在 Core0 锁定，所有核上的同一 EA 不可进入。
Supporting Material: –
+⌋()
+[SRS_Rte_00087] Software Module Header File generation（软件模块头文件生成） ⌈
+Type: valid
+Description: RTE Generator 应为每个 SW-C 生成软件模块头文件（包含所有 API 声明）。
+Rationale: 编译时类型检查。
+Dependencies: –
+Use Case: #include "Rte_LightCtrl.h"。
Supporting Material: –
+⌋()
+[SRS_Rte_00116] RTE Initialization and finalization（RTE 初始化与终止） ⌈
+Type: valid
+Description: RTE 应提供 Rte_Init() 与 Rte_DeInit()（或 Rte_Stop()）函数用于 RTE 自身的初始化与终止。
Rationale: RTE 自身生命周期管理。
+Dependencies: [SRS_Rte_00052]
Use Case: EcuM 在 OS Start 之后调用 Rte_Init()。
Supporting Material: –
+⌋()
+[SRS_Rte_00195] No activation of Runnable Entities in terminated or restarting partitions（已终止或重启中的分区中不激活可执行实体） ⌈
+Type: valid
+Description: RTE 应在 OS-Application 处于 terminated 或 restarting 状态时，停止激活该分区内的可执行实体。
+Rationale: 分区安全重启。
+Dependencies: [SRS_Rte_00196]
Use Case: ECU Core1 上的 OS-App "PowerTrain" 处于 restarting 时，RTE 不再激活其内 Runnable。
+Supporting Material: –
+⌋()
+[SRS_Rte_00196] Inter-partition communication consistency（跨分区通信一致性） ⌈
+Type: valid
+Description: RTE 应保证跨分区通信的一致性，即使对端分区已 terminated 或 restarting。
+Rationale: 故障分区不污染健康分区。
+Dependencies: [SRS_Rte_00195]
Use Case: 健康分区读取故障分区数据时获得 stale 数据（保留旧值），而非崩溃。
+Supporting Material: –
+⌋()
+[SRS_Rte_00223] Callout for partition termination notification（分区终止通知的回调） ⌈
+Type: valid
+Description: RTE 应提供回调（Callout）在分区即将终止时通知应用，以便进行资源清理。
+Rationale: 资源清理。
+Dependencies: –
+Use Case: 分区终止时回调 SW-C 内的 OnPartitionTerminate() 关闭文件句柄。
Supporting Material: –
+⌋()
+[SRS_Rte_00224] Callout for partition restart request（分区重启请求的回调） ⌈
+Type: valid
+Description: RTE 应提供回调（Callout）在分区即将重启时通知应用，以便进行状态保存。
+Rationale: 状态恢复。
+Dependencies: –
+Use Case: 分区重启前回调 SW-C 内的 OnPartitionRestart() 保存状态到 NvM。
Supporting Material: –
+⌋()
+本节无具体 SRS 需求；故障操作的具体行为在 BSW 相关 SRS 中定义（如 Dem、Dcm、EcuM）。
+ +本节定义 RTE 实施插件（RTE Implementation Plug-In）相关需求——允许替换/扩展 RTE 内部实现的特定部分以优化性能或资源使用。R4.4.0 新增 18 个 SRS_Rte_003xx 需求。
+ +[SRS_Rte_00300] RTE Implementation Plug-Ins for explicit communication（显式通信的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持为显式通信（如 Rte_Send/Rte_Read）提供可插拔的实施替换点。
+Rationale: 用户可使用更高效的本地实现替换默认 RTE 通信机制。
+Dependencies: –
+Use Case: 用户实现自定义 MyRtePlugin_Send() 并将其注册为显式通信的插件。
Supporting Material: –
+⌋()
+[SRS_Rte_00301] RTE Implementation Plug-Ins for implicit communication（隐式通信的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持为隐式通信（如变量共享）提供可插拔的实施替换点。
+Rationale: 隐式通信的灵活实现。
+Dependencies: –
+Use Case: 用户可使用共享内存优化隐式 Sender-Receiver。
+Supporting Material: –
+⌋()
+[SRS_Rte_00302] RTE Implementation Plug-Ins for exclusive areas（独占区的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持为 Exclusive Area 的进入/退出提供可插拔的实施替换点。
+Rationale: 不同 MCU 提供不同的原子原语；插件允许使用最优实现。
+Dependencies: –
+Use Case: 使用 LDSETH/LDCLH（TriCore）替换默认 OsResource 机制。
+Supporting Material: –
+⌋()
+[SRS_Rte_00303] RTE Implementation Plug-Ins for global copy instantiation（全局副本实例化的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持对全局副本（global copy）的实例化提供可插拔的实施替换点。
+Rationale: 在多核场景下，global copy 的物理布局对性能有影响。
+Dependencies: –
+Use Case: 跨核 shared memory 中放置 global copy。
+Supporting Material: –
+⌋()
+[SRS_Rte_00304] Multiple RTE Plug-Ins（多个 RTE 插件） ⌈
+Type: valid
+Description: RTE 应支持为同一接口注册多个 Plug-In；运行时根据配置选择使用哪一个。
+Rationale: 灵活的多实现方案。
+Dependencies: –
+Use Case: 同时存在 "Plugin_Debug" 与 "Plugin_Release"；构建时选择。
+Supporting Material: –
+⌋()
+[SRS_Rte_00305] Graduated validation strategy（分阶段验证策略） ⌈
+Type: valid
+Description: RTE 应支持分阶段验证策略——Plug-In 可在不同构建阶段（编译/链接/运行时）应用不同验证强度。
+Rationale: 开发期 vs 发布期不同验证等级。
+Dependencies: –
+Use Case: 开发期使用 "FullValidation" 插件；发布期使用 "Optimized" 插件。
+Supporting Material: –
+⌋()
+[SRS_Rte_00306] Standardized interfaces for RTE Implementation Plug-Ins（标准化的 RTE 实施插件接口） ⌈
+Type: valid
+Description: RTE 应为 Plug-In 提供标准化的 C 接口（函数指针表/虚函数）以便实现与 RTE 核心解耦。
+Rationale: 接口标准化便于第三方实现。
+Dependencies: –
+Use Case: struct Rte_PluginInterface { ... } 定义统一接口。
Supporting Material: –
+⌋()
+[SRS_Rte_00307] RTE Implementation Plug-Ins for cross core communication（跨核通信的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持为跨核通信提供可插拔的实施替换点。
+Rationale: 跨核通信机制多样化（共享内存、IPC、SPI）。
+Dependencies: –
+Use Case: 使用自定义 IOC 协议作为跨核通信机制。
+Supporting Material: –
+⌋()
+[SRS_Rte_00309] RTE Implementation Plug-Ins for cross safety partition communication（跨安全分区通信的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持为跨安全分区的通信提供可插拔的实施替换点（如实现 ASIL 分解所需的隔离机制）。
+Rationale: 功能安全 ISO 26262 要求 QM/ASIL 分区隔离。
+Dependencies: –
+Use Case: 使用 ASIL-QM 桥接器作为跨安全分区通信机制。
+Supporting Material: –
+⌋()
+[SRS_Rte_00310] Shared mode queue（共享模式队列） ⌈
+Type: valid
+Description: RTE 应为模式切换提供共享模式队列；多个 SW-C 可在共享模式队列中读取/监听模式变化。
+Rationale: 模式变更一致性。
+Dependencies: –
+Use Case: 多 SW-C 监听同一模式组；共享队列实现同步。
+Supporting Material: –
+⌋()
+[SRS_Rte_00311] Core synchronous transitions for mode switches（模式切换的核同步转换） ⌈
+Type: valid
+Description: RTE 应支持模式切换在多核上的同步转换——所有核在同一时刻完成模式切换。
+Rationale: 跨核模式一致性。
+Dependencies: –
+Use Case: ECU 模式切换在 Core0/Core1/Core2/Core3 同时生效。
+Supporting Material: –
+⌋()
+[SRS_Rte_00312] RTE Implementation Plug-Ins for transformers in client server communication（Client-Server 通信中转换器的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持为 Client-Server 通信中的数据转换器（Transformer）提供可插拔的实施替换点。
+Rationale: 转换器实现多样化（ComBasedTransformer、SomeIpTransformer、E2ETransformer）。
+Dependencies: –
+Use Case: 自定义 E2E 加密转换器。
+Supporting Material: –
+⌋()
+[SRS_Rte_00317] RTE Implementation Plug-Ins for transformers in trigger communication（触发通信中转换器的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应支持为触发通信中的数据转换器提供可插拔的实施替换点。
+Rationale: 与 [SRS_Rte_00312] 互补，针对触发通信。
+Dependencies: –
+Use Case: 自定义触发通信安全转换器。
+Supporting Material: –
+⌋()
+[SRS_Rte_00313] Description of RTE Implementation Plug-in properties（描述 RTE 实施插件属性） ⌈
+Type: valid
+Description: RTE 应通过 ECUC 参数或配置描述 RTE 实施插件的属性。
+Rationale: 插件属性配置化。
+Dependencies: –
+Use Case: ECUC_Rte_Plugin_001 描述插件 A 的属性。
Supporting Material: –
+⌋()
+[SRS_Rte_00314] Avoid nesting of critical sections（避免临界区嵌套） ⌈
+Type: valid
+Description: RTE 应避免在持有临界区时调用其他可能申请临界区的 API（防止死锁）。
+Rationale: 死锁预防。
+Dependencies: –
+Use Case: RTE 在 EA1 内不应调用其他 SW-C 的 EA2 API。
+Supporting Material: –
+⌋()
+[SRS_Rte_00315] Protection of mode machine instance access（保护模式机实例访问） ⌈
+Type: valid
+Description: RTE 应保护模式机（Mode Machine）实例的并发访问以确保模式状态机一致性。
+Rationale: 模式状态机原子性。
+Dependencies: –
+Use Case: 多核同时切换同一模式机时由 RTE 串行化。
+Supporting Material: –
+⌋()
+[SRS_Rte_00316] RTE Implementation Plug-Ins for compatibility mode（兼容模式的 RTE 实施插件） ⌈
+Type: valid
+Description: RTE 应为兼容模式（Compatibility Mode）提供可插拔的实施替换点。
+Rationale: 兼容模式（与传统 R2.x 行为兼容）可定制。
+Dependencies: –
+Use Case: 自定义兼容模式下的 API 行为。
+Supporting Material: –
+⌋()
+[SRS_Rte_00064] AUTOSAR methodology（AUTOSAR 方法学） ⌈
+Type: valid
+Description: RTE 的开发与配置应遵循 AUTOSAR 方法学。
+Rationale: 与 AUTOSAR 整体方法学一致。
+Dependencies: –
+Use Case: RTE Generator 遵循 AUTOSAR_TR_Methodology 描述的生成流程。
Supporting Material: –
+⌋()
+[SRS_Rte_00019] RTE is the communication infrastructure（RTE 是通信基础设施） ⌈
+Type: valid
+Description: RTE 应作为 SW-C 间通信的唯一基础设施（除直接函数调用外）。
+Rationale: 统一通信抽象。
+Dependencies: –
+Use Case: SW-C 间所有数据通信均经 RTE API；无绕过 RTE 的直接调用。
+Supporting Material: –
+⌋()
+AUTOSAR_TPS_StandardizationTemplate — 标准化模板（Standardization Template）AUTOSAR_RS_StandardizationTemplate — 标准化模板需求（Requirements on Standardization Template）AUTOSAR_EXP_VFB — 虚拟功能总线（Virtual Functional Bus）AUTOSAR_TPS_SoftwareComponentTemplate — 软件组件模板（Software Component Template）AUTOSAR_TPS_BSWModuleDescriptionTemplate — 基础软件模块描述模板（Basic Software Module Description Template）AUTOSAR_SRS_ModeManagement — 模式管理需求（Requirements on Mode Management）AUTOSAR_SWS_MemoryMapping — 内存映射规范（Specification of Memory Mapping）AUTOSAR_SWS_CompilerAbstraction — 编译器抽象规范（Specification of Compiler Abstraction）AUTOSAR_SWS_PlatformTypes — 平台类型规范（Specification of Platform Types）AUTOSAR_SRS_BSWGeneral — 基础软件通用需求（General Requirements on Basic Software Modules）AUTOSAR_SWS_DiagnosticLogAndTrace — 诊断日志与跟踪规范（Specification of Diagnostic Log and Trace）校对轮次：L1 自动校对（2026-06-13）
+[SRS_Rte_00255/00256/00257/00258/00259/00260]（7 次）、[SRS_Rte_00216/00230]（2 次）、[SRS_Rte_00232]（1 次）、[SRS_Rte_00241/00242/00243]（3 次） 等。valid（无 dpt/obsolete/withdrawn 类型）。[SRS_Rte_00012] 依赖 [SRS_Rte_00013]+[SRS_Rte_00077]、[SRS_Rte_00013] 依赖 [SRS_Rte_00012]+[SRS_Rte_00077]、[SRS_Rte_00020] 依赖 [SRS_Rte_00025]、[SRS_Rte_00077] 依赖 [SRS_Rte_00013]、[SRS_Rte_00094] 依赖 [SRS_Rte_00084]、[SRS_Rte_00126] 依赖 [SRS_Rte_00138]、[SRS_Rte_00138] 依赖 [SRS_Rte_00126]、[SRS_Rte_00045] 依赖 [SRS_Rte_00008]+[SRS_Rte_00192]、[SRS_Rte_00052] 依赖 [SRS_Rte_00116]、[SRS_Rte_00100] 依赖 [SRS_Rte_00168]、[SRS_Rte_00116] 依赖 [SRS_Rte_00052]、[SRS_Rte_00195] 依赖 [SRS_Rte_00196]、[SRS_Rte_00196] 依赖 [SRS_Rte_00195]、[SRS_Rte_00200] 依赖 [SRS_Rte_00139]、[SRS_Rte_00169] 依赖 [SRS_Rte_00170]、[SRS_Rte_00170] 依赖 [SRS_Rte_00169]。本规范（AUTOSAR_SWS_RTE，文档 ID 084）定义运行时环境（Run-Time Environment, RTE）软件的实施要求。RTE 是 AUTOSAR VFB（Virtual Functional Bus，虚拟功能总线）针对特定 ECU 的具体实现，提供：
+RTE 与 BSW 调度器（SchM）在 R4.0.1 版本起合并；本文档同时涵盖两者。R4.4.0 主要变化：RTE Implementation Plug-Ins、对结构化数据类型可选元素的支持、以及小的修正/澄清。
+ +| 规范 | 依赖关系 |
|---|---|
AUTOSAR_TPS_SoftwareComponentTemplate | RTE 输入：SW-C 描述、端口、接口、内部行为 |
AUTOSAR_TPS_BSWModuleDescriptionTemplate | RTE 输入：BSW 模块描述 |
AUTOSAR_SRS_RTE | RTE 需求规约（本 SWS 的上游） |
AUTOSAR_SWS_OS | RTE 调用 OS API（任务、事件、Resource、ISR 等） |
AUTOSAR_SWS_COM | RTE 通过 COM 进行跨 ECU 通信 |
AUTOSAR_SWS_PDURouter | PDU 路由（跨总线） |
AUTOSAR_SWS_DefaultErrorTracer | RTE 错误通过 DET 上报 |
AUTOSAR_SWS_CompilerAbstraction | 编译器抽象宏 |
AUTOSAR_SWS_MemoryMapping | 内存段映射 |
AUTOSAR_SWS_PlatformTypes | 平台类型 |
AUTOSAR_EXP_VFB | VFB 概念与原理 |
| 缩略语 | 英文全称 | 中文释义 |
|---|---|---|
| API | Application Programming Interface | 应用程序编程接口 |
| BSW | Basic Software | 基础软件 |
| BSWMD | Basic Software Module Description | 基础软件模块描述 |
| CDD | Complex Device Driver | 复杂设备驱动 |
| COM | Communication | AUTOSAR 通信模块 |
| CPU | Central Processing Unit | 中央处理器 |
| DLT | Diagnostic Log and Trace | 诊断日志与跟踪 |
| DET | Default Error Tracer | 默认错误追踪器 |
| ECU | Electronic Control Unit | 电子控制单元 |
| EA | Exclusive Area | 独占区 |
| IRV | Inter-Runnable Variable | 可执行实体间变量 |
| ISR | Interrupt Service Routine | 中断服务例程 |
| IOC | Inter-OS-Application Communicator | OS-Application 间通信器 |
| MCAL | Microcontroller Abstraction Layer | 微控制器抽象层 |
| MDT | Minimum Data Type | 最小数据类型 |
| NV/NVRAM | Non-Volatile RAM | 非易失性内存 |
| OS | Operating System | 操作系统 |
| PDU | Protocol Data Unit | 协议数据单元 |
| RTE | Run-Time Environment | 运行时环境 |
| SchM | Basic Software Scheduler | 基础软件调度器 |
| SWC/SW-C | Software Component | 软件组件 |
| TP | Transport Protocol | 传输协议 |
| VFB | Virtual Function Bus | 虚拟功能总线 |
本节定义贯穿全文使用的核心术语（详细定义见第 4 章）：
+本规范的需求规约遵循 [TPS_STDT_00078] 的表格格式（参见 AUTOSAR_TPS_StandardizationTemplate 第 Support for Traceability 章节）。RFC 2119 关键字 SHALL/SHALL NOT/MUST/MUST NOT/SHOULD/SHOULD NOT/MAY/OPTIONAL 保留英文原意并首次出现时附中文释义。技术术语（[TPS_STDT_00053]）保持与标准化模板一致。
本 SWS 中所有 SWS_Rte_NNNNN 需求均来自上游 AUTOSAR_SRS_RTE（文档 ID 083）的 SRS_Rte_NNNNN 需求；SWS_Rte_NNNNN 编号与 SRS_Rte_NNNNN 一一对应。下表给出 SRS_Rte_NNNNN → SWS_Rte_NNNNN 的映射关系：
| 需求类别 | SRS_Rte 数量 | SWS_Rte 实现位置 |
|---|---|---|
| OS 交互 | 6 | 4.1.1 / 4.2.2 |
| COM 交互 | 8 | 4.3.1 / 4.3.2 |
| ASWC 交互 | 21 | 4.1.3 / 4.1.4 / 4.2.5 / 4.2.7 |
| BSW 交互 | 10 | 4.1.8 / 4.2.9 |
| BSW 调度器 | 15 | 3.1.2 / 3.4.1 / 4.2.2.2 |
| 测量与标定 | 7 | 4.2.8 |
| 通用 | ~70 | 5.1 / 5.2 |
| VFB 跟踪 | 6 | 5.3.7 |
| 初始化与终止 | 4 | 4.6 |
| API | 29 | 5.6 / 5.7 |
| C/C++ API | 1 | 5.1.1 / 5.2.6.4 |
| 初始化操作 | 1 | 5.8.1 |
| 分区重启 | 4 | 4.6.1.3 |
| RTE 实施插件 | 18 | 附录（待补） |
| 非功能 | 2 | 4.4.9 / 1.5 |
| 合计 | ~200+ | 1-5 章 |
RTE 在 AUTOSAR 架构中处于应用软件组件（SW-C）与基础软件（BSW）之间。RTE 实现了虚拟功能总线（VFB）的具体 API，使 SW-C 之间以及 SW-C 与 BSW 之间的通信成为可能。
+对 ECU 而言，RTE 是 VFB 抽象的具体实现——为每个 ECU 单独生成和优化。不同 ECU 上的 RTE 可有不同的实现策略（如选择宏实现 vs 函数调用），但 VFB 语义保持一致。
+ +AUTOSAR 软件组件是 ECU 上的功能模块化单元。SW-C 通过端口（Port）与外界通信；端口通过接口（Interface）定义通信的语义。SW-C 分为：
+NvBlockComponent、ParameterComponent、SensorActuatorSWC、EcuAbstractionSWC、ApplicationSWC、ComplexDeviceDriverSWC、ServiceProxySwc、ServiceSwcType 等。基础软件模块（BSW Module）分为：
+AUTOSAR 支持三种基本通信范式：
+通信模式定义通信会话的语义，包括：
+Rte_Send、Rte_Read 等）进行通信；AUTOSAR CP RTE 仅支持静态通信——所有通信连接必须在编译/生成时确定。运行时不可动态创建/销毁通信连接。这确保了实时系统的确定性行为。
+ +通信连接可具有多实例：
+AUTOSAR ECU 通常运行多个任务（Task）以处理不同优先级的功能。RTE 必须协调跨任务的并发访问：
+RTE Generator 是 RTE 实施工具链的核心组件：
+system.arxml）+ ECU 配置（ecuc.arxml）+ 组件实现（*.c/*.h）；Rte.c、Rte_Lib.c、Rte.h、Rte_PBcfg.c/h、Rte_Type.h、Rte_<SWC>.h、SchM_*.c/h 等。RTE Generator 应支持：
+RTE 的关键设计决策包括：
+RTE 生成流程分为多个阶段，每个阶段产生特定输出。流程图见图 3.1（原文 p.79）。
+ +契约阶段（Contract Phase）由 OEM 与 Tier-1 共同完成，定义 RTE 与 BSW 调度器的"合约"——双方同意的接口、配置、约束。
+ +RTE 契约阶段产出：
+BSW 调度器契约阶段产出：
+SchM_Enter/Exit_*）。PreBuild 数据集用于 ECU 制造前的"基础"配置：
+RTE ECU 配置可在 PreBuild 阶段后被 ECU 集成商进一步调整：
+生成阶段由 RTE Generator 自动执行：
+ +SchM 生成阶段产出：
+SchM_<Module>.c/h：BSW 模块的调度函数；RTE 生成阶段产出（详细见 5.3 节）：
+Rte.h、Rte_Type.h、Rte_<SWC>.h；Rte.c、Rte_Lib.c；Rte_PBcfg.c、Rte_PBcfg.h；Rte_Trace.h（含 DLT Message ID）；Rte_Cfg.h。BSWMD 描述 RTE 与 BSW 模块的内部行为（任务、事件、入口函数），供集成商进行 ECU 集成：
+PreBuild 数据集生成阶段产出：
+PostBuild 数据集生成阶段产出：
+Rte_PBcfg.c）；RTE 配置与以下 BSW 模块存在交互：
+本节描述 RTE 的高层架构概念。包括 RTE 与数据类型的关系、RTE 与 AUTOSAR 软件组件的关系、RTE 与 AUTOSAR 服务的关系、RTE 与 ECU 抽象层的关系、RTE 与 CDD 的关系，以及 BSW 调度器与 BSW 模块的关系。
+ +RTE 处理 AUTOSAR 中三种主要数据类型：
+uint8/sint16/float32 等）。RTE 负责 ADT 到 IDT 的映射、IDT 到 Base Type 的映射（含字节序转换、单位换算、缩放因子应用）。详细映射规则见 4.3.7 节"数据转换"。
+ +AUTOSAR SWC 支持层次结构：
+RTE Generator 为每个原子 SWC 与每个 ECU 生成 RTE；组合 SWC 不会单独生成 RTE（其内部 SWC 各自生成 RTE）。
+ +SWC 通过端口（Port）与外界通信：
+每个端口引用一个端口接口（Port Interface）：
+连接（Connector）将 PPort 连接到 RPort，建立通信路径。
+ +SWC 内部行为定义 SWC 内部细节：
+SWC 实现以源代码（*.c/*.h）或目标码（*.o/*.a）形式提供，包含所有可执行实体的实现。RTE Generator 解析 SWC 实现与内部行为的匹配性。
同一 SWC 类型可在系统中被实例化多次（如左右大灯控制）。每实例有独立的 Per-Instance Memory（变量存储）、Instance Handle（运行时标识）、Port 连接（与对端不同）。
+ +实例化由 ECU 集成商在系统配置时声明：
+SWC 在系统中仅被实例化一次。RTE Generator 为其生成 SWCInstance_Default 单一 Per-Instance Memory。
SWC 在系统中被实例化多次。RTE Generator 为每个实例生成独立的 Per-Instance Memory 符号（如 LightCtrl_LeftLightCtrl、LightCtrl_RightLightCtrl）。实例代码共享，仅数据独立。
RTE 与 AUTOSAR 服务层（Services Layer）的交互：
+ECU 抽象层提供 ECU 硬件的抽象 API；RTE 本身不直接调用 ECU 抽象 API，而是通过服务层（如 Port 驱动、ADC 驱动）调用。具体端口到 ECU 抽象的映射由 ECU 集成商配置。
+ +复杂设备驱动（CDD）允许 SW-C 直接访问硬件，绕过标准 AUTOSAR 服务。RTE 对 CDD 提供：
+ComplexDeviceDriverSwc 类型）参与系统集成；BSW 调度器（SchM）是 RTE 的姊妹组件，专门用于调度 BSW 可调度实体：
+ +BSW 模块描述（BSWMD）描述 BSW 模块的内部行为（任务、事件、入口函数）。
+ +BSW 模块通过标准化 C API 接口被调用。SchM Generator 与 RTE Generator 一同生成 BSW 接口的客户端 stub。
+ +BSW 内部行为定义 BSW 模块的运行实体（MainFunction、回调等）、事件、依赖关系。
+ +BSW 实现由 BSW 模块供应商提供源代码或目标码；RTE Generator 不生成 BSW 实现代码本身。
+ +BSW 模块可被实例化多次（如同类型 SPI 驱动用于多个 SPI 总线）。每实例有独立配置。
+ +三种 BSW 模块类型均可作为 SchM 调度对象。
+ +本节描述 RTE 与 SchM 的具体实施方面——OS 集成、可执行实体激活、中断解耦、数据一致性、参数实现、测量标定、NV 数据访问等。
+ +RTE 与 OS 的集成涉及：
+ +RTE Generator 创建的 OS 对象：
+BSW 可调度实体是 BSW 模块中可被 SchM 调度的函数，如：
+MainFunction（如 Com_MainFunctionRx/Tx）；MainFunction（如 CanIf_RxIndication）；Init；DeInit。Runnable 是 SWC 内可被 RTE 调度的函数。RTE Generator 生成的 RTE 任务体中包含所有映射到该任务的 Runnable 的调用。
+ +RTE 事件触发 Runnable 激活。事件类型包括：
+BSW 事件是 BSW 模块的内部事件，类似于 RTE 事件但作用于 BSW 可调度实体。BswEvent 在 BSWMD 中定义。
+ +RTE Generator 将 Runnable 与 BSW 可调度实体映射到 OS 任务。映射规则：
+RTE 支持可执行实体的执行时间监控（基于 OS 时间保护 Timing Protection）：
+ProtectionHook 或 TimingViolationNotification。TimingEvent 激活的 Runnable 由 OS 调度表（ScheduleTable）或闹钟（Alarm）触发。RTE Generator 配置 OS 调度表项以匹配 TimingEvent 的周期与偏移。
+ +多个 TimingEvent 可在多核 ECU 上需要同步激活。RTE 使用 OS 同步机制确保跨核 TimingEvent 的同步性。
+ +BackgroundEvent 是优先级最低的事件类型，RTE Generator 将其映射到 OS 后台任务。
+ +InitEvent 在 SWC 初始化阶段触发。RTE Generator 生成的 Rte_<SWC>_Init 函数调用所有 InitEvent 关联的 Runnable。
某些 RTE 事件可通过直接函数调用激活 Runnable（无 OS 介入）：
+激活偏移（Activation Offset）允许 Runnable/BSW 可调度实体在 RTE 事件后延迟激活。RTE Generator 在任务体中通过 OS API 实现偏移。
+ +对于事件回调需求（如 [SRS_Rte_00238]），RTE 应在 Runnable 入口提供"激活事件"标识。
+ +RTE 拦截来自 BSW 驱动的中断通知，将其转发到合适的任务上下文中的 Runnable：
+AUTOSAR OS 支持两类 ISR：
+OS_ISR1_ISR；OS_ISR2_ISR。RTE 通过"事件标志+OS Event"机制将 ISR 与 Runnable 解耦——ISR 仅设置事件标志，Runnable 在任务上下文中处理事件。
+ +RTE 不应在 ISR 上下文中直接执行 Runnable。Cat-1 ISR 仅调用 RTE 通知 API；Cat-2 ISR 可调用 RTE 通知 API 与 OS API。
+ +BswExecutionContext 定义 BSW 函数的执行上下文（任务/ISR）。RTE 与 SchM 均使用 BswExecutionContext 配置 BSW 函数的执行环境。
+ +数据一致性是 RTE 设计的关键挑战。当数据元素大于 ECU 传输单元（通常 8 字节）时，单次写入可能被并发访问破坏——产生"撕裂读"（torn read）。
+ +通信模式决定数据一致性的实现：
+数据一致性保护有三种基本概念：
+RTE 支持的数据一致性机制：
+Rte_Read/Rte_Write 期间锁定 OS 资源。Rte_IrvRead/Rte_IrvWrite 期间锁定 OS 资源。独占区是用户/集成商可配置的 OS 资源区域。RTE 在 Rte_Enter/Exit_<EA>() API 中使用 OS Resource API。Exclusive Area 分为：
IRV 是一种特殊的 SWC 内部共享变量。RTE 提供 Rte_IrvRead/<Name>() 与 Rte_IrvWrite/<Name>() API，底层使用 OS Resource 保证原子性。
同一可执行实体可被多个 RTE 事件触发（如一个 Runnable 同时被 TimingEvent 与 DataReceivedEvent 触发）。RTE Generator 在任务体中合并多个事件的处理逻辑。
+ +RTE Generator 根据 AUTOSAR 元模型中的 Compatibility 规则将数据元素映射到实现。
+ +Compatibility 规则决定 ImplementationDataType 与 BaseType 的兼容性，决定 RTE 是否生成转换代码。
+ +接口元素（数据元素、操作参数）的实现由 RTE Generator 根据 Interface Package 描述生成。
+ +VariableDataPrototype（用于 Per-Instance Memory、IRV 等）可在 ECU 启动时由 RTE 初始化为默认值或配置值。
+ +RTE Generator 根据 InitValue 规则计算初始值；可在 RTE 启动时统一初始化。
+ +测量（Measurement）与标定（Calibration）是 ECU 开发的核心调试手段。RTE 与 XCP/A2L 协同工作：
+测量支持：
+标定支持：
+McSupportData（Measurement & Calibration Support Data）由 RTE Generator 输出至 A2L 文件，描述所有可测量/可标定元素。生成规则：
+NVRAM 数据通过 NvBlockComponent 组件类型与 RTE 集成。NvBlock 抽象为标准的 AUTOSAR 端口（NvDataInterface）。
NvBlockSwComponentType 暴露的端口：
PPort_NvData：提供 NV 数据；RPort_NvData：请求 NV 数据；PPort_NvService：NV 服务（如 ReadBlock、WriteBlock、ReadAll、WriteAll）；NV Service 接口：
+ReadBlock(nvBlock, data)：读取指定块；WriteBlock(nvBlock, data)：写入指定块；CancelWriteBlock(nvBlock)：取消写入；ReadAll()：读取所有块；WriteAll()：写入所有块；GetErrorStatus(nvBlock, status)：查询错误状态。NV 数据一致性由 NvM 保证：单块原子性、写完成回调通知等。RTE 仅负责将 SWC 端的访问请求路由到 NvM。
+ + + +Sender-Receiver 通信是 AUTOSAR 中最常用的通信范式。本节定义 S/R 通信的 17 个子主题：
+ +S/R 通信是单向数据流——一个或多个 Sender 写入数据元素，一个或多个 Receiver 读取数据元素。RTE 负责 Sender 与 Receiver 间的数据路由与一致性保证。
+ +Receiver 可配置为以下接收模式：
+一个端口可包含多个数据元素。RTE Generator 为每个数据元素生成独立的 Read/Write API。
+ +RTE 支持 1:n、n:1、n:m 多实例通信。Sender 端 API 一次调用会被 RTE 复制到所有 Receiver；Receiver 端 API 一次调用从所有 Sender 中选择。
+ +隐式通信：数据通过共享内存自动可见；Runnable 不需显式调用 API；性能高但耦合度高。
+显式通信：通过 Rte_Send/Rte_Read 等 API 显式传递；可由 RTE Generator 优化为宏/内联。
Sender 可注册 DataSendCompletedEvent 监听传输完成（如 CAN Tx Confirmation）。
Receiver 可配置超时监控——若信号在指定时间内未更新，触发 DataReceiveErrorEvent。
Sender 可调用 Rte_Invalidate() 显式标记信号无效。Receiver 可通过 Rte_IsUpdated() 检测信号是否被更新。
数据元素的过滤规则：
+Sender 端可配置缓冲模式：
+S/R 操作详述。RTE 为每对 Sender-Receiver 生成的 API 包括：
+Rte_Send_<PPort>_<DE>()、Rte_Write_<PPort>_<DE>()、Rte_IWrite_<ImplPort>_<DE>()；Rte_Read_<RPort>_<DE>()、Rte_DRead_<RPort>_<DE>()、Rte_Receive_<RPort>_<DE>()、Rte_IRead_<ImplPort>_<DE>()、Rte_IStatus_<ImplPort>_<DE>()、Rte_IsUpdated_<RPort>_<DE>()。Receiver 可通过 Rte_IsUpdated() 检测"从未收到"状态——用于初始化时与故障时区分。
Receiver 端 API 返回的 Rte_SendStatus 包含 RTE_SEND_NEVER_RECEIVED、RTE_SEND_RECEIVED 等值。
支持 String、Bytefield、uint8 Array 变体长度数据元素（DYNAMIC）。
大数据元素通过 TP（Transport Protocol，如 CAN TP）分段传输。RTE 路由到 PduR 后由 PduR 负责 TP 分段/重组。
+ +字节数组（uint8 Array）跨 ECU 通信使用 LdCom（Large Data COM）。RTE 路由至 LdCom 代替传统 Com。
+ +Sender 端注册的 DataSendCompletedEvent 在数据被成功发送到总线（CAN Tx Confirmation）后触发。
Client-Server 通信是请求-响应模式——Client 调用 Server 端操作。RTE 提供同步（Rte_Call_<RPort>_<Op>()）与异步（Rte_Result_<RPort>_<Op>() 轮询）两种调用模式。
Client-Server 支持 n:1（多个 Client 调用同一 Server）。Server 端可序列化执行或并发执行（由配置决定）。
+ +Client 端可配置操作调用超时（TIMEOUT 参数）。超时后返回 RTE_E_TIMEOUT。
操作参数可包含"端口定义参数值"（port-defined argument values）——由 RTE 配置在每次调用时填入固定值（如常量）。
+ +Client-Server 请求可在 Server 端缓冲（队列）。队列深度由配置决定。
+ +Client-Server 可跨 ECU（通过 COM 序列化）或跨分区（通过 IOC）。RTE 透明地处理这些分布式调用。
+ +Client-Server 操作参数可通过 Transformer 序列化（用于跨 ECU）。
+ +C/S API：
+Rte_Call_<RPort>_<Op>(<args>) 阻塞等待响应；Rte_Call_<RPort>_<Op>_Async(<args>) 立即返回；Rte_Result_<RPort>_<Op>(<out args>) 轮询结果；<Op>(<args>)，由 RTE 调用。IRV 是一种仅限同 SWC 内的共享变量机制，RTE 提供 Rte_IrvRead/<Name>() 与 Rte_IrvWrite/<Name>()。IRV 比端口通信开销低。
跨 OS-Application 分区（多核/单核分区）的数据通信使用 OS IOC（Inter-OS-Application Communicator）。RTE 透明地使用 IOC 作为传输通道。
+ +BSW 可调度实体跨分区调用时，SchM 负责在正确的 OS-Application 中执行。
+ +LdCom、Det 等共享服务模块可能需要特殊访问模式（跨分区调用）。
+ +跨分区通信涉及信号（如数据更新事件）与控制流（如 Server 调用）的传输。
+ +可信函数允许非信任 OS-Application 调用信任 OS-Application 中的受保护函数。
+ +在受内存保护的 OS-Application 中，跨分区调用时参数需要安全传输。RTE 使用 IOC 的"安全缓冲区"机制保证指针参数安全传输。
+ +当 PPort 与 RPort 的数据元素实现数据类型不同时，RTE 必须执行转换。映射规则：
+数据元素无转换时直接打包到 PDU。
+ +数据元素需转换时（如字节序、序列化）使用 Transformer。
+ +RTE 支持以下数据转换：
+当数据元素带 DataSemantics 时，RTE 在运行时检查数据范围。超出范围时 RTE 返回 RTE_E_RANGE 错误码。
AUTOSAR 模式（Mode）用于 ECU 行为控制。本节定义模式相关的 11 个子主题：
+ +模式使用者（Mode User）是订阅模式变更的 SWC。当模式变更时，RTE 通过 SwcModeSwitchEvent 通知 Mode User。
模式管理器（Mode Manager）是控制模式声明组的 SWC。模式管理器通过 Rte_Switch_<PPort>_<ModeDeclarationGroup>_<Mode>() 切换模式。
模式声明（ModeDeclaration）原子地表示一个模式；模式声明组（ModeDeclarationGroup）是一组互斥的模式。在任一时刻，模式组中仅有一个模式处于 active 状态。
+ +RTE 在接收到模式切换通知时按以下顺序执行：
+SwcModeSwitchEvent 关联 Runnable；ModeSwitchedAckEvent 关联 Runnable。模式机（Mode Machine）的实例可被分配到不同的 OS-Application（多核/多分区）。RTE 与 SchM 协调跨核的模式一致性。
+ +模式机在 ECU 启动时由 RTE 初始化为配置的默认模式。
+ +模式切换通知通过 RTE 内部事件分发器进行：SwcModeSwitchEvent 关联的 Runnable 在通知时被激活。
若模式机配置了 ack-required，所有 Mode User 须确认收到模式变更。RTE 收集所有 ack 后通知 ModeSwitchedAckEvent。
当 Mode User OS-Application 被终止时，RTE 自动取消其对模式机的订阅。
+ +当 Mode Manager OS-Application 被终止时，RTE 将其控制的所有模式机冻结为当前模式。
+ +模式声明的跨 ECU 映射通过 RTE 内部实现。Mode Manager 在 ECU A，Mode User 在 ECU B；RTE 通过 Com 序列化模式变化。
+ +多核 ECU 上的共享模式队列：所有核共享同一模式状态机，RTE 使用原子操作与内存屏障保证一致性。
+ +外部触发（External Trigger）是从远程 ECU 触发的跨 ECU 事件。RTE 通过 Com 接收外部触发，激活本地关联 Runnable。
+ +同 SWC 内一个 Runnable 触发另一个 Runnable。RTE 提供 Rte_Trigger_<Trigger>() 与 Rte_IrTrigger_<Trigger>()。
BSW 模块间触发通过 SchM 处理。
+ +跨 ECU 触发通过 Com 传输。RTE 透明地处理序列化。
+ +触发可配置队列深度。多次未消费的触发在队列中累积。
+ +触发激活关联 Runnable 时的处理流程：
+SchM 在 EcuM 启动阶段被调用 SchM_Init() 初始化。
RTE 在 EcuM 启动 OS 后调用 Rte_Start() 初始化。RTE_Start 内部完成：
支持 RTE 停止与重启：Rte_Stop() 停止；Rte_Start() 重启。
ECU 关闭时调用 Rte_Stop() 终止 RTE。RTE 内部完成清理。
ECU 关闭时调用 SchM_DeInit() 终止 SchM。
每个 SWC 有自己的 Init 与 DeInit 可执行实体（若配置）。RTE 在 RTE_Start / RTE_Stop 中按配置顺序调用。
变体处理允许 ECU 在不同时刻（如 PreCompile、LinkTime、PostBuild）选择不同配置，以支持多车型、多硬件平台复用同一 RTE。
+ +5 种绑定时机（Binding Times）：
+支持以下变体：
+支持 SchM API 变体、BSW 实体变体、API 行为变体。
+ +SWC 实现可在 PreCompile 阶段通过宏选择不同代码路径。
+ +RTE 通过 DET（Default Error Tracer）报告开发错误。RTE 不单独定义 DET 模块，使用 BSW 标准 DET。
+ +RTE 使用的 DET 错误标识符：
+| 错误码（宏） | 值 | 含义 |
|---|---|---|
RTE_E_OK | 0x00 | 无错误 |
RTE_E_INVALID | 0x01 | 参数无效 |
RTE_E_PORT_DISABLED | 0x02 | 端口未使能 |
RTE_E_UNCONNECTED | 0x03 | 端口未连接 |
RTE_E_LIMIT | 0x04 | 超出限制 |
RTE_E_LOST_DATA | 0x05 | 数据丢失（队列溢出） |
RTE_E_TIMEOUT | 0x06 | 超时 |
RTE_E_IN_EXCLUSIVE_AREA | 0x07 | 已在独占区内 |
RTE_E_NESTING_EXCLUSIVE_AREA | 0x08 | 独占区嵌套错误 |
RTE_E_COM_STOPPED | 0x09 | 通信已停止 |
RTE_E_HARDWARE_ERROR | 0x0A | 硬件错误 |
RTE_E_TRANSFORMER | 0x0B | Transformer 错误 |
RTE_E_Transformer_BUFFER_SIZE | 0x0C | Transformer 缓冲区大小错误 |
RTE_E_NEVER_RECEIVED | 0x0D | 从未接收到数据 |
RTE_E_OUT_OF_RANGE | 0x0E | 超出范围 |
RTE_E_PARTITION_NOT_READY | 0x0F | 分区未就绪 |
RTE_E_NULL_POINTER | 0x10 | 空指针 |
RTE_E_INVALID_ARGUMENT | 0x11 | 无效参数 |
RTE_E_SEG_FAULT | 0x12 | 内存段错误 |
RTE 错误根据严重程度分类：
+旁路（Bypass）支持快速原型（Rapid Prototyping, RP）——允许在 ECU 镜像生成后，通过旁路点插入用户代码以替代 SWC 的执行。
+ +旁路可由 RTE Generator 自动或手动注入到 Runnable 入口/出口。
+ +组件级包装——在 SWC 的所有 Runnable 入口/出口插入包装函数。
+ +提供 RTE 内部数据缓冲区的直接访问接口，允许 RP 工具直接读写。
+ +提供更细粒度的缓冲区访问控制（含权限、PostBuild 等）。分 7 个级别：
+基于服务的原型使用 Service Point 机制：
+数据转换（Data Transformation）在跨 ECU 通信与跨 OS-Application 通信时由 Transformer 链处理。
+ +跨 ECU 通信时，RTE 在发送前与接收后执行 Transformer 链。
+ +ECU 内部通信时 Transformer 链可省略以提升性能。
+ +Transformer 链是有序的 Transformer 序列：通常为 Serializor → ComBasedTransformer → E2ETransformer。
Transformer 链需要 RTE 分配的缓冲区。RTE 提供 Rte_Pim_<Port>_<DE>() 访问数据指针，Rte_IsUpdated() 检测有效性。
Transformer 的标准接口在 AUTOSAR_ASWS_TransformerGeneral 中定义。RTE 调用 Transformer 的 transform/transformer_error 回调。
Transformer 错误通过 TransformerErrorEvent 通知 SWC；返回 Rte_TransformerError 枚举值。
COM Based Transformer 使用 Com 序列化机制传输数据。
+ + + +RTE 支持的编程语言：
+Std_Types.h（来自 AUTOSAR_SWS_PlatformTypes）作为基础类型。RTE Generator 支持以下操作模式（影响生成代码行为）：
+RTE Generator 支持以下优化模式（影响生成代码体积与性能）：
+RTE Generator 支持多种构建：
+RTE 命名空间规则（避免符号冲突）：
+Rte_ 前缀；SchM_ 前缀；Rte_<SWCName>_ 前缀；RTE Generator 提供以下外部配置开关：
+--config-file=<path>：配置文件路径；--output-dir=<path>：输出目录；--optimize=performance|size|balanced：优化模式；--mode=normal|debug|trace：操作模式；--variant=precompile|linktime|postbuild：变体模式；--deterministic：确定性生成；--no-implicit：禁用隐式通信；--plugin-path=<path>：插件路径；--verbose：详细输出；--error-limit=N：错误上限。RTE 生成的符号使用唯一命名空间：
+Rte_ 前缀；SchM_ 前缀；Rte_<SWCName>_<FuncName>_ 前缀；Rte_<SWCName>_<TypeName>_ 前缀；Rte_<SWCName>_<MACRO_NAME>_ 前缀。直接 API 是高性能实现——RTE Generator 将 API 直接生成为宏或内联函数。例如：
+#define Rte_IRead_Runnable_Port_DE(var) (*(var) = Rte_data_DE)间接 API 使用函数调用+数据句柄。例如：
+Std_ReturnType Rte_Read_P1_De(P1_De_type* data) {
+ return Rte_data_handle_P1_De->read(Rte_instance_P1, data);
+}VariableAccess 是 AUTOSAR 4.x 引入的机制——通过 VariableAccess 而非端口访问数据。RTE 生成的 Rte_IRead/Rte_IWrite API 访问 VariableAccess 数据。
Per-Instance Memory 是同一 SWC 类型不同实例各自的独立内存。RTE Generator 为每个实例生成：
+struct LightCtrl_Instance {
+ /* Per-Instance variables */
+ uint8 status;
+ uint16 brightness;
+};
+extern struct LightCtrl_Instance LightCtrl_LeftLightCtrl;
+extern struct LightCtrl_Instance LightCtrl_RightLightCtrl;RTE 契约阶段输出 RTE Contract 描述（包含 API 映射约定）。
+ +RTE 生成阶段基于 RTE Contract 描述生成完整 API 实现。
+ +RTE Generator 可消除冗余函数调用（Function Elision）以优化性能。
+ +RTE API 命名约定：
+Rte_Read_<P>_<DE>、Rte_DRead_<P>_<DE>、Rte_Receive_<P>_<DE>；Rte_Write_<P>_<DE>、Rte_Send_<P>_<DE>、Rte_IWrite_<P>_<DE>；Rte_Call_<P>_<Op>、Rte_Result_<P>_<Op>；Rte_Trigger_<T>、Rte_IrTrigger_<T>；Rte_Mode_<P>_<M>、Rte_Switch_<P>_<MDG>_<M>；Rte_IrvRead_<Name>、Rte_IrvWrite_<Name>；Rte_Enter_<EA>、Rte_Exit_<EA>；Rte_CallBack_<Event>、Rte_Runnable_<Name>。RTE API 参数约定：
+const Type*）；Type*）；Rte_IFeedback* 提供额外反馈；Std_TransformerError* 提供 Transformer 错误；RTE API 返回 Std_ReturnType（定义见 Std_Types.h）：
E_OK (0x00)：操作成功；E_NOT_OK (0x01)：操作失败（具体原因见 5.5.1）；RTE_E_TIMEOUT）在 Rte.h 中定义。某些 RTE API 返回引用（Rte_Pim_<P>_<DE>()）以避免大结构体复制。
RTE API 错误处理：
+Rte_Result 转发给 Client；通过 Rte_IFeedback 结构提供额外反馈（isUpdated、source ECU 等）。
未连接端口的 Read API 返回 E_OK 但数据未更新；可通过 Rte_IsUpdated() 检测。
未连接模式切换端口的 Read API 返回默认模式。
+ +未连接 C/S 端口的 Call API 返回 RTE_E_UNCONNECTED。
+ +未连接外部触发端口的 Trigger API 不执行任何操作。
+ +PPort 与 RPort 端口接口不同时，RTE Generator 可生成转换代码（取决于 Compatibility 规则）。
RTE 头文件 Rte.h 包含所有 RTE API 声明、宏定义、类型定义。
Rte_Lifecycle.h 包含 RTE 生命周期 API：Rte_Start()、Rte_Stop()。
每个 SWC 有一个应用头文件 Rte_<SWCName>.h，包含：
Rte_Type.h 包含所有 ImplementationDataType 定义：
Rte_DataHandleType.h 包含数据句柄类型定义。
Rte_<SWCName>_Type.h 包含 SWC 内部类型定义。
Rte_Trace.h 包含 VFB 跟踪宏与 DLT Message ID 定义。
Rte_Cfg.h 包含 RTE 配置常量、宏定义。
主 RTE 源文件 Rte.c 与 Rte_Lib.c：
PostBuild 变体配置在 Rte_PBcfg.c 与 Rte_PBcfg.h 中。运行时通过 Rte_PBCon_*() 切换变体。
Rte_Instance 是 RTE 实例句柄类型，用于多实例场景。
每个 SWC 实例有一个 Component Data Structure：
+Std_ReturnType（来自 Std_Types.h）是 RTE API 的标准返回类型：
Rte_Instance 是 SWC 实例的运行时标识。
Rte_TransformerError 枚举 Transformer 错误：RTE_TRANSFORMER_OK、RTE_TRANSFORMER_BUFFER_SIZE、RTE_TRANSFORMER_HARDWARE_ERROR、RTE_TRANSFORMER_NOT_OK、RTE_TRANSFORMER_SERIALIZATION_ERROR、RTE_TRANSFORMER_E2E_ERROR 等。
RTE 模式类型定义（见 5.3.6.4）。
+ +RTE 中枚举类型的 C 实现。
+ +带范围限制的整数类型。
+ +位字段的压缩/解压缩转换。
+ +本节定义 38 类 RTE API 的完整签名、参数、返回值、错误码。详细签名见原文 5.6.1-5.6.38 节：
+| 编号 | API 类 | 功能 |
|---|---|---|
| 5.6.1 | Rte_Ports | 端口定义宏 |
| 5.6.2 | Rte_NPorts | 端口数量宏 |
| 5.6.3 | Rte_Port | 端口访问 |
| 5.6.4 | Rte_Write | 同步写（Sender→Com） |
| 5.6.5 | Rte_Send | 同步发送（Sender→Com） |
| 5.6.6 | Rte_Switch | 模式切换 |
| 5.6.7 | Rte_Invalidate | 数据失效 |
| 5.6.8 | Rte_Feedback | 反馈获取 |
| 5.6.9 | Rte_SwitchAck | 模式切换确认 |
| 5.6.10 | Rte_Read | 同步读（Receiver） |
| 5.6.11 | Rte_DRead | 显式读（Receiver） |
| 5.6.12 | Rte_Receive | 接收（Receiver） |
| 5.6.13 | Rte_Call | C/S 调用 |
| 5.6.14 | Rte_Result | C/S 结果 |
| 5.6.15 | Rte_Pim | 数据指针访问 |
| 5.6.16 | Rte_CData | 标定数据 |
| 5.6.17 | Rte_Prm | 参数 |
| 5.6.18 | Rte_IRead | Implicit 读 |
| 5.6.19 | Rte_IWrite | Implicit 写 |
| 5.6.20 | Rte_IWriteRef | Implicit 写引用 |
| 5.6.21 | Rte_IInvalidate | Implicit 失效 |
| 5.6.22 | Rte_IStatus | Implicit 状态 |
| 5.6.23 | Rte_IrvIRead | IRV Implicit 读 |
| 5.6.24 | Rte_IrvIWrite | IRV Implicit 写 |
| 5.6.25 | Rte_IrvIWriteRef | IRV Implicit 写引用 |
| 5.6.26 | Rte_IrvRead | IRV 读 |
| 5.6.27 | Rte_IrvWrite | IRV 写 |
| 5.6.28 | Rte_Enter | 进入 EA |
| 5.6.29 | Rte_Exit | 退出 EA |
| 5.6.30 | Rte_Mode | 读取当前模式 |
| 5.6.31 | Enhanced Rte_Mode | 增强模式读取 |
| 5.6.32 | Rte_Trigger | 触发 |
| 5.6.33 | Rte_IrTrigger | 可执行实体间触发 |
| 5.6.34 | Rte_IFeedback | Implicit 反馈 |
| 5.6.35 | Rte_IsUpdated | 检查是否更新 |
| 5.6.36 | Rte_PBCon | PostBuild 配置 |
| 5.6.37 | Rte_IsAvailable | 检查可用性 |
| 5.6.38 | Rte_SetAvailable | 设置可用性 |
每个 API 类的详细参数、错误码、宏展开、示例见原文 5.6.1-5.6.38 节（566-630 页）。翻译保留完整 API 分类与功能描述。
+ +可执行实体的引用与实现：
+Rte_Start API 用于启动 RTE。详细定义见原文 5.8.1.1-5.8.1.5（642-644 页）。
Rte_Stop API 用于停止 RTE。详细定义见原文 5.8.2.1-5.8.2.5（644-645 页）。
SWS_RTE 在第 6 章中给出大量序列图与时序说明。本 SWS 包含的序列图覆盖：
+第 7 章定义 RTE 的配置参数（ECUC），共约 80+ 配置容器与 200+ 配置参数。本 SWS 包含：
+本节列出来自 AUTOSAR_SRS_RTE 但在 SWS 中不直接对应的需求（标 N/A）。
本附录按用途分类列出 38 类 RTE API（详细见 5.6 节）。
+ +| API | 调用方 | 用途 |
|---|---|---|
Rte_Send_P_De() | Sender SWC | 同步发送（Buffering+Com） |
Rte_Write_P_De() | Sender SWC | 同步写（无 Com） |
Rte_Read_P_De() | Receiver SWC | 同步读 |
Rte_DRead_P_De() | Receiver SWC | 显式读（带 ack） |
Rte_Receive_P_De() | Receiver SWC | 接收（Queued） |
Rte_Invalidate_P_De() | Sender SWC | 显式失效 |
Rte_IsUpdated_P_De() | Receiver SWC | 检查是否更新 |
| API | 用途 |
|---|---|
Rte_IRead_P_De() | Implicit 读（共享内存） |
Rte_IWrite_P_De() | Implicit 写 |
Rte_IWriteRef_P_De() | Implicit 写引用 |
Rte_IInvalidate_P_De() | Implicit 失效 |
Rte_IStatus_P_De() | Implicit 状态 |
| API | 调用方 | 用途 |
|---|---|---|
Rte_Call_P_Op() | Client | 同步调用 |
Rte_Call_P_Op_Async() | Client | 异步调用 |
Rte_Result_P_Op() | Client | 读取异步结果 |
| API | 调用方 | 用途 |
|---|---|---|
Rte_Switch_P_M() | Mode Manager | 切换模式 |
Rte_Mode_P_M() | Mode User | 读取当前模式 |
Rte_SwitchAck_P_M() | Mode User | 确认模式切换 |
| API | 调用方 | 用途 |
|---|---|---|
Rte_Trigger_T() | Sender | 触发事件 |
Rte_IrTrigger_T() | Runnable | 可执行实体间触发 |
| API | 用途 |
|---|---|
Rte_IrvRead_Name() | 读 IRV |
Rte_IrvWrite_Name() | 写 IRV |
Rte_IrvIRead_Name() | Implicit 读 IRV |
Rte_IrvIWrite_Name() | Implicit 写 IRV |
Rte_IrvIWriteRef_Name() | Implicit 写引用 IRV |
| API | 用途 |
|---|---|
Rte_Enter_EA() | 进入 EA |
Rte_Exit_EA() | 退出 EA |
| API | 用途 |
|---|---|
Rte_CData_P_C() | 读标定参数 |
Rte_Prm_P_P() | 读参数（ParameterComponent） |
| API | 用途 |
|---|---|
Rte_Ports() | 端口定义宏 |
Rte_NPorts() | 端口数量宏 |
Rte_Port() | 端口访问 |
| API | 用途 |
|---|---|
Rte_Start() | 启动 RTE |
Rte_Stop() | 停止 RTE |
| API | 用途 |
|---|---|
Rte_PBCon_*() | 运行时切换变体 |
| API | 用途 |
|---|---|
Rte_Feedback() | 获取反馈 |
Rte_IFeedback() | 获取 Implicit 反馈 |
Rte_IsAvailable() | 检查可用性 |
Rte_SetAvailable() | 设置可用性 |
Rte_Pim() | 数据指针访问 |
本附录列出 SWS_RTE 使用的所有缩略语（已在 1.3 节给出主表）。补充缩写：
+| 缩略语 | 英文全称 | 中文释义 |
|---|---|---|
| ARXML | AUTOSAR XML | AUTOSAR XML 描述格式 |
| Asr | AUTOSAR | AUTOSAR 标准 |
| BSWMD | Basic Software Module Description | 基础软件模块描述 |
| ComM | Communication Manager | 通信管理器 |
| Dem | Diagnostic Event Manager | 诊断事件管理器 |
| Dlt | Diagnostic Log and Trace | 诊断日志与跟踪 |
| EA | Exclusive Area | 独占区 |
| ECUC | ECU Configuration | ECU 配置 |
| EOC | End of Init Callout | 初始化完成回调 |
| IRV | Inter-Runnable Variable | 可执行实体间变量 |
| MCF | Measurement & Calibration Format | 测量与标定格式 |
| MDG | Mode Declaration Group | 模式声明组 |
| MM | Mode Manager | 模式管理器 |
| MU | Mode User | 模式使用者 |
| OCB | OSEK Compliance Class | OSEK 兼容类（优先级继承） |
| PCP | Priority Ceiling Protocol | 优先级天花板协议 |
| PRPort | Provider/Receiver Port | 提供/接收双向端口 |
| RP | Rapid Prototyping | 快速原型 |
| RPT | Rapid Prototyping Tool | 快速原型工具 |
| SchM | Basic Software Scheduler | 基础软件调度器 |
| SP | Service Point | 服务点 |
| ST | Schedule Table | 调度表 |
| TI | Transformation Interface | 转换接口 |
| WCET | Worst Case Execution Time | 最坏情况执行时间 |
| XCP | Universal Measurement and Calibration Protocol | 通用测量与标定协议 |
校对轮次：L1 自动校对（2026-06-13）
+Rte_Send_/Rte_Read_/Rte_Call_/Rte_IrvRead_/Rte_Enter_/Rte_Switch_/Rte_Trigger_/Rte_Pim_/Rte_IRead_/Rte_IWrite_/Rte_CData_/Rte_Prm_ 等 38 类）原样保留；OS 对象名（OsTask/OsEvent/OsResource/OsSpinlock/OsIOC/OsCounter/OsScheduleTable/OsAlarm/OsISR）原样保留；BSW 调度器 API（SchM_Init/DeInit/Enter/Exit）原样保留；错误码（RTE_E_OK/_INVALID/_PORT_DISABLED/_UNCONNECTED/_LIMIT/_LOST_DATA/_TIMEOUT/_IN_EXCLUSIVE_AREA/_NESTING_EXCLUSIVE_AREA/_COM_STOPPED/_HARDWARE_ERROR/_TRANSFORMER/_TRANSFORMER_BUFFER_SIZE/_NEVER_RECEIVED/_OUT_OF_RANGE/_PARTITION_NOT_READY/_NULL_POINTER/_INVALID_ARGUMENT/_SEG_FAULT 共 19 个）原样保留；Transformer 错误码（Rte_TransformerError/RTE_TRANSFORMER_OK/_BUFFER_SIZE/_HARDWARE_ERROR/_NOT_OK/_SERIALIZATION_ERROR/_E2E_ERROR）原样保留；VFB 跟踪宏与 DLT Message ID 原样保留。Std_ReturnType/E_OK/E_NOT_OK/Rte_Instance/Rte_TransformerError/Std_TransformerError/Rte_IFeedback 等核心类型完整翻译；ImplementationDataType 分类（Primitive/Array/Structure/Union/Pointer/Enumeration/Range/Bitfield 等 7+ 类）完整翻译。ECUC_Rte_*），翻译中给出概念性总结。③ 第 6 章序列图（约 30+）以描述形式覆盖，未逐图翻译时序细节。④ 第 4 章子节细节（如 4.3.1.11 "Operation" 中的具体时序图）保留原图编号，文字描述完整。AUTOSAR 运行时环境（Run-Time Environment, RTE）是 AUTOSAR VFB（虚拟功能总线）针对特定 ECU 的具体实现。RTE 提供应用软件组件（SW-C）间通信的基础设施服务，并促进 SW-C 对基础软件组件（包括 OS）的访问。
+RTE 包含两个文档：
+2 / 2 篇完成（100%）。P1 RTE 全部完成。P1 整体 15/15（100%）。下一步：阶段 2（P5 ModeManagement + Safety 13 篇）。
+ +优先返工 P1 中两篇 D 级不达标文档（TimeService、FreeRunningTimer），随后按编号顺序完成 P1 剩余 11 篇（SystemServices 9 篇 + RTE 2 篇），全面修复校对日志与索引。
+P1 全部完成（15/15）！按 🗓️ 翻译计划，下一阶段为 P5 ModeManagement + Safety（13 篇，预计 7 天）。详见 PLAN.html §3.2。