StarFlex

General NRC behavior with subfunctionSID Level NRC FlowSub-function Level NRC FlowImportant CommentServer Response behavior 是针对 Server Level 的 CheckServer Response behavior with sub_function 是针对 sub-function Level 的 Check比如$28 03 01 在28 S

General由于Network Management 涉及的内容比较多，我分为多个Blog来写，细节如下CAN Network Management 介绍：参见AUTOSAR CAN Network Management Introduction Can Partial Network配置：参见AUTOSAR Partial Network Configuration Can Wakeup 的唤醒方式配置：参见AUTOSAR Network Wakeup(Can) Configuration

针对NVM Block 分为3种类型NATIVE/DATASET/REDUNDANT,本文将以这三种为例子进行介绍NVM/FEE的介绍，对于AUTOSAR NVM的介绍还请参考AUTOSAR NVM Introduction 一文，本文还是以介绍NVM/FEE 模块的配置为主。　还是那句话配置内容是基于AUTOSAR 标准，不受限于任何工具NOTE:由于不同芯片对应FLS都不尽相同，因此本文不会介绍FLS的内容StructureNVM CommonNVM Block Configurat

General 本文主要介绍如何配置LIN Stack , 对于LIN Stack的功能介绍还请参见AUTOSAR LIN Introduction本文配置内容以VECTOR 工具为基础，不过对于其他工具也是一样的配置方法。很多朋友可能有疑问认为很多工具都支持自动导入LIN LDF 文件，所有配置都可以自动生成，为什么还需要了解细节和手动配置这部分内容。我是这么理解这个问题的:理解这些属性的原理和配置底层逻辑，可以使你摆脱工具的限制，避免出现换了工具就不会了这种情况 目前AUTOS

对于IPDUM ， AUTOSAR 提供2种实现方式， 一种是 I-PDU MultiplexingMultiple PDU to Container Mapping ,本文主要介绍 Multiple PDU to Container Mapping 的配置方法，对于IPDUM的功能请参考我的另外一篇Blog – AUTOSAR IPDUM IntroductionData FlowCommunication Matrix 我们假设我们由如下Multiple PDU, 只简单列出来有关系

本文只介绍AUTOSAR DEM配置，目的在于知道DEM快速开发，对于AUTOSAR DEM 功能请参见AUTOSAR DEM Introduction 一文Workflow Step Action Refer to Section 1 定义DEM General Dem General 2 定义Freeze Frame

本文主要介绍AUTOSAR DCM的配置，对于ISO14229 以及Customer Diagnosis的作用不是本文重点Dcm Configuration Workflow Step Action Refer to Section. 1 定义$27 ,$10 27 Service 10 Service 2 定义SID/Sub

General Introduction在AUTOSAR CAN Wakeup Analysis 一文中已经介绍过 , 这里就做简单的说明。 本文还是以介绍配置为主对于在AUTOSAR SPEC 中规定对于Network Wakeup 功能，主要可以通过2种方式进行处理1.Controller (CAN)这种唤醒方式需要CAN Controller 支持相应的功能， 绝大部分的MCU 都支持，可以简单的理解这种唤醒方式需要先唤醒在校验。优点： 不需要支持PNC的transceiver ，

General Introduction对于RH850 来说最多支持16 组Memory 分区， 这些Memory 分区可以是RAM/ROM/D-FALSH/Stack(RAM)/Register(RAM), 我们可以针对memory分区设置访问其所需要的权限，只有Memory 访问者具备相应的权限才可以合法访问memory ，否则会触发MPU Error进入到OS Protection Hook一般来说对于VECTOR 工具链中是提供UI 界面进行配置， 本文主要将从芯片的角度介绍RH850 ..

General Introduction可以将ECU 通信网络分成很多个子网络，每个子网路都有自己的PN INFO, 通过BSWM 监控收到的PN INFO 进而控制对应的PDU Groups是否开启其中PN Info的位置可以通过CanNmPnInfoOffset and CanNmPnInfoLength 设置另外可以通过设置PN Filter Mask 对于收到的PN INFO 进行过滤，通过过滤后的PN INFO来决定是否有对应的PDU Groups需要开启由于Par..

本文主要用于介绍如果使用Davinci Developer 创建SWC/CDD 以及响应的功能，对于RTE的基础知识并不会结束，比如使用QUEUE Port 和NON QUEUE Port的区别对于RTE 功能，可以参考我的另外一篇文章AUTOSAR RTE IntroductionScenarioRefer to Section: 为可参见的后面的章节Application Data Transmission 这里指定的是两个SWC/CDD的通过Application Port 进..

