什么是“AUTOSAR”

开场白

对于大多数从事车载嵌入式软件开发的人来说，“AUTOSAR”的名字是不是已经很亲切了，或者至少有一次听到过呢？
实际上，从前年到去年，在量产开发现场利用AUTOSAR的机会大幅增加。

概要

AUTOSAR中的ECU软件大致由三部分构成。
其结构如图1所示。

最下面的AUTOSAR基本软件(Basic Software：BSW，详见图2)简单地表示为“任何汽车制造商的任何ECU供应商创建的任何类型的ECU中的基本软件”，操作系统，通信堆栈(CAN，LIN，FlexRay，以太网等)，
非易失性存储器堆栈，诊断，输入和输出，由软件模块组，其提供各种功能，如模式管理。
另外，在软件体系结构上，硬件依存的只有微型计算机固有的MCAL(Microcontroller Abstraction Layer/图2的从GPT驱动程序到PORT驱动程序的BSW的一组)、OS和Complex Driver以及外部连接到微型计算机的设备用的驱动程序。
除此之外，由于不依赖于硬件，所以可以将伴随硬件变更的影响局部化。

最上面的用于实现个别ECU功能的应用层的部分通常由多个软件组件(Software Component：SW-C)构成。
为了实现某种功能，车辆内的多个ECU的关系已经不少见，但将车辆看作一个系统时，可以分为监视传感器的输入部分、操作致动器的输出部分、以及其间的运算部分的三个部分。
然后，分别对应的SW-C之间通过“端口”连接(注：这里的端口与输入输出端口和BSW的PORT驱动程序不同)。
SW-C在考虑到实现功能所需的传感器、致动器、ROM/RAM等资源和时间限制的基础上，分配给各自的ECU。
通过该分配，确定端口之间的通信是使用CAN通信BSW等的ECU间通信还是ECU内通信。
此时，RTE(Runtime Environment，Runtime Environment)的主要作用之一就是，就像电话交换机一样，不需要对SW-C本身进行任何修改。
由此，应用层的自上而下型开发比以往更容易。

另外，SW-C的实际处理通过周期事件等各种事件发生时执行的处理即“Runnable Entity”来实现。
将该Runnable Entity配置为OS的任务也是RTE的作用。

另外，编码依赖于BSW/RTE的部分不少，另外，为了适应实用方面或特定用途的要求，也经常进行规格扩展。
因此，需要注意的是，即使是基于相同规格的产品，不仅在质量和安装方法上，在功能方面也可能存在差异。
另外，在AUTOSAR中，不仅进行上述那样的软件体系结构，还进行数据交换形式的标准化。
这对于尽可能地延长设计资产的可用时间或扩大集成工作自动化的范围来说，是非常重要的。
AUTOSAR规定了利用XML的标准数据交换形式，其中特别重要的如下所示。

·System Description：
整个车辆系统的设计信息。
·ECU Extract of System Description(EcuEx)：
在系统描述中，仅提取与特定ECU有关的信息，并用作汽车制造商和ECU供应商之间的设计信息交换介质。
另外，以往，在与CAN网络连接的ECU的开发中，通常使用DBC文件作为其介质。
EcuEx可以替换它，并且可以描述更多的信息。
·ECU Configuration Description(EcuC)：
ECU上的SW-C的信息，RTE和BSW的设定信息等。
·Software Component Description(SW-C Description)：
有关SW-C的设计信息。
包括有关Port和Runnable Entity的信息，以及使用哪些BSW的哪些功能，等等。
·基本软件模块描述(BSWMD)：
各BSW的设定项目等的信息。

导入形态

关于AUTOSAR的概要，可以从公开的规格书、几篇解说文章、研讨会等获得信息。
但是，关于在量产开发现场导入AUTOSAR的实际情况，只能得到非常有限的信息。
特别是，需要注意的是，引进也有受“周围状况(或”一般使用方法“)”左右的部分。
关于这一点，下次以后也会涉及，在此，对当前的AUTOSAR的导入形态的整体状况进行说明。
让我们举几个例子。

• 仅使用通信堆栈：为了确保与其他ECU的通信方面的兼容性，只导入通信堆栈。
  应用传统OSEK/VDX OS任务和传统调度器类型的开发风格，而无需使用RTE。
• 除了通信堆栈之外，还使用OS和RTE：为汽车制造商分发SW-C做准备，还引入了OS和RTE。
• 最大限度地转移现有模块：确保与其他ECU通信方面的兼容性，并仅利用通信堆栈、OS、RTE等最小限度的产品，以备汽车制造商分发SW-C，其他则可通过再利用现有模块的Complex Driver进行应对。“。
• 使用最小的MCAL：MCAL通常使用微型计算机制造商提供的东西，但有时还不存在。
  在这种情况下，我们只使用最小的MCAL(或其子集)来尽可能减少新的开发量，其他则由Complex Driver支持。

当然这些并不是全部，上述各自也不是完全独立的。
另外，关于是否有来自汽车制造商的SW-C的分发、被分发的SW-C利用哪个BSW提供的服务的设想，实际上也是各种各样的。
因此，特别是在向多个汽车制造商供给ECU的情况下，在成本方面的限制下，不容易判断为了组装要分发的SW-C而需要购买什么样的BSW。
另外，关于作为汽车制造商和ECU供应商之间的设计信息授受的介质的EcuEx，在汽车制造商将其内容记述到何种程度这一点上，也进行了各种各样的运用。
而且，代替EcuEx，使用CAN用DBC文件等以往的形式的情况也很多(“如果内容相同，则转换是可能的”的道理)。
因此，“AUTOSAR的导入”一词的意思并不是唯一的，“周围的状况”、“一般的使用方法”等各种因素可能会左右“应该准备的事情”、“容易准备的事情”。