寻找供应商
广告
首页 > 汽车技术 > 正文

软件定义汽车时代：进一步探索开放软件标准架构—AUTOSAR

2019-02-02 19:51:51·  来源：牛喀网  
　
之前我们为大家介绍过AUTOSAR的背景、目的以及会员组织等等内容【传送门：软件定义汽车时代：初识开放软件标准架构AUTOSAR】，今天我们将更加深入的一起探索AUTO
之前我们为大家介绍过AUTOSAR的背景、目的以及会员组织等等内容【传送门：软件定义汽车时代：初识开放软件标准架构—AUTOSAR】，今天我们将更加深入的一起探索AUTOSAR。
 
本篇文章作为上一篇的后续，我们将从详细介绍AUTOSAR的3个标准化对象。
  • （Software）Architecture
  • Methodology
  • Application Interface
- Software Architecture（软件架构）
上篇文章我们曾介绍过，如今的AUTOSAR平台“AUTOSAR Classic Platform”的Software Architecture里面，ECU（电子控制单元）的软件层为Application Layer、Runtime Environment（RTE）、Basic Software（BSW）3个阶层（图1）。我们在这里简单介绍以下这3个阶层的概要。
图1：“AUTOSAR Classic Platform”中的Software Architecture（软件结构） 来源：ETAS
 
1）Application Layer：
对可以实现应用功能的Software Component（SW-C）进行配置的部分。 SW-C有时也记作Application SW（ASW）。除了对传感器和执行器有依赖性的SW-C之外，对ECU硬件和ECU的配置没有依赖。SW-C之间，或者SW-C与BSW／Complex Device Driver（CDD）之间，通过叫做AUTOSAR Interface的接口来进行连接。另外，SW-C的实际处理，是通过Runnable Entity或者略称为Runnable的要素（相当于C语言里面的函数）来实现的。Runnable除了某些特定的情况以外，都是在OS的任务层级运作而不是在中断程序ISR（Interrupt Service Routine）层级。
2）Runtime Environment / Run-Time Environment（RTE）
可以实现SW-C之间，或者SW-C与BSW／CDD之间相互连结的接口的部分。不管是分配在同一个ECU还是在不同ECU的2个SW-C，都不需要对SW-C本身进行任何的变更。换而言之，也可以说是消除了SW-C的ECU配置依存性。必要时，可以利用BSW的帮助（OS及协议栈等）。此外，还处理BSW周期函数及Runnable的起动，各种排他控制（Exclusive Area／Critical Section）等。
3）Basic Software（BSW）
摆脱了“面向哪一家汽车制造厂商？由哪一家ECU供应商开发的？或者什么类型的ECU”等条件的限制，实现共通的基本机能的部分。R4.2 Rev. 1里面合计定义了92个（其中9个是程序库）。
a.微控制器依存部分
OS（Operating System）以及MCAL（Microcontroller Abstraction Layer、各种驱动群）。此外，MCAL虽然大都是由微控制器供应商提供，但并不意味着一定就预备了所有的种类。
b.微控制器非依存部分
除了微控制器依存部分以外，剩下的全部都是BSW。预备了通信（Communication）、非易失性存储器（Memory）、看门狗（Watchdog）、I/O等各种栈（stack）。
4）Complex Driver
有时也记作Complex Device Driver（CDD）。假定了需要利用AUTOSAR标准里面没有涵盖的驱动（例如：利用微控制器固有的硬件机能时），对实时要求较高的应用以及需要编入传统型（non-AUTOSAR）的现有软件时的部分。可以直接访问硬件，也允许利用中断。还可以介入AUTOSAR Interface与SW-C进行连接。此外，根据不同的BSW，直接连接CDD可能会需要重新准备专用的接口。
各层通常主要用C语言安装。因此，不仅是对微控制器，对C语言编译器也有依赖。这个编译器依赖性（对编译器供应商及版本，可选项的依赖性），主要由Compiler Abstraction这个结构来吸收。对编译器依赖性大小关系如下：
OS＞MCAL＞其他的BSW
RTE及BSW，基本上会生成自动代码。另外， BSW里面，除了会根据设定生成可变的代码，有时也会有不变的固定代码部分。这些代码的提供形态有源代码形式和程序库形式。相对来说后者对编译器依赖性更高。这里的依赖性很容易被遗漏，需要特别注意。

