为了对相关的元模型元素进行简洁的描述,本章集中讨论和解释了概念方面的内容。
阅读本章并不是理解后面章节的先决条件。
它只是为本文档其他各章中使用的概念方面的详细描述提供了一个中心位置。
基础概念分8节:
1、测量和校准
2、运行时和数据一致性方面
3、软件组件模板中的变量处理
4、组成组件类型的通信规范
5、PRPortPrototype
6、假装联网
7、可变大小的数组数据类型
8、结构中的可选元素
基础概念分四部分讲述,本章讲述:
2、运行时和数据一致性方面
3、软件组件模板中的变量处理
本节给出了一些背景信息,并列出了在实现RunnableEntitys和RTE时,在RunnableEntitys之间进行有效通信方面可能采取的策略。
RunnableEntitys之间的通信可以通过“共享内存”的方式非常有效地实现。请注意,术语“共享内存”可以在不同的层次上进行解释。例如,在C语言中,可以使用带有外部链接的变量(也称为“全局变量”,尽管这个术语在C语言中没有正式定义)来实现可运行间的通信。这在技术上是可行的,因为它总是保证AtomicSwComponentType中的RunnableEntitys总是聚集在一个特定的处理单元(换句话说:分发不是一个选项)。
注意,RunnableEntitys之间通信的目的是建立一个数据流方案。后者是控制理论应用于汽车嵌入式系统的一种非常流行的模式。因此,如果使用“全局变量”在RunnableEntitys之间建立内部通信,那么它们将获得所谓状态消息的语义。
然而,在RunnableEntitys之间直接共享内存需要解决一个严重的问题:保证正在通信的RunnableEntitys之间的数据一致性。RunnableEntitys确实会被映射到任务,这样AtomicSwComponentType的一个RunnableEntity可能会被相同AtomicSwComponentType的另一个RunnableEntity抢占。
请注意,实现数据一致性的纯粹方法不仅适用于对并发访问的变量的单次访问。相反,不允许在RunnableEntity运行时无意中更改并发访问的变量的值(使用状态消息语义)。
以下段落描述了一些可用于确保所需数据一致性的常见策略。我们不会试图描述这些方法的优点或缺点。
多线程操作系统提供互斥锁(互斥信号量),保护对在多个任务中使用的独占资源的访问。
RTE可以使用这些os提供的互斥锁来确保共享内存空间的RunnableEntitys不会并发运行。RTE将确保运行RunnableEntity的任务在访问RunnableEntitys之间共享的内存之前使用了适当的互斥锁。
另一种替代方法是在RunnableEntitys的运行期间禁用中断,或者至少在与RunnableEntity中并发访问的变量的第一次使用到最后一次使用的时间间隔相同的时间段内禁用中断。这种方法可能导致严重的不确定执行时间。
优先级上限允许对共享资源进行非阻塞保护。如果优先级模式是静态的,AUTOSAR操作系统能够暂时将试图访问共享资源的任务的优先级提升到所有试图访问该资源的任务的最高优先级。
通过这种方法,在技术上不可能使一个暂时拥有资源的任务也被一个试图访问该资源的任务抢占。
另一种方法是使用具有状态消息语义的并发访问变量的副本。请注意,此方法直接对应于“隐式”发送方-接收方通信的语义。
这特别意味着对于并发使用的变量,将创建一个副本,RunnableEntity实体可以在该副本上工作,而不会有任何数据不一致的危险。
在执行访问变量的RunnableEntity之前,这个概念需要额外的代码将并发访问的变量的值写入副本。副本的值应在RunnableEntity终止后写回被并发访问的变量。
由于手工处理复制例程代价太大,而且容易出错,所以最好将额外代码的创建留给合适的代码生成器。
围绕RunnableEntitys生成复制例程上图中所示的额外复制例程已经保护了特定的RunnableEntitys,使其不受并发访问变量的意外更改的影响。但是,可以通过减少每个任务开始和结束时的额外代码来进一步优化流程(下面描述)。
此外,只有在适当的地方才会插入复制例程,例如,只有当RunnableEntity对并发使用的变量具有写访问权限时,才会插入用于将复制的值写回并发访问的变量的复制例程。
请注意,复制例程必须临时确保复制过程不被中断,以便能够一致地将值从并发访问的变量复制到并发访问的变量。
但是,与RunnableEntity的总体运行时消耗相比,这些周期应该非常短,因此不会对运行时行为产生重大影响。
优化插入复制例程可以应用进一步的优化条件,例如:避免为调度在所有任务中具有最高优先级的RunnableEntitys(通过包含的RunnableEntitys)访问某个并发访问的变量的任务创建副本是完全安全的。
为了使应用程序代码不受代码生成的任何依赖,对并发访问的变量的访问将由宏来保护,这些宏稍后将由代码生成器解析。
保护宏的存在直接支持源代码级别的重用。只有在调度场景(在将RunnableEntitys分配到优先级级别方面)不变的情况下,才有可能在目标代码级别上重用。
只有在能够识别出相关变量的情况下,才能借助代码生成器正确地实现这个概念。换句话说:AtomicSwComponentType的描述必须向外部世界公开所有并发访问的变量。
可以这样说,隐式和显式通信之间的区别在应用程序领域(即AUTOSAR软件组件的开发人员及其实现领域)建立了一种使用模式。
通过阅读各自的文本部分,可以明显看出两个应用程序的建模方式不同。基于端口的通信使用VariableAccess来形式化访问通信元素的不同角色。用于此目的的一些角色暗示了显式通信(例如,dataSendPoint),而另一些角色则代表了隐式通信(例如,dataWriteAccess)。
然而,使用VariableAccess的重要之处是,通信角色的建模是从实际的通信元素中抽象出来的,并且表示了一种统一的建模方法(意思是:它可以直接引用目标,也可以通过所谓的InstanceRef),这种方法适用于所有的用例。
诚然,对于内部通信,这是用一种不同的方式来处理的。在这里,在RTE中明确分离“具有隐式行为的可运行变量”和“具有显式行为的可运行变量”时,没有使用额外的抽象层(尽管这样做在技术上是可行的)。
不同通信角色(即隐式和显式)的实现是通过将VariableDataPrototype直接聚合到两个角色中来完成的,即显式interrunnablevariable和隐式interrunnablevariable。
另一方面,对内部通信的访问从不需要使用InstanceRef,因此抽象可能被认为是不必要的开销,会破坏M1模型。
软件组件模板支持在其模型元素的子集中创建变体。支持变化的模型元素的完整列表可以在附录中找到。
软件构件模板中对变体处理的支持主要是为了通过变化来描述一个虚拟功能总线级上的变量系统
• SwComponentPrototype的存在
• SwConnectors的存在
• SwComponentDocumentation中章节的存在
• PortPrototype的存在
这支持调整软件组件实例的数量和种类,以及它们在特定系统变量中的互连。
前三种情况支持构建后绑定。如果存在PortPrototype,则只支持将PreCompileTime作为最新绑定时间。
依赖于后构建条件而存在的SwConnector对应用于附加了SwConnector的PortPrototype上的API函数调用的行为有影响。如果SwConnector不存在,则需要考虑RTE API函数的行为。这意味着这个PortPrototype的RTE实现类似于未连接的PortPrototype的行为。
如果SwConnectors不存在,那么相应的API函数仍然是软件组件实现的一部分。
在PostBuild步骤中不可能删除API函数。因此,PortPrototype的条件存在的最新合理绑定时间是预编译时间。
除了与vfb相关的模型元素的变体之外,还支持对变体软件组件实现的描述。请注意,这需要对内部行为的可变性提供广泛的支持。
确定的主要用例是
• RunnableEntitys的存在
• RTEEvents的存在
• 角色隐式InterRunnableVariable和显式InterRunnableVariable中是否存在VariableDataPrototypes
• 在角色PerInstanceParameter,SharedParameter和ConstantMemory中是否存在ParameterDataPrototypes
由于与PortPrototype的存在相同的原因,这类可变性的最新绑定时间是预编译时间。
在元模型中,所有可能表现出可变性的位置均以原型“ atpVariation”标记。 这允许定义可能的变化点。
标记值用于指定其他信息,例如最新的绑定时间。
元模型中可能表现出可变性的四种类型的位置
元模型中存在四种类型的位置,这些位置可能显示出可变性:
•汇总
•协会
•属性值
•提供属性集的类
在以下章节的类表中解释了将原型“ atpVariation”附加到某些模型元素的原因以及对其他模型元素的后果。
有关AUTOSAR变体处理概念的更多细节可以在AUTOSAR通用结构模板中找到。