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，使用频率极低。

 闲谈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）