- Methodology
“Methodology”这个词很难准确翻译过来。常常被翻译成“方法”，这个翻译会让我联想到意思不同的“technique”。译成“方法论”也不太好理解。因此，大部分时候都不直接翻译，而是解释成“根据什么，通过怎样的操作，得到什么样的结果这样一连串的过程”。
AUTOSAR里面的这个流程，以AUTOSAR TR Methodology这个书面描述来解说，用被称为SPEM※1）的记述方法的子集来记述。Methodology的概要如图2所示。
图2：「AUTOSAR Methodology概要Workflow」 来源：AUTOSAR R4.2 Rev.1 TR Methodology、Figure 2.2相当（由AUTOSAR_MMOD_metaModel.eap作成）
根据AUTOSAR Methodology，开发中作成的各种设计信息，必要时需要在不同的工具之间或者不同立场的作业人员之间进行传递（数据交换）。另外，需要进行构成管理。因此，这个数据形式里面需要有共通的定义。
AUTOSAR里面的数据交换，基本上使用XML进行。这些数据形式被称为AUTOSAR XML或者ARXML，为了能够在各种阶段和单位进行数据交换而被细化，主要由被叫做AUTOSAR TPS（Template）的各种书面语言来定义。其中代表性的如下：
1）ECU Extract
一般用于汽车制造厂商和ECU供应商之间传递信息,是ECU软件开发(RTE/BSW设定)时必需的起点※2）。《AUTOSAR TPS System Template》文件中有详细释义。其中包含了诸如：网络的E/E系统构成（例如：ECU和网络的定义）、通讯矩阵的定义（例如：消息的定义）、SW-C针对ECU的分配信息等。另外也可以将其他各种各样的构成要素囊括在内，并将其反映到RTE和BSW的设定中去，所以也有助于简化ECU供应商的设定工作。但是，一般必须由汽车制造厂商提供ECU Extract的所有构成要素，构成要素不完整的情况较多，此时须由ECU供应商进行补充。并且在开发初期提供的都是不完整版，之后需要多次反复更新※3）。
2）ECU Configuration Values（EcuC）
也被称为ECU Configuration Description。其中储存了RTE和BSW的设定信息，用于生成其代码。有时储存在单一文件夹中，有时也会根据BSW进行细分。《AUTOSAR TPS ECU Configuration》文件中有详细释义。
3）Software Component Description
储存了Application Layer中的SW-C相关的定义信息。《AUTOSAR TPS Software Component Template》文件中有详细释义。正确来说，虽然其中包含了Atomic、Composition和Service Component等各种Software Component，一般来说，包含这些定义的数据总称为SW-C Description。传递数据信息时，有时会将SW-C的接口部分的定义（Port Interface）和数据类型（Data Type）等信息存放在一个文件夹中，有时会按各项目进行细分。
4）Measurement and Calibration Support Data (McSupportData、MCSD)
存放了支持校准和测量SW-C和BSW的信息（具体有变量名称和类型等等）。《AUTOSAR SWS RTE》文件中有详细释义。此支持数据会转化到ASAM MCD-2 MC标准（别名：ASAP2）中的A2L文件夹中去，作为校准/测量/诊断工具（Measurement、Calibration and Diagnostics Tool、MCD Tool）使用。
5）Diagnostic Extract
存放了诊断相关的定义数据。《AUTOSAR TPS Diagnostic Extract Template》文件中有详细释义。在R4.2 Rev.1中以附加数据的形式体现。
6）ECU Resource Description
存放了ECU硬件相关的定义数据。《AUTOSAR TPS ECU Resource Template》文件中有详细释义。现节点，即使在AUTOSAR的最新版本（R4.2 Rev.1）中，Analog IO、Digital IO和Timer等的定义均为：Currently no special attributes are defined，使用频率极低。

注释
※1）是指Software＆Systems Process Engineering meta-Model。是根据Object Management Group（OMG）开发出来的。http://www.omg.org/spec/SPEM/2.0/
※2）一般很少使用传统（non-AUTOSAR）的数据形式来代替ECU Extract。例如，跟通信相关的话，DEC、LDF以及FIBEX都是其代表性的数据形式。
在AUTOSAR Authoring Tool中，可作为扩充功能应对数据的读取。作为其中之一的“ETAS ISOLAR-A”，可以作成DBC、LDF以及FIBEX的读取命令脚本，所以可以把汽车厂商特有的扩充数据（特别是DBC）反映到RTE和BSW的设定工作中。
※3）因为是ECU软件开发的起点，所以在开发过程中ECU供应商向汽车厂商的反馈是很关键的一点。涉及到很多注意点，比如必须区分“最终可以得出什么样的结果”和“实际得出了什么样的结果”。

 闲谈Methodology：用工具进行设定不是“画画”！
