3. AUTOSAR软件组件与Stateflow映射
在AUTOSAR开发流程中，Stateflow并不是孤立存在的图形工具，它最终要落到某个软件组件（SWC）内部，成为某个Runnable实体的实现载体。理解“SWC类型—Runnable—IRV/参数—Stateflow图表”这条映射链，是后续建模与代码生成能否顺利推进的前提。本节围绕这条链展开，重点说明每一层该做什么选择、这些选择如何影响Stateflow图表的组织方式。
一、先选SWC类型：Application、Sensor/Actuator、Service
AUTOSAR把软件组件按职责划分为几类，常见的有应用软件组件（Application SWC）、传感器/执行器软件组件（Sensor/Actuator SWC）、服务软件组件（Service SWC）以及复合组件（Composition）。选择哪一类，直接决定了Stateflow图表中允许出现哪些端口和访问方式。
Application SWC承载控制逻辑，通常通过Sender/Receiver端口或Client/Server端口与其它组件交互，是Stateflow图表最常落脚的容器。Sensor/Actuator SWC负责把底层IO信号抽象为AUTOSAR信号，它往往直接访问IO硬件抽象，Stateflow在其中更多承担信号预处理或状态判定。Service SWC提供跨组件服务，例如诊断、存储管理，其Runnable常由BSW回调触发，Stateflow用于实现服务状态机。复合组件本身不实现逻辑，只做组件装配，因此不在其中放置Stateflow图表。
选择原则可以概括为：逻辑归Application，硬件抽象归Sensor/Actuator，公共服务归Service。如果一段状态逻辑既涉及控制算法又直接读写IO，应拆分为两个组件，而不是把IO访问塞进Application SWC的Stateflow里。
二、Runnable实体：Stateflow图表的宿主
Runnable是SWC内部可被调度执行的最小实体，它由RTE触发，触发方式包括周期触发（TimingEvent）、数据接收触发（DataReceivedEvent）、操作调用触发（OperationInvokedEvent）以及初始化/关闭等模式切换事件。一个SWC可以包含多个Runnable，每个Runnable对应一个入口函数，代码生成后就是Rte_Runnable_<SWC>_<Runnable>() 这样的形式。
Stateflow图表必须挂在一个Runnable之下。也就是说，在Simulink模型中，Stateflow Chart通常作为某个Function-Call Subsystem或某个Runnable对应的模型区域内的子系统存在。Runnable的类型决定了Stateflow图表的执行时机：周期Runnable中的Stateflow按固定步长推进；DataReceivedEvent触发的Runnable中的Stateflow只在数据到达时执行一次；OperationInvokedEvent触发的Runnable中的Stateflow则响应服务调用。
因此，在建模前应先明确：这段状态逻辑需要多快响应？是周期执行还是事件驱动？是否需要在初始化时复位？这些问题的答案决定了Runnable的触发类型，也决定了Stateflow图表中是否需要显式的初始化入口。
三、IRV与参数：Stateflow与AUTOSAR数据模型的接口
Stateflow图表内部的数据对象需要与AUTOSAR数据模型建立对应关系，主要涉及两类：IRV（Inter-Runnable Variable，Runnable间变量）和参数（Parameter）。
IRV用于同一SWC内多个Runnable之间传递数据。例如，一个Runnable负责采集并计算，另一个Runnable负责输出，两者之间通过IRV共享中间结果。IRV在AUTOSAR中属于SWC内部变量，不经过RTE端口，因此不会出现在组件的外部接口上。在Stateflow中，IRV通常映射为Data Store Memory或Simulink.Signal对象，并配置为与AUTOSAR IRV对应的存储类。
参数则是标定或配置数据，例如阈值、增益、时间常数。参数在AUTOSAR中通过Calibration Parameter或Constant Parameter表达，在Stateflow中映射为Parameter对象或Constant模块。参数的关键属性包括数据类型、初始值、是否可标定、存储类。对于需要在线标定的参数，应配置为可标定存储类；对于编译期固定的常量，则使用常量存储类以减少RAM占用。
需要特别注意的是，Stateflow中的局部变量、输入输出数据、数据存储内存，都必须显式配置AUTOSAR属性，否则代码生成时无法正确映射到RTE接口或内部变量。常见的做法是在Simulink数据字典中集中管理这些对象，再通过AUTOSAR属性对话框逐一绑定。
四、Stateflow图表作为Runnable实现载体的组织方式
当SWC类型、Runnable触发方式和数据对象都确定后，Stateflow图表的组织就有了明确约束。一个Runnable对应一个Stateflow Chart，Chart内部的状态机描述该Runnable的行为逻辑。如果SWC包含多个Runnable，就应有多个Chart，分别挂在各自的Runnable下，而不是把所有逻辑塞进一个Chart再用条件分支区分。
在Chart内部，输入输出端口应与Runnable的RTE端口对应。周期Runnable的Chart通常以固定步长执行，状态迁移在每个步长评估一次；事件驱动Runnable的Chart则只在事件到达时执行一次，因此Chart中不应假设状态会持续演化。对于需要初始化的状态，应在Chart中设置默认迁移或使用Init状态的显式入口。
代码生成阶段，Stateflow Chart会被转换为C代码中的状态机实现，包括状态变量、迁移条件判断和动作执行。Runnable的入口函数调用Chart的step函数，Chart内部维护状态变量的持久化。IRV和参数则分别映射为SWC内部的静态变量和标定量，通过RTE或直接访问方式被Chart读写。
五、一个映射示例
假设要为一个车窗防夹控制功能建模。选择Application SWC，命名为WindowAntiPinch。定义两个Runnable：RE_Calc由10ms周期TimingEvent触发，负责采集位置信号并计算防夹力；RE_Output由DataReceivedEvent触发，负责在收到电机电流数据后输出反转指令。两者之间通过IRV IRV_ForceValue共享防夹力计算结果。参数包括P_Threshold（防夹力阈值，可标定）和P_DebounceTime（去抖时间，常量）。
在模型中，RE_Calc下放置一个Stateflow Chart，内部用状态机描述“正常上升—力超阈值—触发反转—等待复位”的状态迁移；RE_Output下放置另一个Chart，用简单流程图判断电流方向并输出。两个Chart通过IRV读写共享数据，参数通过Parameter对象引用。代码生成后，RE_Calc和RE_Output分别生成独立的Runnable函数，IRV成为SWC内部静态变量，参数成为标定量的访问入口。
这个示例说明：SWC类型决定组件职责边界，Runnable决定执行时机和Chart数量，IRV与参数决定数据接口，Stateflow Chart则承载具体的行为逻辑。四层映射一致，代码生成才能正确产出符合AUTOSAR规范的代码。