目录
一、嵌入式
1.1 什么是嵌入式系统
1.2 什么是汽车 ECU
1.3 如何了解一款MCU
1.4 谈谈代码静态分析
二、汽车软件
2.1 什么是“域控制器”
2.2 为什么是 ARXML
2.3 SOA：面向服务的架构
2.4 下一代的 EEA（电子电气架构）
2.5 ADAS的八大系统（汽车高级辅助驾驶系统）
三、流程类
3.1 什么是软件定义汽车
3.2 汽车软件开发 V 模型
3.3 谈谈 ASPICE
3.4 ISO 26262
3.5 功能安全
一、嵌入式
1.1 什么是嵌入式系统
它是以应用为中心，软硬件可裁减的，适应应用系统对功能、可靠性、成本、体积、功耗等综合性严格要求的专用计算机系统。
1.2 什么是汽车 ECU
电子控制单元，又称“行车电脑”、“车载电脑”等。是汽车专用微机控制器。
1.3 如何了解一款MCU
（1）ROM 空间、RAM 空间
（2）IO口 数 量 、 定 时 器 数 量 和 定 时 方 式 、 所 提 供 的 外 围 功 能 模 块、 中 断 源
（3） 工 作 电 压 及 功 耗 等 等
1.4 谈谈代码静态分析
功能安全规范ISO26262 建议在软件编码要遵循编码规范。
汽车领域最成熟的编码标准莫过于 MISRA C，保证代码质量。
静态代码分析：自动化工具，可以在开发人员电脑或服务器部署，自动分析并优化代码编程是否符合客观规范。
二、汽车软件
2.1 什么是“域控制器”
IPO模型：输入-处理-输出
域控制器：就是通讯和交通充分发展过程中的一个过渡性产物，最高目标规划是Server。
域控制器的发展至少要分为两个阶段：功能域控制器----区域控制器。
控制器体系架构发展：功能域控制器--区域控制器--中央控制器（Server）
2.2 为什么是 ARXML
XML：可扩展标记语言，用于传输数据；
在AUTOSAR规范下，ARXML文档的解析均已实现工具化。
2.3 SOA：面向服务的架构
基于软件的模块化和以太网的通信，提供标准的服务组件，使软件与硬件解耦，从而可以灵活的设计和扩展上层的应用。
SOME/IP的引进：SOME/IP是面向服务的通信中间件，是SOA的一种。
2.4 下一代的 EEA（电子电气架构）
方向：现在各个 OEM 包括各级供应商，努力在做的事情就是将现有的汽车上的功能重新定义成为服务，并改造现有的电器架构，将以太网作为主要通信设施，并将控制器逻辑上移至域控制器。
2.5 ADAS的八大系统（汽车高级辅助驾驶系统）
（1）盲点侦测系统：运用雷达和传感器， 来侦测车辆后方的盲点区，在盲点区侦测到车辆靠近时会向驾驶员提供警示
（2）停车辅助系统：自动泊车、车辆后方检测
（3）车道偏离预警系统LDW：采样车道的标示线，对比车辆位置，进行检测与提示
（4）碰撞预防系统FCW：前车车距检测、驱动自动紧急刹车系统
（5）适路性车灯系统：
（6）夜视系统：红外线来感知热量不同，识别前方道路情况
（7）主动车距控制巡航系统ACC：
（8）驾驶人生理状态监视：避免疲劳驾驶
三、流程类
3.1 什么是软件定义汽车
基础软件将成为架构演进和生态构成的中枢，对汽车行业及企业组织形态产生影响，具体如下：
主机厂：定义功能架构、及参与系统集成——还需参与应用开发，形成自己的差异化特征；
供应商：分工模式——硬件提供商、基础软件供应商、OS及虚拟化供应商、软件供应商、安全方案供应商（细分领域）
3.2 汽车软件开发 V 模型
V 模型是一个软件开发生命周期模型，其中的流程执行是以 V 形顺序进行。
V 模型是瀑布模型的扩展，它最大的特点就是每个开发阶段都对应一个测试阶段。这是一个高度严格的模型，下一阶段必须在上一阶段完成后才能开始。
- 缺点：因为 V 模型是顺序类模型，因此在项目开始之前，必须非常明确需求，因为回去进行更改通常很昂贵。
- 优点：V 模型简单易懂，易于管理，且每个阶段都有特定的可交付成果和审查过程。
V 模型左侧：设计--Verification 阶段（符合规范）：业务需求分析——系统设计——架构设计——模块设计——编码阶段
V 模型右侧：测试--Validation 阶段（满足需求）：单元测试——集成测试——验收测试
3.3 谈谈 ASPICE
ASPICE是一个 过程模型， 由过程和能力度两个维度构成，用于评价汽车行业软件设计开发的能力水平。
用于指导供应商的软件开发流程，改善车载软件的质量。
能力等级从 0 级到 5 级共分为 6 个层次：
【0 级】Incomplete，未完成。
【1 级】Performed，已执行。
【2 级】Managed，已管理。
【3 级】Established，已建立。
【4 级】Predictable，可预测。
【5 级】Innovating ，最佳化。
iNTACS去管理评估师，评估师个人进行ASPICE评估并签发评估结果——评估报告。
企业导入ASPICE：差距分析——ASPICE培训——制定流程、模板、检查单——按照流程执行——ASPICE评估。
与功能安全关系：ASPICEASPICE 只是对过程的要求，ISO26262 功能安全不光有过程要求，还有对产品设计开发的技术要求和具体技术细则，并且功能安全集中关注safety 相关内容。
3.4 ISO 26262
ISO 26262 提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。
ISO26262 提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs）
ISO26262 使用 ASILs 方法来确定获得可接受的残余风险的必要安全要求。
ISO26262 提供了确保获得足够的和可接受的安全等级的有效性和确定性措施。
该标准涵盖功能性安全方面的整体开发过程（包括需求规划、设计、实施、集成、验证、确认和配置）
认证机构：南德意志集团（德国）、莱茵集团（德国）、恒润科技、中国汽车技术研究中心
3.5 功能安全
FFI 原则：不同安全等级的模块之间，故障产生的相互影响必须避免，也就是要防止级联性故障。
故障分类：分为系统性故障和随机故障。随机故障通常发生在硬件方面，软件方面一般会产生的是系统性故障，由一些特定的人为因素引起。
- 内存方面系统故障：OS 需要提供 Memory Protection，配合硬件提供的 MPU (Memory Protection Unit) 来实现内存护.
- 时间方面系统故障：WDG 用于监测代码执行时间以及代码执行顺序等错误，目的是防止代码跑飞。
- 通信方面系统故障：E2E用来检测通讯方面的诸多问题.