AUTOSAR Authoring Tool（AAT）类别中的工具和系统通常会被用来制作AUTOSAR XML。
令人遗憾的是，对于利用这些工具展开的设定工作，人们不认为那是在写代码，多戏称之为是在“瞎玩”、“画画”等。
在工具中的输入操作背景中，存在着”设计“这样的概念性作业，所以决不是单纯地“画画”。原本在AUTOSAR中，相比较重新安装而言，在设定时就必须满足能够应对各种场景情形的要求（相当于除Frakes以外其他分类中的Generative Approach※4））。而且其设定内容已实现形式化，之后也有可能实现自动化。如果想顺利导入AUTOSAR并实现软件的高度再利用化，就必须让周围的人理解、认可设定工作的意义和价值。
另外，如果仅以“AUTOSAR XML”或“ARXML”的形式表述，那就基本等同于什么都没有表达出来。比如就应该像“ECU Extract”这样表述，重要的是要表达出其中包含了什么样的内容。
而且Methodology基本上不是一开始就存在并用来分担工作的。因为有了实际的开发流程和工作分工（分界线）的需求，Methodology才应运而生，并根据需求持续更新。反过来说，作成了这个标准的会员企业，对此开发流程也仅仅只是有一个大概的了解。即使自己公司的开发流程和AUTOSAR Methodology的开发流程有很大的不同，但说不定从中可以受到改善的启发。如果一开始对两者的差异就采取批判的态度，那可能就失去了改善的机会，让人不禁觉得惋惜。

-Application Interface（AI）
不管再怎么利用AUTOSAR Software Architecture，即使不再依赖于SW-C、ECU的配置和硬件，但对于“实现某功能时需要什么样的数据，且以何种形式表现”这样的信息仍然有一定的依赖性。如果单纯地靠线性变换就得以表现的话那还算简单，但是，如果物理量的维度原本就不同的话，那线性变换也无济于事。
AUTOSAR Application Interface应用于汽车时，在以下各域以及各域之间的典型性接口，皆以AUTOSAR Interface的形式归总：
  • 车身和舒适功能
  • 动力传动系统
  • 乘客和行人保护
  • 多媒体/车联网/HMI
另外，使用AUTOSAR Software Architecture，并不意味着一定就会使用Application Interface。现在很多使用AUTOSAR的汽车制造厂商都并未使用Application Interface。AUTOSAR可根据相应的分类方法细分之后再导入。
注释
※4）除Frakes以外的其他工具：Metrics and Models, ACM Computing Surveys, Volume 28, Issue 2, pp. 415-435, 1996.http://dl.acm.org/ft_gateway.cfm?id=234531&type=pdf&CFID=65178775&CFTOKEN=89447410

-最后
笔者虽然接受了1次更新6000字左右的连载工作，但最开始光“复习”工作就花费了双倍的精力。所以，我想在这里强调的是，这些内容才仅仅达到了很浅显的概要的层次，自己必须以此为起点继续钻研。牛喀学城在11月17日特邀OEM+Tier 1实战专家，为大家带来一场实战讲解，有兴趣的朋友们可以在面授课堂上去更系统的学习AUTOSAR，详情可以点击以下海报查看：
 
在这过程中不可避免地会接触到大量的信息和工具。牛喀学城的讲师会为朋友们抽丝剥茧，两天的课程必将使朋友们满载而归。
AUTOSAR是基础，就像是背后的工作人员，是一个朴素、不起眼的存在。我相信工作一段时间之后，至少现在我可以明确的说：只要用了，将来肯定有所回报。
从下次开始，我会尽我所能地介绍关于导入AUTOSAR时应该跨越的壁垒，以及有助于跨越壁垒的相关内容和值得期待的积极的一面。还请大家耐心等待！
 
 
分享到：
 
反对 0 举报 0 收藏 0 评论 0
autosar
  • 汽车测试网V课堂

    汽车测试网V课堂

  • 微信公众号

    微信公众号

  • 汽车测试网手机站

    汽车测试网手机站

• AUTOSAR中的软件架构思考 • Adaptive AUTOSAR：下一代汽车软件平台的演进
• AUTOSAR自适应平台：汽车软件演进的关键里程碑 • 经纬恒润AUTOSAR成功适配曦华科技国产车规级芯片
• 汽车基础软件信息安全与AUTOSAR • AUTOSAR AP
• AUTOSAR CP • 详解AUTOSAR分层架构与软件组件
• AP Autosar在SOA开发中的应用方法论 • 高级驾驶辅助系统下的AUTOSAR通信栈的优化方法
0 条相关评论
  • 广告
  • 广告

编辑推荐

最新资讯

  • 广告
  • 广告
沪ICP备11026917号-25