SwcInternalBehavior被用来给AtomicSwComponentType定义行为，也即可以进行哪些操作，以何种方式进行操作等等。
从设计角度来说，在VFB阶段不用引入SwcInternalBehavior，相关开发人员可以在整个系统的应用层设计结束之后再来为每个SWC创建SwcInternalBehavior。
Runnable Entity
可运行实体（后文也称作RE），是SWC能提供的最小代码块，往往代表某一项具体功能，同时RE也是OS操作系统调度时使用的主体（实际代码中往往是OS和RTE共同完成调度，在RTE代码中调用相应的RE）。但是呢，CompositionSwCType自身是不能定义Internal Behavior的。
最上面的框代表了这个RE有什么功能：
IRV Access: 对哪些inter runnable variable有读操作权限，或者写操作权限，或者读写操作权限都有
Data Access: 对哪些S/R接口中的数据有读写需求，如果接口连接的是跨ECU的应用，代表着最终的读写操作需要在总线上传输数据
Server Call Point: 有哪些C/S操作（operation）需要完成
Mode Switch Point: 需要进行哪些模式转换操作
Mode Access Point: 读取某个模式状态
Parameter Access: 有哪些NvM量需要处理
至于Events，则代表着何时或者何种情况下需要进行一次RE的执行。
Minimum Start Interval代表RTE连续调用RE的最小间隔。
RE的symbol在一个EcuInstance范围内，名字应当保持唯一性。
Can Be Invoked Concurrently代表RE是否可以被并发调用。默认设置为False值。
当canBeInvokedConcurrently设置为False时
基于RTEEvent的概念，SwcInternalBehavior为每一个RE定义了从suspended迁移到to be started状态的条件。
当RE在to be started状态时，RTE可以决定去开始运行这个RE，从to be started到running状态之间的延迟时间，取决于RTE的调度策略，也即RE在OS task中的映射情况。
当RE返回（return）时，控制交还给OS，会从running状态迁移到suspended状态。如果是catgory 2的RE，当进入running状态后则不会再回到suspended状态。
被抢占时，他们也会进入preempted状态。
如果一个RE的canBeInvokedConcurrently设置为False，那么RTE会保证它不会被并发执行，也即这个RE无法被映射到两个不同的OS任务当中，RE内部的具体实现也无需考虑并发执行的情况。当RE在running状态，同时又因为收到其他请求导致希望并发执行时，RTE一般需要等待前一次执行结束，或者将当前请求置入队列。
当canBeInvokedConcurrently设置为True时
当设置为True时，是允许在不同的OS任务当中并发执行同一个RE的。
SWC自身的描述文件不会定义并发调用的限制次数，仅仅说明是否允许并发执行。
典型的应用场景是AUTOSAR service的RE实现，不同的SWC可以同时使用相同的AUTOSAR service。
集成人员可以决定，在这种情况下，AUTOSAR service的RE直接运行在调用这个服务的SWC的context内。对于Client/Server方式调用，这样的直接耦合关系是非常高效的，client和server端的连接可以直接将过程简化为函数的本地调用。
Runnable Entity的种类
RE可以被划分为如下种类：
Category 1: RE不能设置waitpoint，需要在有限时间内执行完毕。Category 1还被细分为1A和1B两个子类，1A的RE只能使用隐性(implicit) API，而1B除此之外可以调用server以及使用显性(explicit) API。
Category 2: 不同于Category 1，Category 2至少有一个wait point，一般这个类型的RE会存在loop循环，当wait point触发时会执行一次。
Runnable Entity的参数
只有由C/S操作调用的RE才能配置这个参数，这里截图为DLT service的例子，也即RE需要提供的参数。
Runnable Entity的激活原因
一个RE是可能被多个RTEEvent激活的，很多情况下也需要能在RE当中获取激活自己的RTEEvent的信息。例如，一个RE既可以周期触发执行，也可以在收到某个数据时被触发调用。
在一个RE中，这个bitPosition的范围为0~31，同时Symbol名也需要保持唯一性。
如果RTEEvent设置了Trigger角色的Wait Point，那么不应当设置Activation Reason, 因为对于有Wait Point的RE来说，它是已经被激活了的，只是会在Wait Point触发时继续执行，无需上文提及的激活原因。
RTE Event
RTE Event定义包含两部分：定义RTE Event；定义Event发生时RTE如何处理。
为RE设置Event时一般有下列种类：
AsynchronousServerCallRetrunsEvent: 异步调用结束时
DataSendCompletedEvent: 相关数据元素被发送后或错误发生时
DataWriteCompletedEvent: Implicit写操作成功，或者错误发生时
DataReceivedEvent: 相关数据收到时
DataReceiveErrorEvent: Com模块检测并提醒数据收到时有错误发生，并由RTE触发
OperationInvokedEvent: 客户端调用ClientServerOperation时
TimingEvent: 需要周期调用时
BackgroundEvent: 需要RE在后台执行时
SwcModeSwitchEvent: 状态变化时
ModeSwitchedAckEvent: 转换到某个状态或者发生错误时
ExternalTriggerOccuredEvent: external trigger发生时
InternalTriggerOccurredEvent: internal trigger发生时
InitEvent: partition开始运行或者重启时，作初始化用
TransformerHardErrorEvent: 收到数据应当触发C/S操作或者外部trigger并作transformation时，发生错误
Runnable Entity之间的通信
在一个SWC中，RE也能够互相通信，进行数据交换。
RTE需要提供同步机制，为RE保证数据交换的安全性，这个时候PortPrototype是不需要的。
如果时同一SWC的不同实例，RE相互通信时只能借由PortPrototype完成。
Port API Options
一般用于RTE生成接口时加入额外的参数，典型应用是配置DLT功能时，RTE生成代码时的第一个参数是对应APP的session id。
Service Needs
ApplicationSwComponentType与实际ECU硬件无关，但这些SWC可能需要用到由底层软件提供AUTOSAR Service给到自己，这个时候就需要用到ServiceNeeds。
只有AtomicSwComponentType和NvBlockSwComponentType可以连接到AUTOSAR service。
当SWC集成到某一具体ECU上时，需要为ServiceNeeds选择实际的ECU 配置选项。
