3.AUTOSAR的多核处理
此刻,有人提问,市面上μC更新换代非常快,性能也不断提升,甚至有多核处理器,这个架构如何应对多核处理?工程师想了想,show出了下图
并结合下图给出解释:
§ BSW模块可以分布在多个分区和核心中。所有分区共享相同的代码。
§ 每个分区上的模块可以完全相同,如图中I/O堆栈中的DIO驱动程序所示。
§ 作为替代,他们可以使用依赖于核心的分支来实现不同的行为。Com服务和PWM驱动程序使用卫星主机通信来处理从相应卫星到主机的呼叫。
§ 主站与卫星之间的通信不规范。例如,它可以基于BSW调度程序提供的功能,也可以基于共享内存。
箭头指示服务调用的处理涉及哪些组件,这取决于分发方法和调用的来源。
§ 每个运行BSW模块的分区中的基本软件模式管理器(BswM)
§ 所有这些分区都是受信任的
§ 每个内核一个EcuM(每个在一个受信任的分区中)
§ 通过引导加载程序启动的那个核心上的EcuM是主EcuM
§ 主EcuM启动所有卫星EcuM
§ 如图所示,IOC提供了通讯服务,这些客户端可以访问需要跨同一ECU上OS-Application边界进行通讯的客户端。IOC是操作系统的一部分。
§ BSW模块可以在多个内核上执行,例如图中的ComM。在运行时确定负责执行服务的核心。
§ 每个核心都运行一种ECU状态管理
4.AUTOSAR的Safety功能
那么,安全功能如何?工程师都有考虑和准备:
AUTOSAR提供了一种灵活的方法来支持与安全相关的ECU,可以使用两种方法:
1. 所有BSW模块均根据所需的ASIL开发
2. 所选模块是根据ASIL开发的,ASIL和非ASIL模块分为不同的分区(BSW分发)
注意:分区基于OSApplications,OS-Application的TRUSTED属性与ASIL/non-ASIL不相关。
使用不同BSW分区的示例,看门狗堆栈放置在自己的分区中
§ ASIL和非ASIL SW-C可以通过RTE访问WdgM
§ BSW的其余部分放在自己的分区中
经过以上的解答和分解,会议上的各位都点头表示同意,但是还是有人提了个问题,我们定义这么多功能模块,不一定所有产品都会用到,如何裁剪?
5.AUTOSAR的ICC
好了,我们接下来讨论ICC(Implementation Conformance Class):
下图显示了基本软件模块到AUTOSAR层的映射
到目前为止,本文档中显示的集群是该项目定义的集群。
当前,AUTOSAR并未将ICC2级别上的群集限制为专用群集,因为许多不同的约束和优化标准可能会导致不同的ICC2群集。 可能存在不同的AUTOSAR ICC2集群,可以根据要定义的ICC2遵从性方法声明符合性。
ICC1呢?
在符合ICC1的基本软件中,不需要模块或集群。未指定此专有基本软件的内部结构。
纳尼?又回到原来的三层结构?
兼容AUTOSAR(ICC1-3)的基本软件(包括RTE)必须具有ICC3模块规范指定的外部性能。例如,针对以下行为:
§ 总线
§ 引导加载程序和
§ 应用
另外,关于ICC3中的系统描述,ICC1 / 2配置应兼容。
也是说,这个架构能屈能伸,只需遵循相关标准要求即可,非常灵活。5后话
会上响起了经久不绝的掌声,结构做到这份上,也是非常详尽了。但是,问题还是有的,架构中定义了那么多模块,模块之间的接口是如何的?
工程师,想了想,面对座上的期盼的目光,慢悠悠地说,我们下次会议再讨论吧……(因为要下班了,万恶资本主义的欧洲,他们的工程师,不!加!班!!)