一、OverView
1、AUTOSAR R20-11文档下载
- 官网下载:AUTOSAR
- 打包文档地址:AUTOSAR R20-11
2、文档组说明
AUTOSAR定义了三个文档组:ClassicPlatform(CP)、Adaptive Platform(AP)和Foundation(FO),基于CP和AP的ECU基于共同标准FO实现彼此连接
3、文档类型说明(参考AUTOSAR_TR_PredefinedNames.pdf)
缩写 | 全称 | |
TMPL | Template | 模板 |
SWS | Software Specification | 软件规范 |
SRS | Software Requirement Specification | 软件需求规范 |
PRS | Protocol Specification | 协议规范 |
RS | Requirement Specification | 需求规范 |
TR | Technical Report | 技术报告 |
EXP | Explanatory Document | 解释性文件 |
TPS | Template Specification | 模板规范 |
MMOD | Meta Model | 原模型 |
MOD | Model | 模型 |
ASWS | Adaptive Software Specification | 自适应软件规范 |
4、阅读导航
AUTOSAR是一个庞大的标准,包含了超过200份规范和20000个需求。建议从阅读标准中的Layed Software Architecture文档入手。接下来可以学习AUTOSAR方法论规范(Methodology)。在接下来就是有选择性的阅读AUTOSAR模板规范(TPS)和BSW的软件规范(SWS)了。阅读导航:
- FO:AUTOSAR_TR_FoundationReleaseOverview.pdf
- AP:AUTOSAR_TR_AdaptivePlatformReleaseOverview.pdf
- CP:AUTOSAR_TR_ClassicPlatformReleaseOverview.pdf
- CP:AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf
二、API怎么来的:需求分解细化
Autosar的API是由顶层需求PO不断分解细化,最后制定出各个FC的详细API和Service Interfaces。
参考:AUTOSAR_TPS_StandardizationTemplate.pdf
AUTOSAR为其标准化工作定义了四个级别的要求:
- AUTOSAR项目目标
- AUTOSAR主要要求
- AUTOSAR要求规范(RS、SRS、ATR)
- AUTOSAR规范(SWS、TPS、AI、TR、MOD、ATS、EXP等)
三、FO阅读记录
在AUTOSAR_TR_FoundationReleaseOverview.pdf里面对FO文件进行分类:
- ReleaseDocumentation
- General
- Methodologyand Templates
- Diagnostics
- CommunicationManagement
- Protocols
- HealthMonitoring
- Crypto
- Safety
- Security
- SystemServices
下面对整个文档浏览下:
File Name | 说明 | |
1、Release Documentation(2个) | AUTOSAR_TR_ FoundationReleaseOverview.pdf | FO总的概述 |
AUTOSAR_TR_ FoundationSpecificationHashes.sha256 | sha256文件 | |
2、General(5个) | AUTOSAR_EXP_ FoundationDiagramSource.zip | AUTOSAR_MOD_BSWUMLModel.eap |
AUTOSAR_TR_Glossary.pdf | 总词汇表 | |
AUTOSAR_RS_Main.pdf | PO分解出44个主要功能需求("RS_Main_”) | |
AUTOSAR_TR_PredefinedNames.pdf | 1.介绍各种预定义名称,分为: • TR_PDN_00001:虚拟模块缩写 • TR_PDN_00002:类别缩写 • TR_PDN_00003:文档跟踪前缀缩写 • TR_PDN_00004:名称空间缩写 | |
AUTOSAR_RS_ProjectObjectives.pdf | 8个顶级需求:PO(“RS_PO_”前缀) | |
3、Methodology and Templates(20个) | AUTOSAR_TPS_ ARXMLSerializationRules.pdf | 1.介绍ARXML序列号规则,具体通过:TPS_ASR_00001-TPS_ASR_00019来一一阐述细节 |
AUTOSAR_TPS_ FeatureModelExchangeFormat.pdf | 1.需求索引:RS_FMDT0000* 2. 增加了对变体处理的支持,特征模型由三种不同的结构组成:特征模型本身、特征选择,最后是特征图 | |
AUTOSAR_RS_ FeatureModelExchangeFormat.pdf | 1.需求索引,前缀: ”UC_FMDT_*” –> ” RS_FMDT_*” 2. 总体工作: • OEM使用工具集a开发AUTOSAR模型和功能模型。 • 然后,两个模型都交给供应商完成。 • 然后,供应商使用工具集B加强工作,并将其传递给OEM。 • 然后OEM重新导入AUTOSAR模型。 这可能在开发周期中发生多次 | |
AUTOSAR_MOD_MiscSupport.zip | AUTOSAR Miscellaneous Support Files: • BSW_dictionary.DIC • M1_dictionary.DIC • M2_Dictionary.DIC | |
AUTOSAR_MOD_GeneralBlueprints.zip | AUTOSAR M1模型蓝图集合,这个ZIP存档包含一组arxml文件,内容如下: • 可交付成果的元数据(免责声明、版本、自述文件) • 预定义名称的关键字集 • 标准化服务接口的端口接口和类型 • SWS内存映射的SwAddr方法 | |
AUTOSAR_TR_ AutosarModelConstraints.zip | Collection of constraints on AUTOSAR M1 models: 1. AUTOSAR_TR_FoundationAutosarModelConstraints.pdf • TPS_AbstractPlatformSpecification • TPS_FeatureModelExchangeFormat • TPS_GenericStructureTemplate • TPS_SecurityExtractTemplate • TPS_StandardizationTemplate 2.AUTOSAR_TR_AdaptiveAutosarModelConstraints.pdf • TPS_AdaptivePlatformTimingExtensions • TPS_ManifestSpecification 3.AUTOSAR_TR_ClassicAutosarModelConstraints.pdf • TPS_BSWModuleDescriptionTemplate • TPS_DiagnosticExtractTemplate • TPS_ECUConfiguration • TPS_ECUResourceTemplate • TPS_SafetyExtensions • TPS_SoftwareComponentTemplate • TPS_SystemTemplate • TPS_TimingExtensions | |
AUTOSAR_TPS_ GenericStructureTemplate.pdf | 1.需求索引:TPS_GST_* 2.介绍元模型的内容,元模型层次结构 • M0:AUTOSAR对象 • M1:AUTOSAR模型 • M2:AUTOSAR元模型 • M3:AUTOSAR模板的UML配置文件 3.内容比较碎,主要目录结构: • 第3章解释了所有AUTOSAR模板通用的顶层结构。 • 用于设计AUTOSAR模板的机制: (a)第2章描述了AUTOSAR模板UML概要文件的一个基本方面 (b)第4章描述了与编译器的标准库类似地收集的通用模板类。 (c)第5章解释了具有抽象关系的抽象类。这些结构实现了适用于所有AUTOSAR模板的特定概念。 (d)第6章概述了通过模型转换应用的方法 • 元模型中设计机制的一些具体应用 (a)第7章描述了基于元建模模式的AUTOSAR模板中变体处理的实现 (b)第8章描述了AUTOSAR M2模型中可拆分元素的实现。 | |
AUTOSAR_TR_ InteroperabilityOfAutosarToolsSupplement.zip | AUTOSAR工具互操作性补充,R20-11/PDEP_基线轮廓-R21-1.arxml:BaselineProfile明确定义了TPS_StandardizationTemplate中定义的ClassTailoring和AttributeTailorings的默认值 | |
AUTOSAR_MMOD_MetaModel.zip | Meta Model: AUTOSAR_MMOD_MetaModel.eap | |
AUTOSAR_MMOD_XMLSchema.zip | Meta Model-generated XML Schema: • AUTOSAR_00049.xsd:这是作为AUTOSAR提供的AUTOSAR XML模式 • autosar.soc:此AUXILIARY文件提供一个OASIS开放目录文件,该文件引用AUTOSAR XSD文件。 • xml.xsd格式:这是W3C提供的xml命名空间的模式。 | |
AUTOSAR_RS_Methodology.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ” RS_METH_*” 2.介绍方法论需求: • 一般需求 • AP专用需求 • CP专用需求 | |
AUTOSAR_RS_SecurityExtractTemplate.pdf | 1.需求索引:RS_SECXT_* 2. 收集了Security Extract模板的需求,主要目的是将安全事件及其属性定义为车辆电子设备入侵检测系统的输入。使用Security Extract关键方面: • 在开发过程中从多个来源收集安全事件定义 • 输入车辆ECU和机器的IdsM实例的安全事件配置 • SIEM系统的输入,用于解释与安全事件相关的二进制数据 | |
AUTOSAR_RS_StandardizationTemplate.pdf | 1.UC用例索引,前缀: ”UC_STDT_*” –> ” RS_STDT_*” 2.需求索引,前缀: ”RS_BRF_*” –> ” RS_STDT_*” 3.介绍了标准化模板的续期。该标准模板旨在支持AUTOSAR交付标准化模型元素。AUTOSAR 4.0已经规定了标准化的蓝图方法。标准化模板继续并改进了这种方法 | |
AUTOSAR_RS_TimingExtensions.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ” RS_TIMEX_*” 2.定义了Timing扩展规范的需求,Timing扩展规范应支持AUTOSAR平台,即经典和自适应平台 | |
AUTOSAR_TPS_ SecurityExtractTemplate.pdf | 1.需求索引,前缀: ”RS_SECXT_*” –> ” TPS_SECXT_*” 2. 入侵检测系统管理器(IdsM)是一个基本软件模块(CP)或一个平台服务(AP),用于收集和集中聚合可能由对车辆软件、通信或电子系统的恶意攻击引起的安全事件。 3.SecurityExtract模板(SECXT)是入侵检测系统(IDS)的一部分, SECXT规定了系统级车辆的安全事件及其属性。SECXT被形式化为ARXML文件,适用于AP和CP,方式类似于Diagnostic Extract file | |
AUTOSAR_TPS_ AbstractPlatformSpecification.pdf | 1.需求索引:TPS_APSD_* 2. 文档包含AUTOSAR抽象平台(XP)设计规范。由于规范是AP和CP的抽象,因此作为FO的一部分发布。 3. 深入探讨抽象平台的设计方面 | |
AUTOSAR_TPS_ StandardizationTemplate.pdf | 1.需求索引,前缀: ”RS_STDT_*” –> ”TPS_STDT_*” 2. AUTOSAR为其标准化工作定义了四个级别的要求: • AUTOSAR项目目标 • AUTOSAR主要要求 • AUTOSAR要求规范(RS、SRS、ATR) • AUTOSAR规范(SWS、TPS、AI、TR、MOD、ATS、EXP等) 3.详细介绍标准化的蓝图: • The Principles of Blueprints • Blueprintables defined in AUTOSAR Meta Model | |
AUTOSAR_MOD_GeneralDefinitions.zip | 用于AUTOSAR定义的标准化M1模型: • AUTOSAR_MOD_GeneralDefinition_EnumerationTables.arxml • AUTOSAR_MOD_GeneralDefinition_LifeCycle.arxml • AUTOSAR_MOD_GeneralDefinition_ReferenceBase.arxml • AUTOSAR_MOD_GeneralDefinition_SecurityEvents.arxml | |
AUTOSAR_TR_XMLSchemaSupplement.zip | AUTOSAR XML模式的补充材料,包含以下文件: • AUTOSAR_00049_COMPACT.xsd • AUTOSAR_00049_STRICT.xsd • AUTOSAR_00049_STRICT_COMPACT.xsd • AUTOSAR_00049.css • xml.xsd格式 | |
AUTOSAR_TPS_ XMLSchemaProductionRules.pdf | 1.需求索引:ATI* 2. AUTOSAR元模型描述了可用于描述AUTOSAR系统的所有信息实体。选择XML作为AUTOSAR系统形式描述交换的基础。本文档描述了如何通过XML模式生成规则将AUTOSAR元模型映射到AUTOSAR XML模式 • XML Schema design principles • Configuration of XML schema production • XML Schema production rules | |
4、Diagnostics(1个) | AUTOSAR_RS_Diagnostics.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ”RS_Diag_*” 2.本文件规定了AUTOSAR诊断的系统需求。它包含AP和CP通用的基础需求,以及CP和AP专用的需求。 • 在CP中:应实现对法定OBD和增强型Di不可知论的处理。诊断基本软件元素集应尽可能由汽车软件模块的现有元素组成。 • 在AP中:应通知与自适应环境相关的一些限制:-仅支持以太网作为物理通信基础设施 |
5、Communication Management(4个) | AUTOSAR_RS_NetworkManagement.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ”RS_Nm_*” 2.描述了AUTOSAR网络管理的需求 |
AUTOSAR_RS_ FoundationDebugTraceProfile.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ”RS_ARFITO_*” 2. ARTI(“AUTOSAR运行时接口”)允许调试和跟踪AUTOSAR系统,支持不同的视图,如OS、BSW、RTE、模型、用户数据和用户定义。 | |
AUTOSAR_RS_E2E.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ”RS_E2E_*” 2. 本文件描述了E2E协议的需求。E2E协议定义了根据ISO 26262:2018需求提供端到端通信保护的抽象机制。 注:该文档包含经典平台文档中众所周知的需求,并尽可能为自适应平台带来了新的需求。 | |
AUTOSAR_RS_LogAndTrace.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ”RS_LT_*” 2. 日志和跟踪(LT)为应用程序和其他模块提供了通用的日志记录和跟踪功能。 | |
6、Protocols(12个) | AUTOSAR_PRS_E2EProtocol.pdf | 1.需求索引,前缀: ”RS_E2E_*” –> ”PRS_E2E_*”/”PRS_E2E_UC_*” 2. E2E通信保护的概念:安全相关数据交换应在运行时受到保护,以防通信链路上的故障影响 3. 通信保护机制的一个重要方面是其标准化和针对不同目的的灵活性。这可以通过一组E2E配置文件来解决,这些文件定义了保护机制、消息格式和一组配置参数的组合 4. E2E API,索引到”PRS_E2E_*”/”PRS_E2E_UC_*” |
AUTOSAR_PRS_LogAndTraceProtocol.pdf | 1.需求索引,前缀: ”RS_LT_*” –> ”PRS_Dlt_*” 2. 介绍Dlt协议的格式、消息序列和语义。该协议允许将诊断、日志和跟踪信息发送到通信总线上。因此,Dlt模块从应用程序或其他软件模块收集调试信息,向调试信息添加元数据,并将其发送到通信总线。 此外,Dlt协议允许根据严重性级别过滤调试信息,例如“致命”、“错误”或“信息” 3. API(Dlt Commands),索引到PRS_Dlt_* | |
AUTOSAR_RS_IPsecProtocol.pdf | 1.需求索引,前缀: ”RS_Main_*” –> ”RS_IPSEC_*” 2. IPsec是IP协议层3上的认证和加密的标准,本文件定义了AUTOSAR FO中IPsec的需求,其目的是确保AP内部以及CP和AP之间IPsec的互操作性 | |
AUTOSAR_RS_SOMEIPProtocol.pdf | 1. 需求索引,前缀: ”RS_Main_*” –> ”RS_SOMEIP_*” 2. 本文件规定(SOME/IP)协议的需求——一种自动/嵌入式协议,以及可用于请求/响应基于事件的通信、和底层序列化/有线格式 | |
AUTOSAR_RS_ SOMEIPServiceDiscoveryProtocol.pdf | 1. 需求索引,前缀: ”RS_Main_*” –> ”RS_SOMEIPSD_*” 2. 服务发现的主要任务是管理车内通信中功能实体(称为服务)的可用性(查找/提供),以及管理向网络发送事件消息的需求。这只允许向需要事件消息的接收者发送事件消息(发布/订阅)。 | |
AUTOSAR_RS_TimeSync.pdf | 1. 需求索引,前缀: ”RS_Main_*” –> ”RS_TS_*” 2. 本文件旨在定义时间同步协议的功能和非功能需求 | |
AUTOSAR_PRS_SOMEIPProtocol.pdf | 1. 需求索引,前缀: ”RS_SOMEIP_*” –> ”PRS_SOMEIP_*” 2. 本协议规范规定了AUTOSAR协议“IP上可扩展面向服务的中间件(SOME/IP)”的格式、消息序列和信号。SOME/IP是一种自动/嵌入式通信协议,支持远程过程调用、事件通知和底层序列化/有线格式。 3.SOME/IP通过网络提供面向服务的通信 • SOM/IP消息格式规范(序列化) • SOME/IP协议规范 | |
AUTOSAR_PRS_ SOMEIPServiceDiscoveryProtocol.pdf | 1. 需求索引,前缀: ”RS_SOMEIPSD_*” –> ”PRS_SOMEIPSD_*” 2. 本协议规范规定了SOME/IP服务发现协议(SOME/IP-SD)的格式、消息序列和语义。 3.SOM/IP-SD取决于SOM/IP。SOME/IP本身支持TCP和UDP通信,但SOME/IPSD限制仅在UDP上使用SOME/IP,SOME/IP-SD用于 • 查找服务实例。 • 检测服务实例是否正在运行。 • 实施发布/订阅处理。 | |
AUTOSAR_PRS_ IntrusionDetectionSystem.pdf | 1. 需求索引,前缀: ”RS_Ids_*” –> ”PRS_Ids_*” 2. 本协议需求规范定义了AUTOSAR协议IDS的格式、消息序列和语义。 3.IDS主要目的是将合格安全事件(QSEv)从入侵检测系统管理器(IdsM)实例传输到入侵检测系统报告器(IdsR)实例,文档重点介绍了IDS消息格式 | |
AUTOSAR_PRS_SecOcProtocol.pdf | 1. 需求索引,前缀: •”RS_Main_00510” –> ”PRS_SecOc_*” •”SRS_BSW_*” –> ”PRS_SecOc_* 2. 本文档中描述的Secure Onboard Communication(SecOC)模块提供了验证车辆架构内ECU之间基于PDU的通信的真实性和时效性所需的功能。SecOC模块旨在为PDU级别的关键数据提供资源高效且实用的认证机制 3. SecOC模块的规范允许不同的配置,用于MAC计算的加密算法和模式以及如何截断MAC和新鲜度值 | |
AUTOSAR_PRS_ NetworkManagementProtocol.pdf | 1. 需求索引,前缀: ”RS_Nm_*” –> ”PRS_Nm_*” 2. 本协议规范规定了AUTOSAR网络管理(NM)协议的格式、消息序列和语义。NM旨在与底层通信堆栈一起工作,独立于所使用的通信系统的物理层。 AUTOSAR网络管理是一个独立于硬件的协议 | |
AUTOSAR_PRS_TimeSyncProtocol.pdf | 1. 需求索引,前缀: ”RS_TS_*” –> ”PRS_TS_*” 2. 本协议规范规定了AUTOSAR时间同步协议的格式、消息序列和语义。时间同步协议处理以太网上的时间信息分配。以太网机制基于现有的PTP(精确时间协议)机制,其在诸如IEEE1588和IEEE802.1AS的标准中描述 3. 时间同步协议用于 • 同步时基和相应的以太网消息 • 测量以太网帧之间的时间差 | |
7、Health Monitoring(3个) | AUTOSAR_EXP_ SystemHealthMonitoring.pdf | 1.系统健康监测(SHM)引入了与平台无关的健康监测。目前,在平台级使用自适应平台(AP)中的PHM和经典平台(CP)中的WdgM执行健康监测和恢复操作的处理。 2.系统健康监视器组件可以实例化为主实例或客户端实例。SHM客户端负责将平台级健康数据传递给Master实例,而SHM Master负责确定健康指标 3. 实际需求可在[RS_HealthMonitoring]中找到,抽象规范可在[AWS_HealthMonitoring]中获得 |
AUTOSAR_RS_HealthMonitoring.pdf | 1. 需求索引,前缀: ”RS_Main_*” –> ”RS_HM_*” 2. 本文件规定了健康监测的需求,对于此版本,本文档仅适用于Adaptive Platform 3. 健康监测提供以下功能: • 对位于微处理器或虚拟机上的具有独立监管约束的多个单独监管实体的监管。 • 支持受监管实体的并行和并发执行以及多个实例化。 • 支持不同的操作模式,软件组件的行为取决于模式。 • 支持多个硬件看门狗。 • 支持多种错误处理机制 | |
AUTOSAR_ASWS_HealthMonitoring.pdf | 1. 需求索引,前缀: ”RS_HM_*” –> ”ASWS_HM_*” 2. 本文档规定了HM和SHM的功能。HM具有以下错误检测功能: • Alive Supervision-检查检查点是否以正确的频率发生 • Deadline Supervision-检查两个检查点之间的增量时间 • Logical Supervision-检查检查点的正确执行顺序 健康监测应通过AUTOSAR经典平台和AUTOSAR自适应平台实现。它也可以由其他平台实现 3. 健康监测API规范: 本章规定了其他文档部分中提到的健康监测API。它是以通用/抽象的方式定义的,因此可以在不同的平台上实现 | |
8、Crypto(2个) | AUTOSAR_TR_ ListOfKnownIssuesSecureHardware Extensions.pdf | 安全硬件扩展的已知问题列表 |
AUTOSAR_TR_ SecureHardwareExtensions.pdf | 1.安全硬件扩展(SHE)是对任何给定微控制器的片上扩展。它旨在将对密码密钥的控制从软件域移动到硬件域,从而保护这些密钥免受软件攻击。 2.当前设计的主要目标是 • 保护加密密钥免受软件攻击 • 提供真实的软件环境 • 让安全性仅取决于底层算法的强度和密钥的机密性 • 允许分布式密钥所有权 • 保持较高的灵活性和较低的成本 | |
9、Safety(1个) | AUTOSAR_RS_Safety.pdf | 1. 需求索引,前缀: ”RS_Main_*” –> ”RS_SAF_*” 2. 本文件规定了AUTOSAR平台,特别是AUTOSAR自适应平台的安全要求。本文件阐述了RS_Main中的高级安全要求 3. 具体内容: • 4.1中AUTOSAR的顶级安全要求(安全目标)。 • 4.2中的功能安全要求源自这些安全目标。 • 4.3子章包含从功能安全要求派生的技术安全要求 1)Functional Cluster: Platform Health Management (PHM) 2)Functional Cluster: Execution Management (EM) 3)Functional Cluster: State Management (SM) 4)Operating System (OS) 5)Functional Cluster: Persistency (PER) 6)Functional Cluster: Communication Management (CM) 7)Functional Cluster: Update and Configuration Management (UCM) |
10、Security(1个) | AUTOSAR_RS_ IntrusionDetectionSystem.pdf | 1.需求索引,前缀: ”RS_BRF_02038” –> ” RS_Ids_*” 2.概述入侵检测系统(IDS)需求,具体元素: • 安全传感器 • 入侵检测系统管理器(IdsM) • 安全事件存储器(Sem) • 入侵检测系统报告器(IdsR) 3.测试用例UC(1-9)驱动了车载IDS的需求 |
11、System Services(1个) | AUTOSAR_TR_TimingAnalysis.pdf | 1.本文件介绍了AUTOSAR开发过程中时序分析和设计的推荐方法和实践 2. AUTOSAR时序分析方法分为以下部分: •时间要求和级别的分解,功能级别的时间分析 • 功能层面的时序分析 • 分布式功能的端到端时序分析 • 网络层面的时序分析 • ECU级别的时序分析 • 时序特性和时序分析方法 3. 为了展示时序分析方法的建议用法,文档中包含了许多真实的用例。使用与章节相同的结构将用例划分为多个类别: • 功能层面的时序分析(第4章) • 分布式功能的端到端定时分析(ECU和网络级之间的接口)(第5章) • 网络层面的时序分析(第6章) • ECU级别的定时分析(第7章) |
未完继续:学习记录:AUTOSAR R20-11的阅读记录(二)【AP】