软件架构这部分，我们抛开一些闭源的诸如特斯拉的软件，来谈谈大家普遍接触的的Classic Autosar和Adaptive Autosar。我们整车上的控制器，分动力域的控制器，如发动机控制EMS、TCU等，还有信息娱乐域的控制器比如车机显示灯，不同控制器的实时性要求等方面是不一样的。例如发动机控制器ECU、或者整车控制器VCU实时性和功能安全要求要比与其他功能或信息娱乐性控制器高，动力域的基本基于Autosar经典平台开发，因其具有如下特点：
1、硬实时，可在us时间内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行。
2、高功能安全等级，其可达到ASIL-D的安全等级。
3、对CPU、RAM或Flash等资源具有较低的占用率。
4、软件功能通常是固化不可动态变更的。
而信息娱乐性控制器，则正好与上相反，其一般会占用较大的硬件资源，且一般实时性要求相对低，因其一般运行在嵌入式PC上，如LINUX，而不是汽车级操作系统上，所以其即使出现故障也不会造成严重的安全事故。而ApdativeAutosar则是连接这两者的桥梁，其具有如下特点：
1、软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果。
2、具有一定的功能安全要求，可达到ASIL-B或更高。
3、与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX。
Adaptive Autosar与Classic Autosar相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发，因此C++将成为AdaptiveAutosar平台的主要开发语言。
Adaptive Autosar的出现并不是为了取代ClassicAutosar平台，而是针对不同的应用场景实现两者的共存和协作，Classic Autosar平台支持高安全性和高实时性的应用场景，因此对于深度嵌入式的软件功能需部署运行在经典平台上，而Adaptive Autosar则支持并行处理的需要高性能运算的功能则需要运行在Adaptive平台上。
当然在软件架构方面本来是多样的，采用哪种就看主机厂如何考量和能力如何了，多软件架构，诸如Autosar、Adaptive Autosar、ROS等将会耦合集成。
为了满足汽车软件开发高质量的标准，ASPICE 过程模型被建立，ASPICE是安全和保障的基础，楼主相信这是未来保证软件开发质量的一个重要方面，不管是供应商还是各大OEM都应逐渐应用起来。
ISO26262标准则在流程和方法论方面定义了系统开发中功能安全的影响，对于软件架构，功能安全是一个非常关键的因素，如何设计车内系统使其能符合功能安全标准要求是一个巨大挑战，特别是在日渐增加的应用复杂性以及产品上市时间的紧迫性的双重压力之下。电子系统面临的挑战是构建的系统需要能够防止危险故障的发生或至少在出现故障时能够有效地进行控制。功能安全标准已应用于车辆安全系统，如安全气囊或 ADAS。ISO26262是从IEC61508标准派生而来，针对道路乘用车车辆内的电气/电子系统。该标准应对架构、功能和程序方面的问题，包括汽车安全生命周期，以避免并控制系统错误以及随机硬件故障。ISO 26262指定了四个ASIL等级(A至D)以确定标准的必要要求以及用于避免不合理残余风险的安全措施，其中D表示最严格的安全等级，A表示最宽松的安全等级。通过考量任务数据中系统故障可能导致伤害的那部分(即出现概率)；驾驶员应付系统故障并避免伤害的能力(即可控性)；以及可控性操作失败会导致的人身后果(即严重程度) 这三点，进行车辆层面的危险分析和风险评估，确定适当的ASIL等级。
最前沿的电子设计资讯
