AUTOSAR_TPS_SoftwareComponentTemplate56学习笔记

Grey

全部学习汇总: ​​https://github.com/GreyZhang/hack_autosar​

AUTOSAR_TPS_SoftwareComponentTemplate56学习笔记

摘录与批注

976_AUTOSAR_TPS_SoftwareComponentTemplate56_autosar

  • 一对多的映射会涉及到重入实现的问题,这样的情况在RTE的层级直接不支持,避免一系列问题的发生。

976_AUTOSAR_TPS_SoftwareComponentTemplate56_迭代_02

  • 各种库函数等一般都是可以重入的,从这个描述看,似乎是否重入基本就是看是否绑定了全局量以及静态局部变量?

976_AUTOSAR_TPS_SoftwareComponentTemplate56_迭代_03

运行实体的分类:


  • CAT1: 1A,第 1 类 RunnableEntity 没有等待点,需要在有限的时间内终止。 类别 1 分为两个子类别:类别 1A 和类别 1B。 1A 类 RunnableEntity 只允许使用隐式 API。 1B 类 RunnableEntity 还允许调用服务器并使用显式 API。
  • CAT2: 与类别 1 的 RunnableEntitys 相比,类别 2 的 RunnableEntitys 总是聚合至少一个 WaitPoint,更多细节参见图 7.31。 通常,这样的 RunnableEntity 实现了一个内部循环,每当一个 WaitPoint 被解析时,就会触发一次循环迭代。
  • 感觉上,现在我接触的操作系统功能中类似的功能都见过。我用过的ETAS操作系统中其实两种任务都是存在的,一般的周期性调度属于CAT1,而扩展任务则是CAT2。至于FreeRTOS,应该大部分任务都是CAT2吧?

976_AUTOSAR_TPS_SoftwareComponentTemplate56_初始化_04

  • 运行实体的激活,可能有多种条件。比较典型的一个是,周期性执行的运行实体同时还在等待来自于RTE的数据传输事件。

976_AUTOSAR_TPS_SoftwareComponentTemplate56_autosar_05

  • 这个描述我觉得可以注意一下,RTE的生成器应该可以生成一个接口用来检测运行实体被激活的原因。

976_AUTOSAR_TPS_SoftwareComponentTemplate56_迭代_06

用于初始化目的的运行实体

  • 确保在软件组件进入其正常操作状态之前应用某些初始化的一种方法是使用 AUTOSAR 模式管理,特别是通过定义包含特定 ModeDeclaration 的 ModeDeclarationGroup 的语义表示专门用于设置的模式 启动并初始化软件组件。
     

然而,这种方法会带来一定的占用空间,在某些情况下可能是可以接受的,但也可能存在更简单的方法派上用场的情况。 初始化的简单方法包括由一种特殊类型的 RTEEvent 触发的 RunnableEntity,即所谓的 InitEvent。

  • 除了使用基于模式的方法来执行初始化 RunnableEntitys 之外,还可以让 InitEvent 引用角色 startOnEvent 中的 RunnableEntity。
     

这种初始化软件组件的方法与基于模式的方法是正交的。 特别是,由 InitEvent 触发的 RunnableEntity 预计在 RTE 完全初始化后执行。 这意味着在 ECU 初始化期间有关 RTE API 可用性的限制与由 InitEvent 触发的 RunnableEntity 无关。

976_AUTOSAR_TPS_SoftwareComponentTemplate56_显式_07


  • 在执行过程中,会发生几个 RTEEvent,例如在 PPortPrototype 上接收到 ClientServerOperation 的远程调用,或者在未接收到它期望接收的 VariableDataPrototype 的 RPortPrototype 上发生超时。
  • 工具中的RTE事件首先定了一个RTE的事件对象,其次定义了当这个事件发生之后RTE应该如何处理。

976_AUTOSAR_TPS_SoftwareComponentTemplate56_显式_08

与RTE事件的交互,如虚拟功能总线规范 [3] 中所述,AtomicSwComponentType 的 RunnableEntity 可以通过两种方式与此类 RTEEvent 的发生交互:

- 当 RTEEvent 发生时,可以指示 RTE 启用特定的 RunnableEntity。


  • RTE 可以提供 WaitPoint ,允许 RunnableEntity 阻塞,直到一组 RTEEvents 中的 RTEEvent 发生。
  • 第二点其实很值得关注一下,这个之前我是一直不清楚的,因为我觉得这部分功能可能是操作系统提供的。现在看起来,各种事件以及阻塞的机制其实应该是RTE提供的。

976_AUTOSAR_TPS_SoftwareComponentTemplate56_autosar_09

  • 如果SWC定义或者描述RTE事件发生时候的运行实体内容,那么RTE应该负责保证事件发生的时候触发运行实体。

976_AUTOSAR_TPS_SoftwareComponentTemplate56_显式_10


  • 如果 RunnableEntity 想要阻塞并等待 RTEEvents(这使得 RunnableEntity 成为 cat.2 RunnableEntity),RunnableEntity 的描述可能包括一个 WaitPoint 的定义。
  • 这样的WaitPoint(见图7.13)包含对一个RTEEvent 的引用,它可以解除对特定WaitPoint 的阻塞。 换句话说:WaitPoint 将阻塞,直到引用的 RTEEvents 发生或属性 timeout 中指定的时间段到期。
  • 上上面第二条的描述可以获知,阻塞的解除其实是两种情况:一个是事件发生,另一个是超时。

小结

这一部分大部分都是在看内部行为的内容,在RTE的事件部分摘录记录了挺多信息,因为这部分不仅仅涉及到未来实际的软件设计,而且补充了我之前不了解的一部分概念。