汽车电子软件架构师——AUTOSAR架构从业者

Component先創建庫文件，然後根據組件類型進一步創建Component和Atomic Component,但层级太多不利于对架构结构的整体认知，一般经验上只建立两级，这样可以增加架构的可读性

Runnable本质上就是SWC中的函数，而在AUTOSAR架构在被DaVinci软件生成的时候，Runnable是空函数

AtomicECU Component和CompositonECU Component区别

创建ECUProject

在前面我们介绍了如何新建一个ECU Project，此部分我们继续介绍在新建的ECU Project去创建Component，右健点击ECU_Composition，在弹出窗口点击New Component。按照架构划分的软件组件SWC，在Davinci中对应ApplicationComponent软件组件可以理解为一个小的模块功能划分，例如一个状态管理模块，热管理模块等。在Component Type处，如果不选择内容则会报错如下截图，因此需要创建Component库文件。

在AUTOSAR下，ARXML文件作为通用配置文件或数据库文件，其描述了软件组件对外接口信息和运行Runnable信息，在AUTOSAR标准下，ARXML文档的解析均已实现工具化，如Vector DavinciDeveloper、Artop、AutosarExplorer，包括MATLAB等。将ARXML文件导入支持其文件格式的工具，导入到工具链中可以用于配置生成AUTOSAR RTE层代码，导入到MATLAB中可支持模型开发，未来的一段时间我将针对Davcinci工具的ARXML开发展开介绍。

Runnable运行依赖于task，task依托于Application,设计后OS可以按照Application和Task进行配置，同时RTE按照Runnable和task的映射关系进行匹配。这样就能保证所有Runnable（运行函数）在OS的task进行调用。

AUTOSARCP提供了很多标准的API接口供ASW使用，在架构设计阶段需要从中选取实现需求所需的API。如下列举几个常用的API。

前面我们简单介绍了RTE (Runtime Environment)，其作为虚拟功能总线，实现了上层的ASW与BSW的隔离，摆脱了以往ECU软件开发与验证时对硬件系统的依赖。RTE是AUTOSAR的接口实现，对于特定ECU的虚拟功能总线。

Runnable的设计要考虑需求实现和CPU负载，从实现需求来说，如果没有特殊要求均放在最短任务周期当然可以实现，但是如果所有任务均在最短任务周期这样会造成芯片负载率过高，严重则会OS跑飞。因此功能模块划分后，一条需求可以采用不同的实现方式和执行任务周期，比如状态管理模块，此模块对实时性要求很高，这样的模块的Runnable设计比如按要仿照比较短的任务周期，这样才能保证处理策略性。补充一点：Runnable是需要OS中的Task做载体的。

功能模块划分后，需要将需求对应映到对应的功能模块内实现，比如有1000条功能需求，20个功能模块，需要将1000条功能需求全部映射到这20个功能模块内，映射后进行需求和架构的双向追溯检查，避免需求遗漏。此处需要注意，不是说一条需求只能在一个功能模块实现，需求是可以拆分到不同模块实现的。

按照软件功能需求和功能安全等级分割软件功能组件，一般ECU通用功能为例,模块划分先按照功能划分，模块划分重点考虑以下两点：1.模块功能高内聚，模块间低耦合2.功能安全。

软件架构的前置输入是软件需求，当软件需求下发后，要制定相应的架构计划，然后开展具体软件架构设计开发工作，下图为架构设计流程。

基于标准AUTOSAR架构的开发流程

AUTOSAR架构在汽车软件领域已成为不可回避热门词汇，从事汽车软件行业的人员都知道，当前汽车电子软件开发几乎全部采用AUTOSAR架构。当前网上AUTOSAR架构的文章，资料很方便，关于AUTOSAR底层标准模块介绍的，关于实施运行环境RTE介绍的，关于应用层软件开发工具MATLAB/Simulink开发介绍的，关于AUTOSAR工具链介绍的，更多的是针对一个方面进行展开，讲解的很详细。但实际从一个软件开发人员的角度，当我们手里有了开发工具，是如何利用这些工具完成符合AUTOSAR架构开发的呢？.....