1. 实验背景与目标拆解1.1 这个实验到底在做什么手头这个AUTOSAR实验十二核心任务是通过SWCSoftware Component软件组件的C/S端口Client/Server Port客户端/服务器端口来控制LED点亮与熄灭。很多初学者第一次听到“C/S端口”会误以为它和网络编程里的Client/Server是一回事其实在AUTOSAR语境下这个概念要落地得多——它本质上是给软件组件之间定义了一种调用与被调用的关系一个组件作为客户端去“请求”服务另一个组件作为服务器去“响应”这个请求。放在本实验的场景里最直观的业务逻辑就是上层应用组件SWC想要控制LED于是它通过C/S端口去调用底层驱动组件提供的接口比如Led_SetState(uint8 state)底层组件接收到这个请求后真正去操作寄存器、拉高或拉低GPIO引脚从而点亮或熄灭LED。这个实验最有价值的地方不是LED本身而是它完整地串联起了AUTOSAR方法论中从“架构设计”到“代码生成”再到“硬件验证”的全链路。你可能已经做过前面几个实验比如通过RTERuntime Environment运行时环境直接操作S/RSender/Receiver发送者/接收者端口来传递数据但C/S端口是完全不同的一套通信范式它解决的是“函数调用关系如何在AUTOSAR架构中建模和落地”的问题。1.2 适合谁来参考这个实验的内容跨度比较大我按经验把受众分成三类高校正在上AUTOSAR课程的学生实验指导书里往往只有操作步骤和截图缺乏“为什么要这么做”的底层解释。这篇文章会把C/S端口的原理、RTE生成机制、底层函数调用链路都串起来帮你应付实验报告里的思考题。刚进入汽车电子行业、接触AUTOSAR工具链的初级工程师在公司项目里你大概率不会亲手从零配置C/S端口但你会阅读别人的ARXML配置文件会遇到“为什么这个函数调用被映射成了RTE事件”之类的问题。这篇文章能帮你建立起从模型到代码的映射认知。自学AUTOSAR、手头有开发板但缺少系统资料的自学者我会把实验步骤拆得很细尽量做到你拿到一个支持AUTOSAR的板子和工具链就能照着操作。一句话总结这个实验的终点不是“LED亮了”而是你真正理解了一个服务调用在AUTOSAR分层架构里走完了一条什么样的路。2. C/S端口通信机制深度解析2.1 为什么需要C/S端口它和S/R端口的本质区别在AUTOSAR架构里软件组件之间的交互主要有两种模式S/R端口发送者/接收者和C/S端口客户端/服务器。很多初学者搞不清什么时候用哪种我拿生活场景打个比方。S/R端口像**“广播电台”**发送者只管把数据播出去它不关心有没有人在听、听众是谁、听完之后要干什么。接收者被动地接收数据收到就更新自己的状态。这种模式适合传感器数据分发——比如车速信号多个组件都需要这个数值发送者广播一次谁需要谁去订阅。C/S端口像**“打电话叫服务”**客户端主动拨号调用接口服务器接听后执行操作并返回结果。这是一种同步的、有去有回的交互模式。它适合控制类操作——比如本例中的LED控制客户端调用了Led_SetState服务器执行完才能返回客户端甚至可能关心返回值比如操作是否成功。用一张表格来看两种模式的本质差异对比维度S/R端口发送者/接收者C/S端口客户端/服务器通信方向单向数据流发送者到接收者双向请求与响应同步性异步发送者不等待接收者同步客户端阻塞等待返回值也可配置为异步应用场景数据分发、状态广播函数调用、服务请求、控制操作典型接口Rte_Read_xxx,Rte_Write_xxxRte_Call_xxx,Rte_Result_xxx数据粒度数据本身操作 参数 返回值2.2 C/S端口的关键角色Require端和Provide端在AUTOSAR的软件组件模板Software Component Template里C/S通信涉及两个角色Require侧需求端声明“我需要调用某个服务”。在组件端口配置中这个端口类型是CSenderReceiver或更精确地说是CPortClient Port。它定义了客户端要调用的操作集合Operation以及每个操作的签名——参数列表和返回值。Provide侧供应端声明“我提供服务”。端口类型是SPortServer Port。它实现了操作的具体逻辑通常对应到底层驱动函数。两个组件的端口通过Connector连接器在软件架构层面连接起来。这个连接关系在RTE生成阶段会转化为函数指针或直接调用关系。关键点是在AUTOSAR架构图中客户端组件和服务端组件存在明确的依赖关系——客户端依赖服务器提供服务服务器的内部细节对客户端完全透明。本实验中通常会有两个SWC应用逻辑组件比如叫LedController或App_LedControl它有个C/S的Require端口定义了Led_SetState操作。底层驱动组件比如叫LedDriver或EcuAb_Led它有个C/S的Provide端口实现了Led_SetState这个操作真正去操作I/O寄存器。如果项目的ECU抽象层已经预置好了LED驱动的服务器组件那么你只需要在应用组件里配置Require端口然后在工具里把两个端口连起来即可。如果没有现成的服务器组件那就需要自己新建一个并实现操作函数。2.3 操作映射的底层原理RTE如何把调用“接”起来到这里很多同学会好奇一个问题在生成的代码里客户端组件调用Rte_Call_Led_SetState(1)这个函数怎么知道要找谁这就要提到RTE生成器的核心工作了。RTERuntime Environment是AUTOSAR架构中连接应用软件组件和基础软件BSWBasic Software的“高速公路”。对于C/S通信RTE生成代码时主要做了三件事为客户端生成Rte_Call接口根据客户端的Require端口定义生成原型为Std_ReturnType Rte_Call_端口名_操作名(参数列表)的API函数。建立调用路由在生成的rte.c文件中这个Rte_Call函数内部会根据连接器的配置找到服务器组件提供的函数指针或实际函数名并执行调用。处理返回值服务器的执行结果会通过返回值传回客户端。如果配置了超时或错误处理还会返回类似RTE_E_OK或RTE_E_COM_BUSY之类的状态码。举一个简化但真实的例子假设LedController组件的Require端口名为LedPort操作名为Led_SetState那么RTE生成的客户端API可能是Std_ReturnType Rte_Call_LedPort_Led_SetState(uint8 state) { /* RTE内部根据连接关系找到实际函数并调用 */ return LedDriver_StateChange(state); }这里的LedDriver_StateChange就是服务器组件实现的服务函数。在代码生成阶段RTE直接把这个函数名“焊死”在了Rte_Call的实现里。如果后续你在架构工具里改了连接关系重新生成RTE这个映射会随之更新。理解了这一点你就能明白为什么AUTOSAR能带来“软硬件解耦”了。应用层组件的代码里根本不需要知道LED底层是用的哪个GPIO、哪个寄存器、甚至不需要知道是用的什么芯片它只需要“知道”自己可以调用Led_SetState这个接口就够了。底层换芯片没关系只要服务器组件重新实现Led_SetState的内部逻辑接口签名保持不变上层代码一行都不用改。3. 实验环境与工具链准备3.1 硬件环境参考AUTOSAR实验常用的硬件平台有两类。第一类是英飞凌AURIX系列开发板TC233、TC277、TC297等这是汽车电子行业最主流的MCU平台之一第二类是瑞萨RH850系列开发板在某些日系供应链里很常见。LED控制实验对硬件要求不高核心是开发板上至少有一个可控的LED灯最好能够通过跳线或拨码开关选择LED所连接的GPIO引脚方便实验中验证不同引脚配置的效果。如果你用的是带有板载调试器的开发板比如英飞凌的KIT_AURIX_TC277_TFT那就不需要额外的调试器了。3.2 软件工具链选型这一节可能是很多自学者的“拦路虎”因为AUTOSAR的工具链不便宜主流工具对个人开发者几乎没有免费版本。我在实验和项目中最常用的是以下组合AUTOSAR建模和配置工具常用的是ETAS的ISOLAR、Vector的DaVinci Developer、Elektrobit的EB tresos。本实验涉及SWC的建模和端口配置首选支持软件组件模板编辑的工具比如ISOLAR或DaVinci Developer。RTE生成器通常集成在上述工具链中。以Vector为例RTE生成器是DaVinci GeneratorEB则是EB tresos的RTE模块。编译器与调试器如果使用英飞凌AURIX常用的编译器是HighTec或TaskingIDE则是AURIX Development Studio免费或者英飞凌的Dave CE。MCAL配置工具对于LED控制实验你至少需要配置一个GPIO端口作为输出。MCAL层通常由芯片厂商提供配合EB tresos或供应商自己的配置工具使用。在本实验中LED驱动组件通常直接操作寄存器也可以不依赖完整的MCAL直接通过操作寄存器的方式实现这样可以使实验难度降低一个量级。注意工具链的版本兼容性问题非常折磨人。AUTOSAR的规范版本有4.0、4.2、4.3、4.4等不同版本下ARXML文件的schema差异较大。实验前务必确认你的建模工具、RTE生成器、MCAL配置工具使用的是同一个AUTOSAR版本。3.3 搭建项目的目录结构一个典型的AUTOSAR SWC实验项目目录结构大致如下├── config/ # 工具生成的配置文件ARXML │ ├── SWC.arxml │ ├── System.arxml │ └── Rte.arxml ├── generated/ # RTE生成代码 │ ├── include/ # Rte_Type.h, Rte.h, Rte_Component.h 等 │ └── src/ # Rte.c, 组件骨架代码 ├── swc/ # 用户编写的SWC源码 │ ├── LedController/ # 应用组件实现 │ └── LedDriver/ # 服务器组件实现 ├── mcal/ # MCAL驱动GPIO等 └── build/ # 编译脚本和产物这个结构不一定非要完全一样但建议把“工具生成的代码”和“手写的代码”分开目录管理。原因很简单RTE生成代码在重新生成时会被覆盖如果你手动改了里面的内容下次生成全部丢失。分开管理能帮你少踩一个大坑。4. 实验步骤全流程解析4.1 第一步创建软件组件并定义端口打开你的AUTOSAR建模工具我用ISOLAR的界面举例不同工具大同小异执行以下操作新建一个软件组件类型命名为LedController类型选择APPLICATION_SW_COMPONENT应用软件组件。在这个组件内部新建一个C/S端口即Client/Server Port。工具的界面中通常会有“Add Port”或“Create Port”的按钮端口类型选择C/S。端口方向选择Require即作为客户端。如果你使用的是以“端口名”为对象配置的方式可能还需要进一步选择端口类型是CClient还是SServer这里选择Client。为端口定义接口这里需要新建一个C/S接口ClientServerInterface命名如Led_CS_Interface在该接口中添加一个操作Operation命名为Led_SetState。为操作定义参数一个参数state类型为uint8方向为IN输入参数。如果有需要还可以定义一个返回值类型为Std_ReturnType用于表示操作执行是否成功。与此同时需要为服务器组件做类似的配置新建软件组件类型LedDriver类型可以是APPLICATION_SW_COMPONENT或ATOMIC_SW_COMPONENT。在仿真或实验场景中把它当作应用组件即可。新建一个C/S端口方向选择Provide即作为服务器端口接口选择同样的Led_CS_Interface。提示接口一定要“同一份”。两个端口如果各自定义了一份同名但不同的接口工具会在连接时提示不兼容。做实验时经常遇到连不上、编译报错的情况多半是接口不一致导致的。4.2 第二步连接端口并生成RTE在软件架构视图中将LedController组件的Require端口和LedDriver组件的Provide端口用连接器连起来。在绝大多数工具里这个操作就是一条线拉过去工具会提示两端接口匹配。接下来配置RTE属性。在C/S通信中有一个关键的配置项叫**“RTE可重入性”和“同步/异步调用”**同步调用Synchronous客户端调用Rte_Call后RTE会直接执行服务器函数直到函数返回才把结果交给客户端。这是默认的、也是本实验推荐的模式简单、行为可预期。异步调用AsynchronousRTE把调用请求放进一个队列或任务中客户端不等待轮询或等待回调来获取结果。这种模式更复杂适合耗时较长的服务比如需要访问总线或执行较长的算法。对LED控制这种微秒级的操作完全用不着异步选同步即可。同步调用的好处是时序上确定——调用一返回LED状态就已经生效了。配置完成后运行RTE生成器。生成的代码中有几个关键文件需要重点关注Rte.hRTE的主头文件定义了主要的数据类型和接口。Rte_Type.hAUTOSAR数据类型定义包括Std_ReturnType、uint8等。Rte_LedController.h组件LedController的头文件里面有Rte_Call_LedPort_Led_SetState的声明。Rte_LedDriver.h组件LedDriver的头文件里面有服务器端需要实现的函数原型比如LedDriver_Led_SetState。Rte.cRTE实现文件包含了调用路由、连接逻辑等核心代码。4.3 第三步实现人机交互逻辑在生成的骨架代码中工具通常会在组件源文件里预留出函数实现的位置。LedController组件的骨架中会有一个RunnableEntity通常是周期性调用Periodic或由事件触发如每10ms或100ms触发一次。在这个Runnable里实现LED控制逻辑。实验中最简单直观的场景是根据某个变量或按键状态来点亮或熄灭LED。既然是纯软件实验我用一个计数变量来模拟/* 在LedController.c中 */ static uint8 LedState 0; static uint16 ToggleCounter 0; void LedController_Periodic(void) { Std_ReturnType ret; ToggleCounter; if (ToggleCounter 100U) { ToggleCounter 0U; /* 翻转LED状态 */ LedState (LedState 0U) ? 1U : 0U; /* 通过C/S端口调用服务器组件提供的服务 */ ret Rte_Call_LedPort_Led_SetState(LedState); if (ret ! RTE_E_OK) { /* 处理调用失败的情况例如记录错误或置默认值 */ } } }这段代码的逻辑是每100个周期翻转一次LED状态并调用C/S接口把新状态发送给服务器组件。注意在真实的AUTOSAR工程中RTE生成时会对Runnable的周期和优先级进行配置。在ISOLAR中这个周期在“RTE Events”选项卡中设置本实验设置成10ms或100ms均可。4.4 第四步实现服务器端的驱动逻辑LedDriver组件的任务就是真正操作LED。如果是独立开发板最底层的实现通常要操作GPIO寄存器。以英飞凌AURIX TC277为例一个简化的实现大致如下/* 在LedDriver.c中 */ #include IfxPort.h #include IfxPort_reg.h #define LED_PIN IfxPort_P00_5 #define LED_MODULE MODULE_P00 void LedDriver_Led_SetState(uint8 state) { if (state 0U) { /* 熄灭LED拉低引脚 */ IfxPort_setPinState(LED_MODULE, LED_PIN, IfxPort_State_low); } else { /* 点亮LED拉高引脚 */ IfxPort_setPinState(LED_MODULE, LED_PIN, IfxPort_State_high); } }如果你用的不是AURIX而是其他MCU思路完全一样找到板载LED对用的GPIO端口和引脚号通过寄存器操作或HAL库函数控制电平输出。这里有一个在实验中常踩的坑LED是高电平点亮还是低电平点亮。很多开发板的LED电路是共阳极接法MCU引脚输出低电平时LED才亮。如果你按高电平点亮写了代码结果会发现LED完全不响应或者逻辑反了。建议在动手前查一下开发板的原理图或者用万用表量一下引脚在测试状态下的电平。4.5 第五步配置RTE事件和编译运行在LedController组件的Runnable配置中添加一个周期事件Periodic Event周期设为10ms或100ms绑定到LedController_Periodic这个Runnable。接下来配置链接脚本和编译选项把生成代码和手写代码一起编译链接。AURIX平台通常用HighTec编译器编译命令大致是# 伪命令行示例具体以你的IDE和工具链为准 hightec-elf-gcc -c LedController.c -I generated/include -I swc hightec-elf-gcc -c LedDriver.c -I generated/include -I mcal hightec-elf-gcc -c Rte.c -I generated/include hightec-elf-ld -T link.ld -o led_control.elf *.o烧录到开发板后观察到LED周期性地闪烁实验就算跑通了。4.6 实验现象与预期的行为如果你按照10ms周期100次计数翻转那么LED应该是大约每1秒10ms×100切换一次状态。这是一个很直观的“心跳灯”效果。如果LED没有反应先别急着怀疑RTE和组件配置按下面顺序排查用示波器或万用表量引脚有没有电平变化。在LedDriver_Led_SetState函数里加一个断点确认函数有没有被调用。检查返回值和RTE生成的调用路由确认客户端确实连到了服务器端。5. 常见问题排查与实操建议5.1 C/S端口连接不上的原因分析我在带学生做实验时遇到最多的一个问题就是在架构图里明明端口已经连了线但RTE生成器报错说找不到匹配的接口或者没有连接器。排查这类问题从三个层面入手接口ID是否一致两个端口虽然看起来是同一个接口但ARXML里记录的UUID可能不同。这通常是操作时不小心新建了一份同名接口造成的。在ISOLAR或DaVinci里打开接口定义确认两个端口引用的是同一个接口对象。端口类型是否匹配C/S端口里Require端口和Provide端口必须是同一接口的“互补”关系。如果你的工具把端口类型做成了两个独立的原子端口一个只有Provide操作一个只有Require操作需要通过连接器把它们绑在一起。组件接口在System文件里是否完整在AUTOSAR的System模板中SwcToSwcConnection或AssemblySwConnector必须显式定义。有些工具导出System ARXML时如果只导出了组件定义没有把组件实例和连接器导出来RTE生成器就找不到连接关系。5.2 Rte_Call返回值一直报错有些同学在调用Rte_Call_LedPort_Led_SetState时发现返回值一直是RTE_E_COM_BUSY或者RTE_E_UNCONNECTED。RTE_E_UNCONNECTED表示客户端端口没有连接到任何服务器端口。首先检查连接器是否真的存在。其次检查RTE配置中是否为这个连接生成了一条Rte_Connection实例。如果连接器存在但RTE没有生成通常是ARXML版本不一致导致的——建议重新生成一次或者检查工具的版本兼容性。RTE_E_COM_BUSY在异步调用中常见RTE的请求队列满了或者上一次请求未完成。同步调用模式下这个错误很少出现。如果出现了多半是配置中把调用模式配成了异步而后台的事件处理没有跑起来。解决方法是把调用模式改为同步或者把处理异步结果的事件Result事件配置正确。5.3 RTE生成代码和手写代码的“覆盖”问题我在实验中反复强调过目录要分开代码不要乱改生成部分。但总有同学手痒觉得生成代码不够个性化手动改了Rte.c或Rte.h里的东西。结果重新生成的时候所有改动全被覆盖项目直接编译不过。给一个我这里一直沿用的实操建议工具的生成目录设置成只读或干脆用脚本在生成后自动清理。手写代码只放在用户目录里通过#include的方式引用RTE头文件。如果你确实需要修改RTE生成的部分行为优先使用配置项而不是修改生成的代码。AUTOSAR工具链提供了很多钩子Hook和配置选项基本能覆盖绝大多数需求。5.4 服务器函数没有执行但LED正常还有一种让人摸不着头脑的场景LED看上去在正常闪烁但你在LedDriver_Led_SetState里打断点却根本打不到。这种情况通常是另一个组件或裸机代码在直接操作GPIO。很多开发板出厂自带的bootloader或者演示代码会周期性地设置LED引脚。遇到这种问题先检查是否有其他应用在跑尤其是调试器连接后可能存在多个CPU核心同时运行的情况。把无关的代码屏蔽掉只保留本实验相关的任务。5.5 连接器类型选择和TLPThread Level Parallelism配置如果你的工具链支持多核配置比如AURIX的TriCore是多核芯片那么在C/S连接中还有一个隐藏但重要的配置项连接器的映射核。客户端组件和服务器组件如果被分配到不同的核上RTE生成时会有特殊处理——要么通过核间通信机制IOCInter-OSApplication Communication传递要么需要配置为跨核调用。对实验场景来说建议最开始把所有组件都放到同一个核上等实验跑通了再尝试跨核配置以理解AUTOSAR的分布式通信机制。这个从简单到复杂的路径能帮你避免一上来就被跨核通信的各种时序问题搞晕。6. 实验之外的思考6.1 从LED控制到真实项目C/S端口在量产代码中的典型用法实验做完了LED闪了但很多同学会困惑C/S端口在真实量产项目里到底用在哪些场景我用实际项目的经验来举例。在车身控制器BCM项目中C/S端口最常见的用法之一就是诊断服务的调用接口。诊断层比如UDS模块作为一个服务器组件提供ReadDTC()、ClearDTC()、SetSession()等操作。上层应用组件需要读取故障码时通过C/S接口调用这些操作。诊断模块内部再向下访问故障码存储模块。另一个典型场景是电池管理系统BMS里的SOC估算服务。BMS核心算法组件作为一个服务器提供GetSOC()接口仪表盘显示组件和整车控制器分别作为客户端周期性调用GetSOC()来获取电池剩余电量。如果使用S/R端口也能实现数据广播为什么用C/S因为SOC估算服务需要响应“请求”语义可能需要传入参数比如温度修正系数并返回结果C/S更语义化。这些场景的共同点是调用方需要主动发起请求且通常关心调用的结果成功/失败。这就是C/S端口最核心的价值。6.2 C/S端口与函数指针、直接调用的关系有的读者可能会想这不就是函数调用吗为什么非要绕一圈通过RTE这个问题的答案恰恰是AUTOSAR的精髓所在。AUTOSAR不是不能让应用层直接调用驱动层而是要保证架构的“可演进性”和“可配置性”。直接函数调用在单片机的裸机开发里是常态但带来的问题是应用代码和应用代码之间、应用和驱动之间强耦合代码没法复用。更换MCU或驱动芯片时上层代码全部要改。无法做到“架构配置”级别的灵活组装。RTE变成了一个中间层它在编译期根据配置生成调用关系。你换一块芯片只需要更换底层驱动组件实现重新生成RTE应用层代码一行都不需要动。这就是为什么OEM整车厂愿意在AUTOSAR上投入大量资源——它能支持“同一个软件组件在不同车型上复用”节省的成本是巨量的。6.3 时序和性能的考虑C/S同步调用在嵌入式实时系统里有一个必须注意的副作用调用方会阻塞等待。如果服务器组件里的函数执行时间过长比如内部有复杂的计算或者访问了慢速总线会直接影响客户端任务的周期。实际项目中C/S调用的服务器函数通常会遵循一个黄金法则做尽量少的事把耗时的事情让给别人。比如Led_SetState这个函数底层驱动只需要写一个寄存器几个时钟周期的事情可以放心同步调用。但如果服务器函数内部要做I2C通信读取外部传感器并等待响应这就有风险了——I2C通信可能耗掉几百微秒甚至几毫秒这会让客户端任务卡顿。遇到这种场景应该怎么设计两个方向一是改用异步调用客户端发完请求先干别的晚点再查结果二是把耗时操作拆分成“启动完成通知”两个阶段服务器组件内部用状态机管理。后者在AUTOSAR中通常配合BSW的异步回调机制实现复杂度会高不少。本实验的LED控制简单不需要考虑这些但一旦你进入真实项目这些“为什么”就会变得至关重要。7. 实验扩展建议实验如果做得顺利我还建议你花点时间做以下几个扩展把C/S端口的理解加深一层扩展一增加一个返回值和错误处理。为Led_SetState增加一个返回值比如返回RTE_E_OK时表示执行成功返回RTE_E_INVALID_PARAMETER时表示参数非法。在客户端组件里针对不同的返回值做不同的处理。这样可以理解AUTOSAR中的错误传播模式。扩展二尝试从两个客户端调用同一个服务器操作。新建一个组件也创建一个Require端口连接到同一个LedDriver的服务器端口上。看看RTE生成的调用路由是否会有竞争保护机制思考一下同步调用场景下是否需要互斥。这是理解RTE保护和可重入性设计的好入口。扩展三切换成异步调用模式。在RTE配置中把调用模式改成异步观察生成的Rte_Call_xxx和Rte_Result_xxx结构的差异以及任务代码需要怎么响应。这个扩展能让你经验敏锐地理解AUTOSAR的“非阻塞调用”机制。扩展四观察生成的ARXML文件。用文本编辑器打开生成的ARXML找到CLIENT-SERVER-INTERFACE、P-PORT、R-PORT、ASSEMBLY-SW-CONNECTOR这些关键标签对比你在工具里做的配置。很多人只有在ARXML层面看到过这些XML结构才能真正理解AUTOSAR配置的本质。8. 踩坑总结与个人体会做完这个实验我个人最大的体会是AUTOSAR实验的难度从来不在代码本身而在“配置-生成-编译”这条链路的闭环理解。LED控制逻辑用裸机C语言写可能30行代码就搞定了。但当你把同样的功能拆解成“客户端组件-接口-服务器组件-RTE-驱动”这么一条链路时每一层都有了明确的边界和职责这带来的架构优势是需要你真正动手做过之后才能感受到的。还有一个小技巧分享在调试C/S通信问题时把RTE生成的头文件和源文件全都展开用IDE的“查找所有引用”功能搜索Rte_Call_LedPort_Led_SetState的实现顺着代码走一遍调用路径。这一步能直观地看到RTE到底做了什么。很多AUTOSAR初学者会害怕阅读生成的代码觉得那些代码晦涩难懂但恰恰是这些代码才是连接“模型”和“硬件”的桥梁。再补充一个很多人容易忽略的点实验报告里多画几张时序图。画清楚“客户端任务周期-调用发生时刻-服务器执行窗口-LED状态切换时刻”这四者的关系对你理解AUTOSAR的调度模型帮助巨大。这比在报告里多写十行文字都管用。如果你做这个实验时用的是开发板建议留着实验环境后续实验比如通过CAN通信控制LED大概率还能复用硬件平台和一部分组件设计。在架构层面把组件划分做好了后面的实验基本就是加端口、加连接、加配置的工作了。
