汽车电子软件AUTOSAR规范构架解决方案的文档学习资料18个合集: AUTOSAR.pdf AUTOSAROS规范(一部分).pdf AUTOSAR_SWS_CANDriver.pdf AUTOSAR分层架构.pdf AutoSAR技术概述.pdf AUTOSAR架构简述.pdf AutoSAR标准与体系.pdf AUTOSAR组织3.1培训.pdf AUTOSAR解决方案.pdf AUTOSAR详细介绍.pdf AUTOSAR软件组件介绍.pdf ISO15765-3车载诊断标准-详细中文版.pdf 基于AUTOSAR架构的通信系统的研究.pdf 基于Autosar的整车电子电气架构设计方法.pdf 开发AUTOSAR兼容的嵌入式软件_mathworks.pdf 汽车电子电气架构(EEA)与AUTOSAR.pdf 汽车电子软件的趋势.pdf

AUTOSAR 一组用于处理 XML文件的Python模块。 允许个人和团队使用Python代码逐步开发和维护AUTOSAR SWC模型。 执行Python脚本可以快速重新生成相同的ARXML文件（无需真正在版本控制中存储生成的ARXML文件）。 建议您使用商业化的AUTOSAR工具链将生成的SWC集成到ECU中。 AUTOSAR版本支持 AUTOSAR 3.0 AUTOSAR 4.2 目的是将来增加对AUTOSAR 4.3和4.4的支持。 （时间计划是未知的，因为我在业余时间从事大部分工作。） 先决条件 文献资料 文档发布。 最新发布 最新版本是 。 当前路线图 v0.4.0 维护跟踪（如果未发现问题，请重新标记v0.3.10） v0.5.0 完全重写RTE合同阶段生成器（升级到AUTOSAR4） 同时将autosar-demo项目升级到AUTOSAR4

NXP AUTOSAR_Project-master软件源码，汽车UDS， AUTOSAR例程源码

本PDF包括整车电子电气发展趋势，AUTOSAR的控制开发流程，后面对应了开发的实际案例，希望对想了解基于功能安全标准和AUTOSAR开发的人有用。

SOME/IP传输协议的SD部分协议规范，由AUTOSAR发布的标准文档，同时还有SoAD部分的说明

基于AUTOSAR的电动汽车驱动电机ECU控制软件研究与设计，黄智宇，熊张良，本文以永磁同步电机为控制对象，研究与设计基于AUTOSAR（汽车开放系统架构标准）的电机ECU的控制软件。主要完成了对控制软件开发中��

1. Autosar SWC 1.1 组件 1.2 接口/端口 1.3 函数、变量 2. Autosar Arxml配置 2.1 接口 2.2 组件 2.3 函数 2.4 调用关系 3. 基于Autosar MBD 3.1 工具要求及开发流程 3.2 arxml的导入、更新 3.3 建模与测试 3.4 代码生成

最新AutoSAR标准资料21-11

AUTOSAR OS描述文档

这里的NM主要是针对Can协议的网路管理。 AUTOSAR CanNM的核心思想主要归纳为以下两条： 1.  如果节点需要保持通信，则节点需要周期的发送NMPDUs，否则停止发送NMPDUs 2.     如果总线上的所有节点不需要使用总线，那么总线上过了一段时间没有NMPDUs时，则会进入Bus-Sleep Mode。   工作模式和状态   CanNm一共有三个工作模式 1.  Network Mode 2.  PrepareBus-Sleep Mode 3.  Bus-Sleep Mode 模式的改变应该通过回调函数通知上层。 下面单独说每种模式   （1）Network Mode Network Mode又包括三个内部状态 1. Repeat Message State 2. Normal Operation State 3. Ready Sleep State ①Repeat Message State 这个模式被用来确保从Bus-Sleep or Prepare Bus-Sleep到Network Mode的节点被总线上面其他节点发现。这个状态可以用来检测总线上的节点。 当进入Repeat Message State时，节点应该开始传送NMPDUs。 在Repeat Message State时，当NM-Timeout Timer溢出，CanNm模块应该重载Timer。 CanNm模块应该在Repeat Message State 下保持一段时间，这段时间可以通过CANNM_REPEAT_MESSAGE_TIME来进行配置。 当离开Repeat Message State的时候，如果节点需要通信，则进入Normal Operation State；如果节点不需要通信，则进入Ready Sleep State。并且清空Repeat Message Bit。   ②Normal Operation State 这个状态可以保持总线处于唤醒状态。从Ready sleep state进入这个状态的时候应该发送NMPDUs。 在Normal Operation State当NM-Timeout Timer溢出，CanNm模块应该重载Timer。 如果节点不需要使用通信，则网络应该被释放，节点应该进入Ready Sleep State。 如果节点接收到Repeat Message Request Bit，则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State，则该节点进入Repeat Message State并且设置Repeat Message Request Bit。   ③ReadySleep State 这个状态是为了如果本节点已经准备释放总线，而其他节点还需要使用总线的时候，在这个状态下等待其他总线上的节点进入Perpere Bus-Sleep Mode。进入这个状态之后，CanNm模块应该停止NMPDUs的传送。 如果NM-Timeout Timer溢出，节点将会进入Prepare Bus-Sleep Mode。 如果该节点需要使用总线，则节点进入Nomal Operation State。 如果节点接收到Repeat Message Request Bit，则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State，则该节点进入Repeat Message State并且设置Repeat Message Request Bit。 （2）PrepareBus-Sleep Mode   这个状态是为了等待总线上的所有节点能够在进入Bus-Sleep Mode之前，有时间停止节点的active状态如清空队列中为发送的报文。在Prepare Bus –Sleep Mode下，所有节点都静默下来。 当节点进入PrepareBus Mode时，应该通知上层应用。通过配置CANNM_WAIT_BUS_SLEEP_TIME参数，可以改变节点在PrepareBus-Sleep Mode停留的时间，在这段时间之后节点将会进入其他状态。 在Prepare Bus-Sleep Mode下面接收到NMPDU或者被上层应用请求通信时，节点将进入Network Mode中的Normal operation State。   （3）Bus-SleepMode   Bus-Sleep Mode的目的是当没有消息被传送的时候可以减少能量的消耗。在Bus-Sleep Mode下面，节点可以被唤醒（如本地唤醒源和CAN线唤醒源）。CANNM_TIMEOUT_TIME+CANNM_WAIT_BUS_SLEEP_TIME两个参数在整个总线上面的节点都应该时一样的配置，保证了总线上的节点能够统一的进行休眠。 当进入Bus-Sleep Mode时候，应该通知上层应用。 在Bus-Sleep Mode下，如果成功接收到NMPDU，CAN NM模块应该调用Nm_NetworkStartIndication。 如果CanNm_PassiveStartUp被调用，则CAN NM模块进入Network Mode 中的Repeat Message State。 ———————————————— 版权声明：本文为CSDN博主「cococenstar」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/cococenstar/article/details/84096689