AUTOSAR_SRS_RTE 中文翻译

[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: –

⌋()

[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: –

⌋()

[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: –

⌋()

[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: –

⌋()

[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: –

⌋()

[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: –

⌋()

[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__Init()。

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_(); ... Rte_Exit_();。

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_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: –

⌋()