1、AUTOSAR
近些年来，汽车行业内功能需求日新月异，使得E/E架构由分布式逐渐发展为功能域集中式，未来变为中央计算区域控制模式的软件架构。这些无不都要求一个移植性高、通用性强和安全可靠的软件架构，于是AUTOSAR很快作为一个热词火爆行业内，但它到底是什么？在这篇博文中，将会去揭开它的前世今生，其规范标准内部包含哪些主体内容。
1.1 背景及发展历程
AUTOSAR (AUTomotive Open System ARchitecture)，中文译为“汽车开放系统架构”，是一家致力于制定汽车电子软件标准的联盟。AUTOSAR最早出现在2003年，当主机厂为ECU开发电子软件时发现，对于不同平台，供应商所提供的硬件往往不同，因此电子软件也需要作出大量调整来匹配硬件。而主机厂存在多款车型平台，同一车型下也存在不同的配置，这无疑大大地增加了研发成本。这都是因为硬件制造厂商和软件开发者之间的耦合性太强，没有一个统一的标准，导致平台或者硬件发生变化时，软件却无法快速且容易地切换。为了解决这个问题，在软件架构、硬件平台和开发规范之间协调一个共同遵循的准则就变得刻不容缓，于是AUTOSAR组织应运而生。
第一阶段：
2002年，由德国企业宝马、博世、大陆、戴姆勒和大众成立组织，启动研讨会。
2003年，组织正式成立，并起草并签署通过了经典平台(Classic Platform，CP)的软件架构，随后福特、标志雪铁龙和丰田加入到核心成员中；
2004年，发布AUTOSAR第一版规范，随后通用公司加入到核心成员，至此9大核心成员聚集；
2005年，加入SWC组件标准，第一代工具准备完成，发布Classic Platform 2.1；
2006年，公布软件测试和集成规范；
第二阶段：
2007年，发布Classic Platform 3.0；
2008年，西门子VDO被大陆集团收购，不再是独立核心合作伙伴，发布Classic Platform 3.1，在底特律举办第1届AUTOSAR开放会议；
2009年，发布Classic Platform 4.0；
第三阶段：
2010年，在东京举办第2届AUTOSAR开放会议；
2011年，在美因河畔法兰克福举办第3届AUTOSAR开放会议；
2012年，在巴黎举办第4届AUTOSAR开放会议、北京第5届AUTOSAR开放会议；
稳定阶段：
2013年，发布稳定版的Classic Platform 4.1.0，慕尼黑第6届AUTOSAR开放会议；
2014年，发布Test 1.0.0，Classic Platform 4.2.1，底特律第7届AUTOSAR开放会议；
2015年，发布Test 1.1.0，Classic Platform 4.2.2，东京第8届AUTOSAR开放会议；
2016年，发布Foundation1.0.0，Classic Platform 4.3.0，瑞典哥德堡第9届AUTOSAR开放会议；
2017年，发布Adaptive Platform；
考虑到在当前及未来汽车市场中持续发展的汽车电子电气(E/E)架构，AUTOSAR组织为E/E发展建立了事实上的开放行业标准，其将会在未来的应用程序和标准的软件模块中，充当功能管理的基础设施。就像AUTOSAR 发言人Reichart 说的：“If a company does it alone it is one proprietary solution. If it is shared and used by several partners it becomes technology, and with board application it becomes state of art and alleviates certification”。翻译一下：“一个事情，如果只有一个公司在做，它就是一个特有的解决方案；如果它被一些合作伙伴共享和使用，那么它会变成一个科技；如果加持丰富的扩展应用，至此，已成艺术”！通俗地说，一流的企业做标准，三流的企业做产品。截止到2023年，参与到AUTOSAR联盟的合作伙伴，已经有350多位：
AUTOSAR入会形式分为五种。 成员合作方式不同，身份职责也不同:
- 核心成员伙伴(Core)：宝马、博士、大陆、戴姆勒、大众、福特、通用、标致雪铁龙、丰田共计9位创立成员，其主要负责AUTOSAR开发联盟的组织、管理和调控。
- 特别高级合作伙伴(Premium Partners Plus)：华为，株式会社电装，Vector；
- 高级合作伙伴(Premium Partners)：部分主机制造厂、Tier 1 和 Tier 2级零部件供应商，在核心合作伙伴组建的项目领导小组的协调和监督下开展工作；
- 开发合作伙伴(Development)：专用解决方案软件开发商，在核心合作伙伴组建的项目领导小组的协调和监督下开展工作；
- 一般合作伙伴(Associate)：根据AUTOSAR已发布的标准文件开展工作；
- 观察员(Attendee)：目前以学术合作和非商业项目的形式参与联盟活动。
1.2 为什么是AUTOSAR?
随着电子信息技术的快速发展，汽车自动驾驶也逐渐落地，而人们在享受汽车科技的同时，也愈发关注汽车性能、行车安全和信息保密。AUTOSAR更加关注软件架构的安全和性能，可以为不断创新发展的汽车电子系统铺平道路。它可以实现：
1、实现软件和硬件广泛的独立，各自发展；
2、通过抽象层实现软件开发的解耦，这可以大大节约时间和成本；
3、通过软件复用，可以提高软件质量和开发效率；
对于主机厂(OEM)来说，采用同一套标准规范(AUTOSAR)，可以将开发任务分布到不同的供应商，让他们在灵活的设计框架中去实现不同的创新性功能，即AUTOSAR提倡的“在标准上合作，实现上去竞争”的原则。统一的软件架构规范，可以简化软件和系统集成，降低企业的软件开发成本；
对于供应商来说，来自于不同主机厂的开发任务及需求，都可以通过已有的软件复用模块，提高开发效率，从而建立一套稳定的商业模型；
对于工具供应商来说，在开发过程中提供标准的接口，不同环节中嵌入开发工具；
对于汽车行业新参赛者来说，通过标准的接口可以创造新的商业模式，使得更容易理解汽车软件是如何开发的。
1.3 AUTOSAR的发展
随着汽车移动端在以下新兴技术的发展，AUTOSAR能否应对如此挑战呢？
1、高度自动化驾驶：功能安全，软件可靠，行驶15-20万公里的持久性；
2、V2X，云服务：信息安全，OTA软件更新功能，较高的网络服务质量；
3、数据高速传输和带宽：以太网、5G；
4、汽车高算力芯片：集成式多核处理器，Soc，集中式EE架构(分布式 -> ECU集中式 -> 功能域集中式[当前主流，分为5大域动力/底盘/车身/智驾/座舱] -> 跨域集中式 -> 中央计算区域控制式 -> 云计算式)；
为此，AUTOSAR提供了两种软件框架：CP - Classic Platform，经典平台、AP - Adaptive Platform，自适应平台。
CP平台主要使用 c 开发，适用于高安全性和高实时性的应用场景，对于分布嵌入式的系统都部署CP软件架构，如发送机、变速箱、制动系统的控制单元等；其实时运行速度达到微秒级，安全等级最高达到ASIL-D，芯片算力在1000 DMIPs，主要集中在Cortex-M，Cortex-R系列上；
AP平台主要使用 c++ 开发，适用于算力要求较高的场景中，专为具有OTA更新功能的联网自动驾驶汽车而设计，如信息娱乐域。其实时运行速度达到毫秒级，安全等级至少为ASIL-B，对芯片算力要求较高，须大于在20000 DMIPs，主要集中在Cortex-A系列上；
1.4 分层软件架构
一、CP_AUTOSAR，经典平台分层软件架构
CP_AUTOSAR软件架构主要分为三层：基础软件层(BSW)、运行时环境层(RTE)和应用层(Application Layer)，每一层都有自己特定的功能和职责。
BSW：底层又可以分为微控制器抽象层、ECU抽象层、服务层和复杂驱动层。其主要用于提供通信管理、内存管理和诊断功能等基本服务，作为构建高级组件的基础；
RTE层：管理系统内组件间通信，可以处理不同软件模块之间的数据交换，确保实时性能和资源优化。
应用层：包括实现各功能的软件组件(Software Components，SWC)，这些组件与较低的两层交互，以提供灵活的用户功能，如驾驶辅助系统或信息娱乐应用程序等。
具体展开如下：
CP_AUTOSAR软件架构下各部分功能细分如下图所示，其具体的功能需求及技术规范会在后续文章中展开。
二、AP_AUTOSAR，自适应平台分层软件架构
AP_AUTOSAR软件架构允许灵活和可扩展的汽车系统开发，与其前身AUTOSAR经典平台不同，自适应平台专注于具有高性能计算能力的下一代车辆。
主要分为四层：硬件/虚拟机层，基础服务层，ARA(实时运行环境)和应用层。
基础服务层：主要包括通信服务（COM）、加密服务（crypto）、日志记录服务（Log）、诊断服务（Diag）、存储服务（Per）、状态管理（SM）、执行管理（Exec）、时间同步（Tsync）、升级配置管理（UCM）等；
RTE层：管理系统内组件间通信；
应用层：采用C++编程，适用于性能要求较高的复杂应用和算法开发上（如机器学习、图像特征识别等）。
AP_AUTOSAR软件架构下各部分功能细分如下图所示，其具体的功能需求及技术规范会在后续文章中展开。
返回AUTOSAR总目录 (后续整理更新，可持续关注！)
5422
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
