近年来，汽车“新四化”（智能化、网联化、电动化、共享化）的快速推进，给汽车行业带来了新的技术变革，汽车的功能变得越来越复杂，尤其是智能座舱、智能驾驶、智能底盘的出现，促使汽车电子电气架构也相应地发生变革。
随着汽车智能化发展、汽车功能的增加，汽车上的电子控制单元（Electronic Control Unit，ECU）也越来越多，每个ECU的信号都必须在设计时进行静态规划和路由，为了应对这种增长带来的挑战，汽车行业正在采用1种新的架构，即面向服务的体系架构（Service-Oriented Architecture,SOA）。
SOA是从遵循服务导向原则的可重用服务中构建复杂软件系统的方法。SOA也是1个组件模型，将应用程序的不同功能单元（称为服务），通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务以1种统一和通用的方式进行交互。SOA可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中因软件代理交互而产生的人为依赖性。
SOA的特点是松耦合性、路径透明、可复用性、一定的标准化，不涉及底层编程接口和通讯模型。
SOA在IT行业中已经使用了多年，旨在描述和构建分布式系统。同时，面向服务的设计在汽车工业中也变得极为重要。
传统汽车通讯是基于信号的通讯方式，即信息发送者不关心谁接收而只负责将信号发送出去，接收者也不关心是谁发送的，而只负责接收信号，这种方式适用于有限大小控制数据的应用场景。
SOA代码灵活性强，支持请求/响应模式，支持复杂的数据模型，可扩展性强，能够满足自动驾驶等应用场景下，大量数据的动态交互，可以对系统进行部分更新，如图1所示。
图1 面向信号与面向服务对比
汽车领域采用SOA的优势是能加快车辆与互联网的互联互通。比如，能够将各种新功能灵活地与互联网集成；能够实现更高效的车载自动诊断系统OBD（On Board Diagnostics，OBD）及空中下载技术（Over-The-Air Technology，OTA）软件升级，有助于实现各种远程诊断、预诊断功能；能够大幅提升影音娱乐功能的用户体验，能够实现不同平台间的各种App共享功能；更便于实现平台架构升级；同时各个服务可以由不同团队独立开发，可以缩短车辆开发的时间。
Wonseon和Seung设计了端到端的SOA，如图2。
图2 端到端面向服务的架构
在传统的车载网络中：
（1）许多ECU是基于CAN等旧式IVN进行工作。
（2）大量的车辆信息和功能也来自旧式IVN。
（3）基于以太网的ECU上的新应用程序应可以访问这些信息/功能。
在本架构中，主要的功能模块有SOA适配器（SOA Adaptor），SOA网关（G/W），SD代理（SD Proxy）和服务路由（Service Router）。下面将介绍各个模块的功能。
3.1 SOA适配器
（1）将信息/功能从旧式IVN转换为“服务”，任何基于以太网的ECU上的应用程序都可以轻松访问。
（2）在以太网方面，服务是在SOME/IP协议之上提供的。
（3）可以在旧版IVN和基于以太网的IVN之间的“桥接ECU”上实现，例如域控制单元，区域控制器等。也可以仅在具有以太网接口的非桥接ECU上实现。
（4）SOA适配器提供的服务可以动态更改。
（2）必要时转换协议并翻译。
（3）缓存外部信息以处理外部网络的可用性和成本问题。
（4）应用策略并执行服务级别的访问控制。
（5）应该在具有外部连接的ECU上实施。
（1）可以使用SD代理实现集中式SD。通过1个称为“SD代理”的中央模块交换服务发现消息。SOME/IP-SD消息也可用于ECU与SD代理之间的通信。
（2）分布式SD方法的安全和流量问题可以由集中式SD处理。每个服务只能由允许的ECU查找和订阅。可以有效地监视服务可用性和搜索/订阅尝试。
可以使用服务路由器来处理来自SOA分布式性质的问题。服务只能通过服务路由器来使用。服务路由可以应用于选定的服务。SD代理可用于高效的服务路由实施，安全和资源问题可以得到有效处理，可以基于域、ECU、服务甚至方法来控制服务访问，策略也可以动态应用。
SOA是汽车以太网和IP带来的汽车系统/软件体系架构的创新，其概念可以扩展到从传统ECU到外部设备的端到端范围。SOA适配器和SOA网关可以分别用于旧设备和外部设备。通过使用其他SOA实体可以有效地管理SOA。端到端SOA支持快速高效地部署各种互联汽车服务。
刘佳熙等在面向服务架构汽车软件开发方法和实践中，提出SOA汽车软件的分成模型，如图3示。
图3 SOA汽车分层模型
该模型主要包括3个层级：元服务、基础服务和应用服务，通过不同的服务层级来分别对应不同层级的汽车业务逻辑。
元服务是最小单元。包括汽车的传感器和执行器等的基本接口。基础服务是中间层服务，在利用元服务的基础上，可自定义汽车业务模块，比如利用自车状态服务和雷达传感器等服务，组合出环境信息融合的服务。应用服务是最顶层的服务，可以访问和调用基础服务以帮助其解决业务问题。
在设计中，上层服务调用下层服务，下层服务不调用上层服务，这一原则有助于构建清晰简单的SOA汽车软件架构。宝马公司在新一代的E/E架构中引入了SOA的方法，如图4所示。SOA为整个系统提供大量的抽象服务。严格的封装和层次结构允许针对接口和使用敏捷方法进行测试，并且降低了系统复杂性。在各代汽车之间重用软件组件将变得更加简单。
图4 BMW下一代E/E架构
大众MEB平台车载应用服务架构（In-Car Appli⁃cation-Server,ICAS），采用了1种可升级的新方法，如图5所示。采用集中式功能与应用程序软件和I/O功能分离的架构，来降低整体系统复杂性和应用程序之间的依赖性，同时可以高效快速地开发客户功能，提供一些客户职能所需的基本服务，并且利用面向服务的通信。
图5 大众MEB平台车载应用服务架构升级方法示例
在该架构中还强调，SOA是数字化的关键，如图6所示，该架构的优点如下：
图6 面向服务通信架构
（1）采用面向服务的通信；
（2）使用服务发现和发布/订阅进行动态绑定；
（4）接口的向前和向后兼容性。
最后，通过提高可更新性、可升级性、重用能力和便携性，使大众汽车可以实现各种功能。
在AUTOSAR自适应平台（Adaptive Platform，AP）设计中，为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可扩展性，AP遵循了面向服务的体系结构理念。
SOA通常具有AP所具有的系统间特性。例如，服务可以驻留在应用程序运行的本地ECU上，也可以位于远程ECU上，该远程ECU也在运行另一个AP例。
上汽组建“零束”软件子公司，聚焦基于SOA技术的智能驾驶系统工程，同时推出“Z-ONE”的SOA开放平台，致力于打造上汽SOA的软件生态。该平台是以SOA理念打造整车功能，将汽车各个功能模块化。同时可以让第3方开发者甚至是普通用户参与到软件功能的打造。
威马汽车在2021年4月交付的威马W6汽车，率先推出了车辆自定义场景编程功能，实现25种能力、自定义场景超100个、手机端与车机端的同步，未来将携手用户及开发者，打开“千人千面”的全新格局。
Andreas等开发面向服务的车用应用程序，并使用空中软件更新部署。主要流程如图7所示。
图7 汽车的SOA开发流程
研究背景如下：在巴塞罗那举行的2019年世界移动通信大会上，梅赛德斯·奔驰展示了1款经过改装的车辆，可与开源SuperTuxKart游戏一起用作沉浸式游戏系统。游戏是使用真实的方向盘控制游戏中的车辆，空调模拟虚拟赛车的气流、温度效果。
Andreas假设车辆类型的制造商现在想要开发这样的游戏系统并将其部署到车辆上，可作为车主购买的可选更新，其开发流程如下。
首先，进行需求分析，具体过程如下：
（1）主机将显示1个赛车视频游戏。声音应来自车载音响系统。
（2）游戏中的效果应由实车反映，例如：空调应根据游戏中的场景（即驶过火山）和虚拟车的速度调节气流和温度。游戏中的撞车事故应通过可逆安全带拉紧器告知用户。电动座椅调节器和按摩器可产生更多的触觉效果。在虚拟比赛开始时，车内的环境照明应用作交通信号灯。
（3）虚拟车辆的水平动力学应根据当前方向盘角度得出。
（4）虚拟车辆的速度应从油门踏板和制动踏板得出。
（5）中指定的效果体验应与视频游戏中显示的情况相匹配。
（6）游戏的最小帧速率应为30 fps。
还存在一些非功能性需求：
（1）此功能应部署在现有汽车上，无需对硬件进行任何修改。
（2）该功能不得损害机动车的安全。
（3）只有在车辆周围环境允许安全操作时，该功能才有效。
5.2 起草软件和系统架构
根据起草软件和系统架构，构建面向服务的部分。
5.2.1 分解
实现“SuperTuxKart”应用程序的必要组件在某种程度上遵循面向服务、面向信号的方法。
面向服务的部分：在这部分中，“Super-TuxKart”应用程序被描述为1个服务消费者组件（客户端）。消费的服务是喷油嘴服务（Nozzle）和转向/踏板状态服务（Steering/Pedal status）。其中，转向/踏板状态服务接口目的是定期接收踏板和转向角的状态，为“Super⁃TuxKart”应用程序提供施加的踏板压力和转向角；喷油嘴服务接口目的是实现对油泵执行器的控制，“Su⁃perTuxKart”应用程序根据游戏中的场景和虚拟车辆的速度以所需的喷嘴效果强度刺激界面。如图8所示。
图8 面向服务部分的架构
面向信号的部分：软件架构的某些部分不会由服务接口实现，而是由经典的面向信号的方法。通常考虑与传感器和执行器密切相关的软件功能。对于该应用，必要的传感器是踏板和转向装置。执行器则是由喷油嘴表示。为了将3个组件集成到软件架构草案中，引入了图9中的信号接口。传感器踏板和转向装置为转向/踏板状态服务提供接口；执行器喷油嘴为喷油嘴服务提供接口（图9）。
图9 信号接口
5.2.2 部署
接下来，用适合的网络技术部署软件架构。考虑3个通信网络，包括：以太网，底盘/动力总成网络，LIN网络。
（1）第1个网络是以太网拓扑。3个ECU通过1个中央以太网交换机互连。ECU 1是中央计算平台。在ECU 1上，部署“SuperTuxKart”应用程序。对于踏板/转向服务，底盘/传动系统域的域控制器ECU2作为部署目标给出。以类似的方式，车身域的域控制器ECU3作为部署喷油嘴服务的目标。
（2）第2个底盘/传动系统网络：该网络描述两种基于CAN和FlexRay协议的系统总线拓扑结构连接到底盘/传动系统域的域控制器。。
（3）第3个网络描述了基于LIN协议的系统总线拓扑。在此网络中，专注于油泵执行器，该执行器部署在专用的LIN组件上，并由喷油嘴服务控制。混合通信如图10所示。
图10 网络混合通信
5.2.3 网络通信
“Super-TuxKart”应用程序所需的网络通信是以太网拓扑中面向服务的通信与CAN、FlexRay和LIN系统总线拓扑中的经典面向信号的通信相结合。
应用程序的开发阶段主要有3部分。
5.3.1 构建基础组件
SOA中的主要基础组件是API存储库，是1个中央数据库，包含详细的有关服务及其功能和接口的信息。可以部署到车辆内计算平台的应用程序可以使用这些服务为客户提供额外的功能。
5.3.2 现有服务的使用
一旦应用程序确定了需求，将通过API存储库并尝试找到可以满足所有要求的服务。理想情况下，存储库中的服务可以满足所有要求。在这种情况下，应用程序可以使用API存储库提供的接口描述来设计软件。由于面向服务架构的解耦性质，不需要对域控制器或背后的ECU进行修改。在“SuperTuxKart”示例中，应用程序设计将根据需求调整空调的气流，并在API中寻找合适的服务存储库。会找到喷油嘴服务并集成此服务接口到应用程序中。
5.3.3 创建新服务
当API存储库中的服务不能满足应用程序的需求时，需要联系API的创建者来进行更新API存储库，以满足开放的要求。由于这个扩展过程大大减慢了新应用程序的设计，因此API存储库设计时应提供尽可能多的功能。
要通过空中更新汽车嵌入式系统的软件，需要2部分：一部分由汽车制造商维护服务器，用于管理更新程序包；另一个负责接收，验证和分发更新程序的客户端，将文件更新到相应的ECU。
更新客户端功能通常在车辆的中央网关平台上实现，该平台可直接访问主机并代表通信总线之间的中央通信点。下载的更新包括1个或多个交叉编译的二进制文件，准备在相应的ECU中进行刷新。中央网关的更新功能（或服务）负责检查更新包，并将二进制文件分发到目标ECU。
该研究表明，使用现有服务可以较少的协调并提高开发速度。如果任何应用程序始终都可以使用现有服务，则可能会带来安全方面的挑战（即访问行驶中的车辆的主动悬架系统）。因此，有必要对汽车SOA的访问控制管理进行研究。
“分析和设计面向服务的架构”，“实现和部署面向服务的软件”是有效开发SOA汽车软件的关键环节。
为了实现汽车智能驾驶，通用高性能计算平台是未来新型E/E架构的硬件基础，而SOA则是“软件定义汽车”的软件基础。通过SOA平台，实现软硬件解耦、终端用户、汽车厂家及第3方开发者携手共建跨品牌、跨平台、跨车型的软件开发能力，打造以用户体验为核心，各方开发者共同参与、合作共赢的智能汽车生态。
在此生态里，汽车企业将不只是生产制造汽车，还将成为移动出行的服务供应商，能够面向用户提供多种多样的软件服务。SOA软件平台上多方的协同合作，将为软件汽车的不断进化和用户体验的不断提升提供源源不绝的动力。未来，车主可以根据乘员数量、道路情况、目的地甚至自己心情等不同条件，在车机及移动端APP上下载配置不同的功能，满足个性化需求。在SOA软件平台的帮助下，通过数据、算法、软件的不断积累和迭代升级，最终汽车将由执行指令的冰冷机械，进化为能够实时交流、洞察需求、主动服务的“有生命的出行伙伴”。
互联网软件架构是否会对汽车软件传统嵌入式领域系统架构产生影响。今天随着小星来一起讨论一下汽车面向服务软件架构SOA是什么，以及会给汽车行业带来哪些变革吧。
传统车企（上）和科技新势力（下）SOA实施对比综上所述，介绍了互联网软件架构当中广泛使用的面向服务SOA架构，基于面向服务SOA的域控制器架构成为智能汽车发展的必然趋势，以及SOA架构给汽车行业的带来各种变革和实施现状。希望今天的介绍能够让大家更好地了解汽车行业数据决定体验软件定义汽车的新趋势。
1 前言
借鉴SOA（Service Oriented Architecture）架构在IT行业所体现出的优势，部分主机厂开始将其引入到了汽车行业中。
主机厂可以基于SOA架构的优势，建立自己的软硬件平台，整车各控制器的软硬件开发都遵守统一的开发架构及标准，这样可以有效地缩短整车的研发周期（已开发功能可以灵活复用，新开发功能可以多方参与）、降低开发成本。
图1 远程诊断系统架构
图2 远程诊断服务器
3 远程诊断系统的应用
基于SOA 新架构所具有的车辆功能的灵活性以及汽车远程诊断系统连通了车、云之间通讯的优势，提出了为满足客户多样化需求而制定的相关应用，既可以有效地提高用户的满意度和体验感，同时也可以简化整车厂同一车型车系的结构，进而缩减相应车辆管理、生产线工作相关内容，提升整车厂工作效率。
3.1 车辆功能配置服务
基于该应用，用户可以通过手机客户端、车辆娱乐主机屏方式，查看自己车辆的当前硬件，哪些功能是可以新增或关闭的，针对功能的变更，详细变更内容清单、各项费用以及如需加装硬件对应详细信息都会呈现。如无需加装硬件，或已安装需求硬件，则通过在线付费或免费进行预约升级，满足功能升级条件后则自动升级。该应用可以最大程度地满足客户对新功能技术的需求，同时费用的透明化将进一步增加客户对品牌的信赖度。
基于该应用，整车厂以及用户都可以发起车辆的体检服务，不同角色有着不同的体检方案，整车厂可以针对某一批量或某种车型发起集体体检服务，用户则可以对自己授权车辆发起体检。
根据体检内容的不同（可以对零部件、系统或整车进行体检）进而调用远程诊断服务器中不同的服务，该服务通过车、云的通讯将对应运行程序或脚本下载到车辆，车端远程诊断客户端会根据程序或脚本内容进行解析以及执行数据的收集，将收集完成的数据统一回传到远程诊断服务器中，该服务器中的健康分析模块根据此服务类型信息调用知识管理模块中对应的失效模型，基于预设的分析逻辑，最终分析得出服务的体检报告，进而呈现给服务的发起者。
用户根据该服务可以及时了解自己车辆的状态，进而保障自己每一次出行的安全性。整车厂可以根据该服务获取重要数据，进而逐步优化自己的远程诊断系统，保证系统准确性的同时也可针对车辆潜在的问题提前发现进而规避处理。
用户也可以基于该应用实时了解车辆保养情况以及各控制器相关信息，提前合理安排车辆的保养计划以及保证车辆所有控制器随时处于最新状态，使得车辆处于最佳工作状态。
图3 车辆快捷服务功能结构
（2）汽车远程诊断系统实现了车辆与云之间的通讯，为整车厂研发提供了一个新的平台，基于此平台开发了面向整车厂或用户的一系列相关应用，以此实现整车厂的闭环式研发以及新的售后服务模式，同时也最大程度的满足了用户的多样化需求，在保证用户满意度以及体验感的前提下也提高了用户的行车安全。
（3）基于远程诊断系统所具备的车辆数据获取的便利性、灵活性，在车辆数据逐步积累的前提下，结合大数据分析技术的快速发展，未来针对远程诊断与大数据技术相结合方向的研究，将会是必然的趋势，也定当在车辆研发的数据闭环方面以及相关新领域，如车辆故障预测等方面表现出可观的优势。
如果没有特斯拉的出现，汽车行业平静的日子或许能维持的更久一些。
2017年7月，Model 3正式开始交付。在数家车企和机构对其进行从外到内的细致拆解之后，得出的结论包括：“其电子电气架构堪称杰作”、“比丰田和大众领先六年”、“做不到”……
Model 3颠覆了传统的电子电气架构，创造性地使用了域控制器，并让讲Linux一种语言，彻底抛弃了在传统汽车世界里“不容置喙”的权威软件架构——AUTOSAR。
特斯拉的做法相当于在一个几乎所有人都用木头盖房子的世界里，用砖和水泥盖了一个房子。
是异类，但却成为智能汽车时代的引领者。
在特斯拉的“刺激”之下，一场汽车软件革命呼啸而来。
分布式电子电气架构显然已经落伍，而系统软件架构AUTOSAR，又能否追赶上智能化的浪潮？车企是否需要和特斯拉一样，彻底打破一切传统，才能真正掌握自己的生与死？
传统车企的命运开始在这场剧烈的革命中变得飘忽不定。
当前，全球几乎所有的整车开发都需要依赖AUTOSAR，是汽车广泛使用的嵌入式系统软件架构，是汽车世界中最权威的软件开发规则。
这样一套复杂、严谨、庞大的规则体系的建立，还要从一个个小小的电子控制单元（ECU）说起。
1950s—1970s，是汽车电子技术的起步时期，一些车企开始用电子零部件来代替机械部件，改善车辆的性能。但这一阶段，汽车电子还只是在汽车收音机、电子喇叭、电压调节器等比较简单的领域发挥作用。
70年代末到80年代初，集成电路以及16位以下的微处理器在汽车上开始应用，电子装置开始应用在机械装置无法解决的复杂控制功能方面，包括自动门锁，自动除霜系统、装车预警系统、自动巡航等。
到了90年代，汽车电子已经深入到可以实现各种功能的综合系统，包括发动机控制与自动变速器控制为一体的动力传动控制系统、制动防抱死系统等。
随着汽车电子的发展，ECU从最开始简单的控制收音机，逐步深入到汽车的各个角落，成为驱动汽车执行每一个动作的大脑。
时至今日，一辆普通轿车上，ECU的数量已经达到70个以上，车辆功能越复杂，ECU数量则更多。
1993年，一辆奥迪A8上面使用的ECU数量仅有5个，但到了2010年，ECU数量就已经突破了100个。
然而，进入传统汽车的底层，会惊讶地发现，这是一个无比混乱的世界。
这些独立的“小电脑”如同一个个独立的王国，说着不同的语言，彼此之间通过CAN/LIN总线进行微弱的通信。
管理这些ECU的难度不亚于管理一个“小宇宙”。大众品牌一台车上的70多个控制单元的操作软件可以来自多达 200 家不同的供应商。可想而知，让协调起来是多么困难。
“一只章鱼有 8 个手臂，每个手臂都有自己的小脑子来管理。这 8 个小脑子与中央大脑进行通讯。科学家尚未弄清这一切如何运作，以及为什么这些手臂不会互相挡住。
汽车面临着本质相同的挑战，但进展并不乐观。各个控制器的“手臂”仍在按照自己的方向行动，没有协调，很快就能耗尽车辆中可用的能量。”
然而，汽车就是在这样混乱的状态下渡过了40多年。
更致命的是，早期ECU的软件和硬件高度耦合，紧紧地捆绑在一起，很难将彼此拆开。
软件和硬件之间如此亲密的关系，给车企和供应商带来了巨大的痛苦。
每当需要更换新的硬件时，都需要对ECU的软件进行重新编写和大规模的修改，随之而来的还有一系列的测试。任何微弱的变动都将带来灾难性工作量。
这一切都导致了整车开发周期漫长无比，并且车企需要为此支付高昂的研发费用。
汽车的软硬件之间亟需一个类似于电脑操作系统与应用程序之间的“中间件”，将软硬件解耦。
于是，AUTOSAR应运而生。
将全球各家车企和供应商的软件开发标准统一，无疑需要汽车界巨头们的强大号召力。
2003年，由全球最大规模的几家汽车企业、零部件供应商以及电子、半导体、软件系统公司，联合成立了一个汽车开放系统架构联盟——AUTOSAR联盟，并推出了一个开放化、标准化的汽车嵌入式系统软件架构——AUTOSAR规范。
目前AUTOSAR联盟已经囊括了100多个会员。各会员依据其对AUTOSAR的贡献及责任分为三个等级：核心合作伙伴（Core Partners）、高级合作伙伴（Premium Partners）、发展合作伙伴（Associate Partners）。
包括大众、丰田、宝马、戴姆勒、大陆、博世、福特等在内的9家核心公司是AUTOSAR协议的发起人，也负责AUTOSAR开发模式的筹划、管理和调控。
由此，一个史上最为庞大的汽车软件联盟形成了，在这些主力军的加持下，汽车行业大大小小的企业都纷纷投入AUTOSAR的怀抱，AUTOSAR也成为了最权威的软件开发标准。
在AUTOSAR刚刚兴起的时候，一些公司甚至会将使用AUTOSAR架构作为宣传点，使用AUTOSAR则代表着车辆有最靠谱的安全保障。
整个架构从上到下分层依次为：应用层（Application Software Layer），运行时环境（RuntimeEnvironment，RTE），基础软件层（BasicSoftware Layer，BSW），微控制器（Microcontroller）。
每层之间为保持独立性，每一层只能调用下一层的接口，并为其上一层提供接口。
分层架构是实现软硬件分离的关键，也使得汽车嵌入式系统控制软件开发者，得以在ECU软件开发与验证过程中，摆脱对硬件系统的依赖。
AUTOSAR的出现极大的解决了车企和供应商们最大的苦恼，大大降低了软硬件之间的耦合度。所带来的好处是显而易见的：
1.有利于提高软件的复用度，使软件可以跨平台复用；
2. 便于软件的交换与更新；
3. 软件功能可以进行先期架构级别的定义和验证，从而减少开发错误；
4. 减少手工代码量，减轻测试验证负担，提高软件质量；
5. 使用一种标准化的数据交换格式，方便各个公司之间的交流合作。
这些优势，使得各个企业在保证软件质量的同时，大大降低了开发的风险与成本。
AUTOSAR不仅在软件的功能、接口上进行了一系列的标准化，还提出了一套规范化的开发流程与方法，使得更多的软件供应商进入汽车电子行业，大家都遵循同一个标准去开发。
总而言之，有了AUTOSAR架构，车企可以完全成为“甩手掌柜”，不需要再管难度最大的底层软件问题。
任何事物都有两面性，AUTOSAR在解决问题的同时也带有着很多先天和后天的弊端。
首先，AUTOSAR是巨头们制定的游戏规则，成为了巩固自己垄断地位的方式。巨头们通过AUTOSAR设定了一套技术壁垒，将想进入汽车行业的玩家挡在自己的世界之外。
目前全世界范围内能开发完整的基于AUTOSAR架构底层协议栈的公司寥寥无几，国内更是几乎为零。大部分Tier 1和主机厂都无法自己建立AUTOSAR架构，主机厂和Tier 1需要向少数几家供应商购买底层软件。
当然，购买这些软件需要付出昂贵的费用，一个ECU的开发费都在几十万左右，如果“全套”下来，开发费至少要在千万级别之上。
这笔钱几乎等同于进入汽车世界的“门票”。
据一家车企的开发人员透露，如果不采用AUTOSAR架构，供应商甚至无法及时提供硬件。大家都是遵照AUTOSAR标准开发，如果想特立独行，不好意思，只能先等等，以及，付出更高的开发费用。
此外，AUTOSAR面面俱到的规范文件也给软件工程师们带来了繁杂的工作。这些规范如同八股文一样，工程师们需要按照严苛的按照标准进行“写作”，不可以越雷池一步。而AUTOSAR的标准高达上百页，工程师们以一己之力很难真正理解。
但是，这些都不足以颠覆AUTOSAR的地位，在传统汽车世界里的重要性是毋庸置疑的。
对AUTOSAR来说，最致命的是，是传统汽车时代的产物，进入到智能汽车时代，已经力不从心，尽显疲态。
当前汽车产业迎来了智能化的转型浪潮，整车电子电气架构架构开始由分布式变为域集中式，又逐渐成为中央集中式，大大的提升了算力利用率，减少算力设计总需求，并让数据统一交互，实现整车功能协同。此外，线束也大大缩减，降低了故障率并减轻了质量。而车载网络也由LIN/CAN总线向车载以太网发展。
传统的AUTOSAR架构（Classic AUTOSAR）已经不能适应智能化的需求。
当然，AUTOSAR本身也开始与时俱进，推出了Adaptive AUTOSAR，主要面向更复杂的域控制器和中央计算平台的电子电气架构。
此前车辆单一的Classic AUTOSAR架构也开始逐步向 Classic AUTOSAR 和 Adaptive AUTOSAR混合式架构。
在混合式的架构中，Classic AUTOSAR应用于传统嵌入式 ECU 中，包括发动机控制机和电机控制器，而Adaptive AUTOSAR更多的应用于 ADAS和自动驾驶等对于计算能力和带宽通信要求更高的领域中。出于对于汽车安全的要求， Adaptive AUTOSAR 还介入驱动底层。
然而，当《建约车评》询问镁佳科技创始人庄莉和理想汽车智能与系统副总裁范皓宇，Adaptive AUTOSAR是否可以真正满足智能化的需求，得到的答案都非常肯定：不能。
在特斯拉出现之前，传统汽车采用的电子电气架构是分散的ECU，而特斯拉是第一家对整车电子电气架构进行大刀阔斧变革的车企，并采用CCM中央计算模块，将4G模块、ADAS域控制器和智能座舱的计算单元，整合在一块主板上，形成了汽车的“中央计算平台”。
中央计算平台算力更高、处理能力更强。显然是分散式的、仅能处理单一任务的ECU无法企及的。
两个处理器有着天壤之别，特斯拉在中央计算平台的基础上形成了基于Linux开发的实时操作系统，而AUTOSAR则是在独立的ECU基础上开发的中间件。
正如功能手机向智能手机转换，需要有新的架构和新的操作系统来支持智能手机丰富多样的功能。如果工程师们试图通过修改塞班系统来让功能手机变成和搭载Andriod、iOS系统一样的智能手机，难度无异于“点石成金”。
因此，在车内的硬件处理器架构发生变化之后，此前面向ECU开发的中间件和操作系统，已经不再适用于新的面向域控制器和中央计算平台的硬件构架，无法继续作为操作系统和中间件。
新的操作系统对内存、文件系统、多任务调度有很好的支持，而此前的ECU只有一个任务在重复执行。所以在这种情况下，Autosar为了适应新的变化，推出了Adaptive Autosar。
然而，参照功能手机的时代，曾经的塞班系统面对智能手机的浪潮挣扎了很久，但无论付出多大努力，也根本无法成为一个完全为智能手机设计的操作系统。
同样，AUTOSAR无法通过修补一个为ECU设计的构架，来适应新的中央计算平台。
这是AUTOSAR与生俱来的弱点。
范皓宇指出，AUTOSAR出现背景本身就是电气化，而不是智能化。这样的一套框架能够让整车厂和多个不同供应商之间在软件部分有共通的框架，确保稳定可靠的功能从物理连接变成电气连接。
在智能化的趋势下，计算平台和系统架构的演进方向，应该是让整车可以持续迭代、升级，改善性能以及用户体验，并能够提高应用开发效率，这需要一个更加统一和高效的操作系统。
仅仅保证功能稳定标准可靠是不能满足需求的，用一个统一的确保稳定可靠的架构，来承载灵活多变是很难实现的。
庄莉指出，随着每个时代硬件的发展，为上一个时代的硬件设计的软件构架都会被自然地淘汰。一个时代的硬件，需要一个为专门设计的软件构架来配合。
AUTOSAR的的另一个危机在于，在智能汽车时代，软件已经成为汽车的大脑，是整车最核心的部分，软件的背后是用户和海量的数据，以及整车OTA能力，如果车企没有软件能力，等同于将自己的命运交付到别人手中。
AUTOSAR架构对于车企而言，就如同一栋已经盖好的房子，住户无法决定高度、面积和户型，唯一可以改变的只有内部的装修。这也就大大限制了车企的自由度，失去了自己的个性，更重要的是失去了底层控制能力。
基于AUTOSAR开发的控制器的软件工作由供应商完成，供应商占据着绝对的主导权，也意味着车企想要整车OTA必须通过供应商完成。
车企只能依靠卖硬件赚钱，这样的盈利模式显然已经不够“性感”。
看看特斯拉最近的举动，就不难理解整车OTA对车企未来命运的重要性。
将整车OTA做到出神入化地步的特斯拉，已经开始利用这一强大的能力为自己赚钱。
今年2月份，特斯拉开始为美国地区的Model 3 长续航后驱版以及长续航后驱升级版车型提供后排座椅加热升级包，升级包的价格为300美元。
5月9日，特斯拉官又方针对model 3长续航全轮驱动版车型推出了付费升级加速能力的服务，通过OTA升级，可以将车辆百公里加速能力从4.6秒提升到4.1秒。为此，车主需要花费1.41万元。
OTA彻底改变了车企的盈利模式，让车企和用户之前不再是“一锤子买卖”，可以通过软件升级提供新功能来持续赚钱，并且没有任何额外成本。这样的诱惑，是任何企业都难以抗拒的。
如果将底层软件能力交给供应商来做，首先车企和供应商之间存在博弈，能不能实现要打个问号。即使可以实现，供应商也要从中收取一大笔费用，车企或许只有喝汤的份。
同样类比智能手机，很难想象如果操作系统以及核心软件不掌握在苹果手中，每次系统更新推送都是由供应商代为处理，是否还会获得和今天一样的使用体验，而世界上也会少了一家万亿市值的科技公司。
由此，有能力的车企正在疯狂地试图将软件能力夺回来，建立自己的软件开发能力。
在这样的背景下，AUTOSAR的权威地位正在被动摇。是上一个时代的强者，但终将落幕。
传统车企和汽车人正在觉醒。
前奥迪研发负责人兼董事会成员彼得·梅滕斯（Peter Mertens）于 2020 年 6 月说：“实话实说，站在个人的观点上，其实一直睡到了现在的状态。”“做了错误的决定。太信任供应商会以某种方式实现。”
汽车工程师Alex Voigt指出“没有软件，车企将失去数字时代的黄金，即客户数据”、“没有软件，公司大概就是个组装低利润的金属盒子的企业，并且这个低利润的金属盒子是个毫无价值的普通商品。”
然而，汽车企业日益增长的对软件部分的控制欲，与自身落后的软件开发能力之间的矛盾，已经成为当前最主要矛盾。
大众集团当前所遭遇的困境，说明了一切。
6月19日，前大众负责数字服务和软件的董事会成员Christian Senger称，公司希望使用开源方式改进其正在开发的基于软件的汽车操作系统。
Senger表示：“操作系统不是自己能够控制的东西。将定义核心，然后立刻加入开源组件，从而制定标准。这将为合作创造机会。”
这相当于大众希望自己建立一套标准的软件架构，为各个品牌和供应商提供一个开放的、通用的平台。最终的目标就是取代AUTOSAR。
Senger同时指出，主机厂目前非常依赖第三方开发，导致效率极其低下。
大众希望保留对整个汽车电子电气架构的控制，软件能力是确保长期竞争力的唯一途径。仅出于这个原因，大众不能让第三方完全获取车辆中的数据，这些数据应该留在公司内部。
高达70亿欧元的投入、5000人的庞大软件团队，都只为一个目标：实现大众汽车的数字化转型。
然而，让这位百年汽车工业巨头万万没想到的是，这一行行代码写起来真的让人感到“头秃”。
变革的强力推动者迪斯，甚至已经为此付出了惨重的代价。
7月1日起，迪斯不再担任大众乘用车品牌 CEO 的职务；紧接着在7月12日又有消息传出，迪斯的心腹、大众品牌软件研发负责人Christian Senger已经“被离职”……
一场由软件问题引发的血雨腥风，在沃尔夫斯堡上空弥漫。
隔行如隔山，传统车企相当于进入到了一个自己完全陌生的领域。
作为在数字化转型方面决心最大、投入最狠的大众，尚且举步维艰，那么其它大批传统的车企的命运又将如何？
专业的软件人才，将成为这场变革中的中坚力量。
大量的车企并没有办法像特斯拉一样，构建一套属于自己的软件架构，而目前一些新兴车企采取的办法是，在汽车传统机械部分选择继续使用AUTOSAR，充分利用其优势，而在与智能化有关的、需要灵活变化的部分，开始搭建自己的架构。
当然，这一部分也是未来汽车产品中最为核心的部分，将掌握在自己手中才真的安心。
毫无疑问的是，这些拥有软件能力的车企，将在未来智能化的竞争中脱颖而出。
然而，绝大多数的车企尚没有半点软件开发能力，最终的结局恐怕只能沦为组装厂，赚取微薄的生产加工费用。
生存还是死亡，这并不是个问题。
结尾：
五花八门的尖端科技在手机这个五英寸见方的空间里展现的淋漓尽致，并时不时通过OTA进行软件升级，带给人们新的体验。
然而，汽车这个更有想象力的移动空间却仿佛成了被科技和互联网遗忘的角落，四个轮子拖着沉重的躯壳，日日夜夜坚守着作为代步工具的唯一使命。
是时候发生些改变了。
但目前的现状是，大多数传统车企处于有心无力的状态，甚至大批的车企还没有真正苏醒过来。
像大众一样坚定地喊出转型并不容易，但更不容易的是真正的转型成功。
IOS系统架构
本文包含 Apple IOS 框架列表及其概述。尝试将大多数iOS 框架置于底层，可以帮助新开发人员入门并了解IOS开发大概。希望能帮助。
核心服务层中存在一些重要的框架，可帮助 iOS 操作系统自修复并提供更好的功能。如上所示，是架构中的第二低层。以下是该层中存在的一些重要框架：
在 Swift、Objective-C和基于 C 的应用程序中运行 JavaScript 程序的能力。还可以使用 JavaScriptCore 将自定义对象插入到 JavaScript环境中
在媒体层的帮助下，将启用系统的所有图形视频和音频技术。这是架构中的第二层
COCOA Touch 也称为应用层，充当用户使用 iOS 操作系统的界面。支持触摸和运动事件以及更多功能。
在应用程序中显示和操作 PDF 文档。
提供虚拟现实交互增强
可以看到还有N多层集成，每次IOs系统更新还会发布不少
IOS-Kit
前言
正如“100个读者就有100个哈姆雷特”一样，对于架构的理解不同的软件工程师有不同的看法。架构设计往往是一个权衡的过程，每一个架构设计者都要考虑到各个因素，比如团队成员的技术水平、具体的业务场景、项目的成长阶段和开发周期。
一些架构理念，如何设计一个简单的 iOS 架构。
一、关于组件化
组件化似乎是项目发展壮大过后必然要做的事情，能让各个业务线的工程师不需要过多的关注其他业务线的代码，有效的提高团队整体效率。然而实施组件化的时机是在需求相对稳定、产品闭环形成过后。所以本文不会应用组件化，但是这里简单谈谈业界的组件化方案。
组件化的核心问题就是组件间如何通讯。“软件工程的一切问题都能通过一个间接的中间层解决。”中介模式很自然的运用起来：
这样虽然能统一组件间的通讯请求，但是却没有避免 Mediator 和目标组件的耦合，ModuleA 工程中仍然需要导入 ModuleB 。
所以重点问题落在了解耦上：
要达到 Mediator 和目标组件的解耦，就需要实现之间的间接调用（图中虚线），既然是间接调用，必然需要一种映射机制。在 iOS 开发中，业界大概有三种方式来处理。
(1) 使用 URL -> Block 解耦
简单来说就是将组件的调用代码放入 block 中，然后 URL 作为 key，block 作为 value，存入一个全局的 hash 容器，组件通过一个 URL （比如 "native/id=10/type=1" ）向 Mediator 发起请求，Mediator 找到对应的代码块执行。由此，解开了 Mediator 和目标组件的耦合。
(2) 使用 Protocol 解耦
BeeHive 注册组件有几种方式，一种是监听了动态链接时 image 二进制文件加载完成的回调，通过修改代码段的方式判断对应的模块进行注册；第二种是在 +load 方法里面注册；第三种是异步注册，但是这种方式存在一个问题，可能组件使用方准备使用组件的时候，这个组件还未注册成功。
所以，组件数量过多的话，会延长动态链接库的过程。
BeeHive 为了让每一个组件享有独自的 app 生命周期、3D touch 等功能，会将这些系统级的事件发送给每一个组件，且不谈大量的方法调用损耗，必须让入口文件 AppDelegate 继承自 BeeHive 的 BHAppDelegate，笔者感觉侵入性过强，并且当开发者需要复写 AppDelegate 方法的时候，还要注意让super调用一下，可以说很不优雅了。
在基于协议的组件化方案中，组件使用方能直接拿到目标组件的实例，那么使用者可能对该实例进行修改，这可能会带来安全问题。
(3) 使用 Target-Action 解耦
Mediator 使用 Target-Action 来间接的调用目标组件，无需专门注册。组件维护者需要做一个 Mediator 的分类，通过硬编码调用目标组件，然后组件使用者只需要依赖这个分类就行了。封装的 Mediator 源码只有简单的 200+ 行代码，并且很易懂。这也让开发者能对组件化的实施更加有信心，不会因为基础设施的错误而束手无策。
小总结
关于以上组件化的简单表述仅代表笔者的个人见解，由于笔者并没有真正的实施组件化，所以理解可能有误。
虽然笔者设计的 iOS 架构不会应用组件化，但是这给架构设计带来了前瞻性的引导，这非常重要。
二、模块化思维划分文件
在团队开发中，项目发展到后期总是会出现某些文件或代码难以管理，出现这种情况的主要原因通常是项目开发过程中对文件的管理过于随意。
开发者应该尽量将所有代码文件归于模块，而不要出现模拟两可的文件。而笔者这里说的模块，是有具体意义的模块，比如图片处理模块、字体处理模块，而不是诸如 Public、Common 等无具体意义的代码文件。
试想，在多人开发中，当所有人都觉得有些代码不知道怎么归类的时候，就会往 Public 里面扔。当某天想要整理一下这个 Public，会发现已经无从下手；或者当需要迁移项目中的某个业务模块时，会附带迁移一些模块，当这个模块是有意义的（比如图片处理模块），迁移成本会非常低，但是当这个藕断丝连的模块是 Public 时，时间成本可能高于想象，估计会将完整的拷贝过去，而又对新项目造成了污染。
全局的公共文件是产生垃圾代码的源头。笔者认为几乎所有的代码都是可以归类为模块的。
大致梳理了一个文件分类，当然这个分类是灵活的，只是要分模块划分：
具体里面放了些什么，可以查看笔者的 DEMO。
三、减少全局宏的使用
很多时候，过多的宏让项目很不整洁，每一个开发者都往全局文件添加宏，而往往只是一段简单的代码，笔者认为开发中应该尽量少使用宏，原因如下：
实际上，非得使用宏的地方并非那么多，比如需要定义一个全局的导航栏字体方便使用，可以将通用字体的配置参数作为一个模块：
或者用常量来代替宏：
这么做也便于转换思维，毕竟 swift 中是没有宏的。
四、去基类化设计
代码设计中，应该尽量避免基类的使用，也就是说，不应该总是要求开发者去继承基类来做功能。使用基类将造成不可避免的耦合，为业务的长期发展带来阻碍（当然某些情况是可以使用基类的）。
其实使用基类就算了，若是将大量的业务逻辑放入基类中将是灾难的开端。试想，当项目新成员一来就看见成千上万行的基类代码TA作何感想？
另外一种场景，当需要将项目中的某个模块迁移到其他项目，或者需要将其他项目合并入当前项目，基类的合并将是一个非常头疼的问题，藕断丝连的模块和代码会让抓狂。
那么，类的工具方法应该放哪儿？对所有类的统一配置应该放哪儿？对封装模块的个性化定制应该怎么做？
装饰模式
类的工具方法，按道理说可以提取为模块，但是有些场景可能显得不够简洁。
其实只要留意 iOS 官方的 API，就不难发现装饰模式的大量应用，使用数个分类将大量的方法按照功能分类，会清晰且优雅：
不过要注意的时，定义分类的时候一定要加一个前缀标识以避免方法覆盖。
AOP
面向切面编程在 iOS 领域经典的应用就是利用 Runtime 去 Hook 方法：
代码中统一配置了 UIViewController 的系统导航栏返回按钮，注意这里调用的业务配置方法都是定义在 UIViewController 的分类里面的。若有某些导航栏需要格外配置返回按钮的需求，可以拓展一个属性来控制。
面向协议设计模式
对于一些封装的组件，多考虑使用协议来个性化定制，继承作为最差方案，而非是首选方案。
定义一个遵守组件定制协议的属性是常用的解决方法：
不同的属性作为不同的策略，组件内部通过调用对应的协议方法实现个性化定制。而当使用者想要改变策略时，只需要更改这个属性就行了。面向协议设计模式结合策略模式是一个很好的实践。
五、MVC？MVP？MVVM？VIPER？
业务具体的架构模式是个让很多开发者头疼的问题，因为有时候能让复杂业务更清晰，有时候却因为胶水代码过多而臃肿。
实际上为什么要严格的遵守架构模式呢？为什么每一个业务模块的架构模式都要一模一样呢？
认为正确的架构思路一定是根据业务来的，不同的模块，不同的业务线完全可以有不同的架构，只需要架构足够清晰不至于晦涩。
大致设计了一下架构的主旋律：
设计的项目目前不会很复杂，多数情况上面的架构就已经够用，若某个页面功能过多，完全可以提取一些额外的模块，比如 DataCenter 处理过于复杂，那就把数据的处理和缓存提取出来：xxxDataProcesser、xxxDataCache。这些都是灵活的，只需要按照模块化的思维提取，ViewController的代码相信也不会太多。
关于响应式框架
Reactivecocoa 虽然强大，笔者以前也用过，不过是一个重量级框架，学习成本有点高，可能会因为团队成员对其了解不足导致难以定位的错误。
而美团的EasyReact 似乎是一个福音，笔者大概浏览了一下源码，质量确实很高，对性能方面的处理很精致，基于图论算法的处理也感觉很棒，项目侵入性也很小。不过缺点就是太新了，需要开发社区一定时间的验证，暂时笔者持观望态度。
结语
本文只是作者思考过后对一个项目架构的简单设计，还有很多部分需要完善和补充，具体细节也可能会按照具体情况修改。Demo 只是一个雏形，希望和各位读者朋友能有所交流。