根据AUTOSAR 架构体系， Lower Layer通过PDUR 传递PDU给Upper Layer 是可以选择具体的Upper Layer Module ，如DCM,COM 或者选择CDD 并且由APP 自行实现这个CDD为什么要使用AUTOSAR CDD? 不使用原生的AUTOSAR BSW 而使用需要自己实现的AUTOSAR CDD一定是有原因的，导致原生AUTOSAR BSW 不能被使用，比如功能安全的限制， AUTOSAR BSW 自身的限制等下面我结合经历过真实例子，详..

General本文主要介绍基于VECTOR MICROSAR 介绍如何完成 CAN 通信的诊断报文的配置Diagnosis Dataflow假设有如下诊断报文DIAG_REQUEST_PHYSICAL DIAG_REQUEST_FUNCTIONAL DIAG_RESPONSE_PHYSICAL那么哪些AUTOSAR Component需要配置呢EcuCDIAG_RESPONSE_PHYSICAL需要创建 3 个EcuCECUC_RESPONSE_PHYS

General StructureKey Management对于Key的注入在AUTOSAR Crypto Stack 主要通过以下API 进行STEP 1: Csm_KeyElementSet(KeyId,KeyElementId,keyPtr,keyLength)STEP 2: Csm_KeySetValid(KeyId)有的Key注入完成后可能有返回值，需要通过如下API 获取STEP3: Csm_KeyElementGet(KeyId,KeyElementId,ke..

Why use it 满足功能安全ISO26262 -6 ：程序流监控，执行时间监控要求GeneralWorkflow评估SE中的AS/DS/LS à 决定LOCAL STATUS à决定GLOBAL STATUSàERROR HandlingStructureSupervised Entity 被监管的实体， 由多个Checkpoint所构成，SE 可以理解为一个收到监管，监控的功能，假设我们有个ASILD 的功能是计算数据并发送数据。那么这个功能就是一个SE ，我

本文着重介绍Memory Stack中的重要API， 以及一些时序调度问题我们知道Memory Stack 一共由三个MainFunction用于执行RAM 于D-FLASH的交互，如何设计 MainFunction调度时序可以达到最优解，细节如下Init Phase Sequence触发时机：INIT TASKFls_Init -->有的可能放在ECUM InitList1 用于绕开MPU 监管 NvM_Init Fee_InitNormal Phase Sequence因

为什么使用MPU通常ECU 内部集成了很多模块，这些模块可能来自第三方(Vector ,EB, 其他公司)或者由自己开发完成， 从功能安全的角度来说，这些模块（代码）都会有对应的安全等级（QM,ASILA~D）, 因为不同的安全等级评估标准（设计，实现，测试）是不一样的，因此如何保证基于不同标准实现的模块可以安全的共存在ECU 内部是功能安全架构需要考虑的内容之一Memory Protection 就是其中一项重要的评估，设计内容，对于不同ASIL 等级的模块，需要保证其运行时所对应的Memor

一直以来想写一篇关于基于AUTOSAR 架构 Runtime 分析以及优化的文章，但是感觉方法很多可是又过于具体和依赖实际软件架构，所以很难抽离出一套万能的方案但是，很多内容是可以复用的，鉴于此，本文只介绍Runtime优化的思路，并不会列举出具体的方案，再写本文时，本想画几张图，避免过于理论，但是实在是太难用图形合理表达所有的内容，所以只能全部是文字了Runtime 分析指标平均负载在任意时间段内，CPU Load 最好低于90%,意味着CPU需要有10%的空闲时间单点负载

General针对E2E 数据校验目前存在2种方式，如下E2E Lib + E2E PW: 采用这种方式的校验E2E_Check接口将返回E2E PXX Status（例子可参见E2E PXX Status Estimation） ，App 需要自行根据返回的E2E PXX Status来判断采取什么Action , 对于这种组合在AUTOSAR 4.3 之后就不再采用了E2E Lib +E2EXf+ E2ESM: 对于AUTOSAR 4.3 之后的版本都将采用这种组合，和前面提到的那种方式相比

General本文主要介绍AUTOSAR Component Init Sequence ,以及各个Main Function调用的时序和推荐周期。 尽量指出每个main Function 所推荐的周期的理由简单来说，通过此种方案设计，可以减少因调度顺序所引入的tolerance, 或者因Polling time设置过短导致Runtime 的浪费NOTE: 最合理的方案一定是结合需求，真实RT 平衡后的方案，比如多个TASK的引入，这里列出的只作为参考Init Sequence Anal