文件标题 |
BSW结构和RTE的特征规范 |
文件拥有者 |
AUTOSAR |
文件责任 |
AUTOSAR |
文件识别码 |
294 |
文件类别 |
附属的 |
文件版本 |
1.1.0 |
文件状态 |
最终版本 |
发布的部分 |
4.0 |
修订版 |
3 |
文件变更历史 |
|||
日期 |
版本 |
变更者 |
变更描述 |
2011年12月20日 |
1.1.0 |
AUTOSAR管理 |
纠正术语”模块短名称” 的错误使用 |
2009年11月30日 |
1.0.0 |
AUTOSAR管理 |
第一次发布 |
免责声明
由AUTOSAR发布的此规范及其中的材料仅被用于提供信息。AUTOSAR以及共同完成此规范的公司对此规范的使用所造成的后果不负有任何责任。
此规范中包含的材料受到版权和其它类型的智慧财产权的保护。如果需要对此规范中包含的材料进行商业开发,那么它需要获得此类智慧财产权的认证。
在没有做出任何修改的情况下,此规范可以以任何形式或者任何方式被使用或者再造,但是只能用于提供信息。
对于任何其它目的,在没有获得出版者的书面允许的情况下,此规范的任何部分都不能以任何形式或者任何方式被使用或者再造。
AUTOSAR规范是专门为汽车应用开发的。它们不能被用于非汽车应用,也未进行过测试。
单词AUTOSAR以及AUTOSAR标志是注册过的商标。
对用户的建议
AUTOSAR规范可以包含典型的项目(典型的参考模型,”使用案例”,和/或对典型技术解决方案的参考,设备,工序或者软件的参考)。
此规范中包含的任何典型项目仅用于解释的目的,它们自身并不是AUTOSAR标准的一部分。如果它们出现在此类规范中,或者出现在实现典型项目的任何AUTOSAR产品一致性文件中,那并不意味着它的智慧财产权与AUTOSAR标准的智慧财产权相同。
目录
3.1.1[BRF00020]将现有的BSW时序安排集成到RTE中
3.1.2[BRF00260]在运行时,动态地支持有时序安排的BSW模块
3.1.3 [BRF00261]允许集成者完善BSW模块的启动/关闭行为
3.2 RTE API增强概念
3.2.1 [BRF00023]其它RTE状态’从未接收到’
3.2.2[BRF00024]其它RTE通过返回值读取API
3.2.3[BRF00092]接收队列行为的扩展
3.2.4[BRF00259]用Rte _ IFeedback扩展RTE
3.3 触发的事件概念
3.3.1 [BRF00031]触发的事件
3.4 丰富测量和校准,允许每个实例存储器作为可测量的存储器
3.4.1 [BRF00076]丰富测量和校准,允许每个实例存储器作为可测量的存储器
3.5 避免RTE类型标题文件概念中出现复制的类型定义
3.5.1 [BRF00078]避免RTE类标题文件中出现复制的类型定义
3.6 端口概念的完整性和缩放比例
3.6.1 [BRF00101]在端口接口处的自我缩放信号
3.6.2 [BRF00097]内部ECU通信的内部数据类型和网络数据类型之间的转换
3.6.3 [BRF00074]在运行时间期间的数据语义范围检查
3.7 含蓄的通信提升概念
3.7.1 [BRF00079]由于资源需要,对含蓄的通信语义进行优化
3.8 A2L生成支持概念
3.8.1 [BRF00021]A2L 生成支持
3.9 DEM行为概念
3.9.1 [BRF00230]DEM 行为要求
3.9.2[BRF00231]与新的冻结帧数据有关的通知的转发
3.9.3[BRF00232]事件处理的控制
3.9.4[BRF00233]存储器溢出显示
3.10 支持大的数据类型概念
3.10.1[BRF00004]支持可变长度的数据类型
3.10.2[BRF00005]支持数据类型尺寸>8的字节(信号尺寸)
3.10.3[BRF00290]支持动态尺寸的数组类型
3.11 VMM AMM 概念
3.11.1 [BRF00045]支持禁用’正常’通信
3.11.2 [BRF00060]控制运行时间可变的LIN时序表
3.11.3[BRF00073]端口组
3.11.4[BRF00103]控制模式相关的IPDU组
3.11.5[BRF00104]模式相关的复位初始值
3.11.6[BRF00189]允许SWCs请求专门的模式
3.11.7[BRF00190]模式请求的可配置的BSW内部评估
3.11.8[BRF00191]模式信息的内部传播
3.12 固定数据的交换概念
3.12.1 [BRF00105]系统参数
3.12.2[BRF00157]用于RPorts的固定值
3.13 变型处理概念
3.13.1[BRF00029]VFB级别的变型处理
3.13.2[BRF00155]支持一个软件组件的不同接口
3.13.3[BRF00167]用于设置变型的宏值
3.14 总线监控问题概念
3.14.1[BRF00087]用于询问FlexRay速率和偏移校正的API
3.14.2[BRF00093]检测丢失的FlexRay启动帧
3.14.3 [BRF00264]将FlexRay收发器错误报告给诊断
3.14.4[BRF00265]报告应用的FlexRay时钟纠正项
3.14.5[BRF00266]报告集合的FlexRay通道状态错误
3.14.6[BRF00267]报告FlexRay状态数据,用于同步帧的数目
3.14.7[BRF00299]报告FlexRay状态数据,用于IDs清单
3.15 支持SAE J1939协议特征概念
3.15.1[BRF00168]支持SAE J1939协议特征
3.16 LIN 2.1标准概念
3.16.1[BRF00184]在LIN2.1规范中调整LIN堆栈
3.17 FlexRay ISO TP概念
3.17.1[BRF00192]支持FlexRay信息IDs
3.17.2[BRF00252]ISO 10681-2符合FlexRay通信
3.18 LIN收发器驱动器
3.18.1 [BRF00228]指定LIN收发器
3.19 FlexRay协议规范问题概念
3.19.1[BRF00268]支持FlexRay单插槽模式
3.19.2[BRF00273]支持双FlexRay通道
3.20 FlexRay规范3.0概念
3.20.1[BRF00272]支持激活的FlexRay Stars
3.20.2[BRF00277]支持FlexRay规范3.0
3.21 TCP/IP CommStack扩展概念
3.21.1 [BRF00283]允许BSW通过TCP/IP进行通信
3.21.2[BRF00284]允许应用通过TCP/IP进行通信
3.21.3[BRF00285]允许PDU路由器通过TCP/IP进行通信
3.21.4[BRF00286]支持以太网作为一个附加的通信媒介
3.21.5[BRF00287]诊断通信通过IP被实现
3.22 时间决定论概念
3.22.1[BRF00120]在一个集群内提供一个同步的时间基准
3.22.2[BRF00121]运行时间保护和监控
3.22.3[BRF00122]支持定时限制
3.22.4[BRF00123]对外部事件的响应
3.22.5[BRF00125]监控本地时间
3.22.6[BRF00126]服务,用于软件组件的同步
3.22.7[BRF00127]服务,用于访问同步的时间基准
3.22.8[BRF00278]使AUTOSAR OS与全球时间(来自定义明确的提供总线系统)
同步
3.23 XCP,用于AUTOSAR概念
3.23.1[BRF00279]R CC缓冲器的配置
3.23.2 [BRF00280]AUTOSAR BSW XCP模块
3.24 网络管理协调概念
3.24.1[BRF00256]网络管理协调器应该使任何一种AUTOSAR总线保持协调
3.24.2[BRF00271]网络协调器应该支持到FlexRay的网络管理网关
3.24.3[BRF00274]FlexRay网络管理定时窗口解除
3.25 软件组件概念的功能诊断
3.25.1[BRF00027]软件组件的功能诊断
3.25.2[BRF00229]软件组件的非集中式模块诊断配置
3.26 FlexRay网络可靠性概念
3.26.1[BRF00302]FlexRay发送完成确认
3.26.2[BRF00303]FlexRay发送暂停时间处理
3.26.3[BRF00304]FlexRay接收完成确认
3.26.4[BRF00305]FlexRay有效载荷长度检查
3.26.5[BRF00306]FlexRay硬件检查
3.26.6[BRF00307]FlexRay复位/再次初始化
3.27 TTCAN概念
3.27.1[BRF00312]将TTCAN引入到[认可的]AUTOSAR中
3.28 调试概念
3.28.1[BRF00152]BSW变型可以被外部调试器使用
3.28.2[BRF00083]ORTI可比较的XML模块描述
3.28.3[BRF00084]M2元模型的调试扩展
3.28.4[BRF00085]访问用于调试的PduR
3.29 DLT概念
3.29.1[BRF00224]允许监控DEM,RTE和COM,以改善诊断效果
3.29.2[BRF00294] 标准的逻辑&布线格式/协议
3.29.3[BRF00295] 用于逻辑&布线的DET布线接口
3.29.4[BRF00296]逻辑&布线需要的RTE/VFB布线接口
3.29.5[BRF00297]逻辑&布线需要的DEM布线接口
3.29.6[BRF00298]使用诊断服务的逻辑&布线调试接口
3.29.7[BRF00300]用于软件组件的标准接口/服务逻辑&布线
3.30 存储器相关的概念
3.30.1[BRF00022]修改NVRAM存储器访问概念
3.31 建立系统升级概念
3.31.1[BRF00057]存储器映射概念
3.3.1.2[BRF00077]软件组件的存储器映射
3.32 支持窗口化的看门狗概念
3.32.1[BRF00159]支持窗口化的看门狗
3.33 闹钟概念
3.33.1[BRF00196]闹钟
3.34 BSW结构概念中允许CDD
3.34.1[BRF00225]BSW结构中允许CDD
3.35 库的概念
3.35.1[BRF00165]集成HIS加密功能
3.35.2[BRF00311]标准的AUTOSAR库
3.36 引导加载器交互性概念
3.36.1[BRF00034]引导加载器交互性
3.36.2[BRF00262]DCM应该支持ECU复位服务
3.36.3[BRF00263]DCM内部应该支持跳转到闪存引导加载器
3.37 多核结构概念
3.37.1 [BRF00199]实时能力&可预测能力
3.37.2[BRF00200]无锁死互斥现象
3.37.3[BRF00204]多核系统,其中一个核作为智能外围设备
3.37.4[BRF00205]多核系统,每个核一个操作系统
3.37.5[BRF00206]多核系统,一个操作系统控制所有核
3.37.6[BRF00207]无锁死
3.37.7[BRF00208]无不受控制的阻塞
3.37.8[BRF00209]与一个核上的单核系统的服务兼容性
3.37.9[BRF00210]与横跨多个核的单核系统的高度服务兼容性
3.37.10 [BRF00211]到核的任务的静态设置
3.37.11[BRF00212]跨核任务的激活
3.37.12[BRF00214]跨核的资源
3.37.13[BRF00215]到核的中端的静态设置
3.37.14[BRF00216]在本地禁止/允许中端API呼叫工作
3.37.15[BRF00217]事件机制应该跨核工作
3.37.16[BRF00218]核的离线可配置能力
3.37.17[BRF00220]初始化和启动
3.37.18[BRF00221]核之间进行受控数据的交换
3.37.19[BRF00222]常见的配置
3.37.20[BRF00223]内核定时器同步
3.38 错误处理概念
3.38.1 [BRF00156]错误处理规范
3.38.2[BRF00193]标准错误清单
3.38.3[BRF00275]分区的错误处理能力
3.39 SRS核测试
3.39.1[BRF00185]测试模式
3.40 SRS闪存测试
3.40.1[BRF00186]测试结果处理
3.41 软件组件E2E 通信保护概念
3.41.1[BRF00114]软件组件端对端的通信保护
3.42 存储器分区概念
3.42.1[BRF00115]被分组到单独用户模式存储器分区中的软件组件
3.43 程序流程监控概念
3.43.1[BRF00131]逻辑程序流程监控
3.44 BSWM防卫行为概念
3.44.1[BRF00128] 保护BSW,使之不能在未授权的情况下被使用
3.44.2[BRF00129]数据保护
3.45 通信堆栈概念
3.45.1[BRF00110]通信保护
3.45.2[BRF00111]数据顺序控制
3.45.3[BRF00112]路由选择的完整性
3.45.4[BRF00113]通信看门狗
3.45.5[BRF00241]多个通信链路
3.45.6[BRF00242]网络通信监控
3.46 电子油门监控适应性概念
3.46.1[BRF00301]使一个AUTOSAR应用与电子油门监控概念相兼容的能力
3.46.2[BRF00248]对输入/输出数据以及输入/输出硬件进行测试和监控
3.46.3[BRF00251]访问SPI总线的优先权
3.46.4[BRF00243]通信保护,确保数据不被破坏和丢失
3.47 与配置有关的特征
3.47.1[BRF00042]将XML(而不是OIL)用于操作系统配置
1 文件的范围
当前,此文件描述了AUTOSAR基本软件(BSW)和RTE的所有新特征。
发行版4.0中的所有新特征都将被描述,发行版4.0扩展了BSW和RTE的发行版3.1
特征是根据”概念”(它集合了一个特殊目的的相关特征)被分类到一起的。
2.使用习惯
在要求中,下列的特殊语义应该被使用(根据因特网工程特别小组IETF的规定)。
在此文件中,关键字”MUST”,”MUST NOT”,”REQUIRED”,”SHALL”,”SHALL NOT”,”SHOULD”,”SHOULD NOT”,”RECOMMENDED”,”MAY”,以及”OPTIONAL”将被理解为:
3 要求规范
此章中给出了一个要求文件的结构。其结构与基本软件模块要求规范有很大的关系(SRS文件)。
3.1 AUTOSAR调度程序协调概念
3.1.1 [BRF00020]将现有的BSW时序安排整合到RTE中
标识: |
BRF00020 |
创办人: |
AUTOSAR PL |
日期: |
2007年03月05日 |
简述: |
将现有的BSW时序安排整合到RTE中 |
重要性: |
高 |
描述: |
调查和实现方式,使用RTE来处理应用软件和基本软件的时序安排。 |
基本原理: |
AUTOSAR的发布版2包括两个用于实现时序安排的模块,它们是基于AUTOSAR 操作系统提供的机制的。这些模块是RTE(用于SWC时序安排)和BSW时序安排模块(用于BSW时序安排)。
根据判断,通过将BSW时序安排集成到RTE中可以为此区域内提供更大的优化可能性,考虑到完整的ECU软件需要,它可以产生一个更优化的时序安排计划。这将导致BSW时序安排模块从BSW结构中被移除。 |
使用案例: |
调用BSW 服务NvM_Read()的应用软件。此调用会访问某些工作队列,用于调用工作。NvM主要功能也会访问工作队列,以便使用它。如果没有采取预防措施,这可能会导致对工作队列的并发访问,并产生不连续状态。如果两个软件都从相同的实体(RTE)被调用,此类有冲突的访问可以被检测并受到保护。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
因此,此任务应该精心制作RTE规范,以覆盖BSW时序安排(例如,任务映射,并发性保护,事件处理)。在此工作过程中,如果用于软件组件时序安排的现有解决方案得到改善,那么应该考虑实现这些改善措施。 移除BSW调度程序可以优化SWc和BSW之间的时序安排和数据连续性。(与软件组件中的执行区域相同) 另一方面,BSW的性能可能会受到印象(中断掩码时间,生成的粘合代码),然而现在它被写下来并被改善。 RTE可以支持本地中断允许/禁用(例如,CAN ISR ,Lin,等等) RTE也可以生成空的功能,以用于ECU集成者编码。 |
接收者: |
-- |
3.1.2 [BRF00260]在运行时,动态地支持时序安排BSW模块
标识: |
BRF00260 |
发起人: |
-- |
日期: |
2008年1月31日 |
简述: |
在运行时,动态地支持调度程序BSW模块 |
重要性: |
中等 |
描述: |
支持多BSW模式,不同的激活功能动态地允许或者禁止BSW模块的时序安排。 |
AUTOSAR BSW应该支持多个模式,不同的BSW功能可用于每一个模式。 |
|
基本原理: |
·BSW的所有功能可能并不总是被需要的。例如,在一个低电源模式下,ECU的CPU被一个较低的频率锁定,它并不需要所有的BSW功能。为了改善保持BSW功能的响应能力,需要一个基于模式的机制来定义激活的BSW功能。 |
之后,激活的BSW功能将被(用于当前模式的)BSW模块定义,而未被安排到当前模式中的BSW模块的功能将不可用。 |
|
使用案例: |
-远程信息处理ECU,周期地检查GPS位置和环境(例如,温度);如果有必要的话,与远程信息处理中央电脑(通过GPRS/UMTS)进行通信或者唤醒总线,以便与其它ECU进行通信。 |
-对于周期性检查来说,整个BSW功能(例如,总线通信)都不需要。 |
|
相关性: |
其它模式概念 -VMM/AMM -与模式有关的通信 -协调的AUTOSAR调度程序 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.1.3 [BRF00261]允许整合者优化BSW模块的启动/关闭行为
标识: |
BRF00261 |
发起人: |
AUTOSAR WP软件结构和操作系统 |
日期: |
2008年01月31日 |
简述: |
一个框架机制,它允许整合者根据其需要来优化BSW的启动/关闭行为。 |
重要性: |
中等 |
描述: |
R3.0启动/关闭程序定义了3个初始化模块(这些模块之间有固定的活动)。在R4.0中,随着BSW模块之间的功能相关性的增加,整合者更难确保BSW模块的启动/关闭程序的正确性和免受冲突性。此外,这些内部相关性可能会引入其它延迟(例如,一个BSW模块等待来自NVRAM的启动数据)。 因此,AUTOSAR应该支持整合者: -解决BSW模块之间的启动/关闭冲突 - 根据特定的需要来优化启动/关闭程序(例如,最小时间) 在启动和关闭过程中,一个基于BSW模式的框架机制可以被循环。 |
基本原理: |
AUTOSAR BSW的启动/关闭的速度和正确性很大程序上取决于整合者。期望AUTOSAR标准能够满足此任务。 |
使用案例: |
-将一个车身舒适ECU与许多软件组件及全面的BSW整合在一起时,几乎需要立即的启动。 |
相关性: |
其它模式概念
|
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
标识: |
BRF00023 |
发起人: |
AUTOSAR WP VFB和RTE |
日期: |
2007年06月21日 |
简述: |
其它RTE状态”从未接收到” |
重要性: |
中等 |
描述: |
另外添加一个选择性的RTE状态”从未接收到”。这是每一个数据元素的新的初始状态。在第一次接收时,此初始状态将被清除。 |
基本原理: |
此附加的选择性状态建立了可能性:从系统启动开始,一个数据元素是否已经被改变。 |
使用案例: |
得到这样的信息:从系统启动后的任何时候,参与其中的数据是否已经被接收到。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
还不清楚,它是否关注端到端的通信,或者发送器一侧与软件组件之间的通信。 |
|
-- |
接收者: |
-- |
3.2.2 [BRF00024]其它RTE读取使用返回值的API
标识: |
BRF00024 |
发起人: |
Continental |
日期: |
2007年05月03日 |
简述: |
其它RTE读取使用返回值的API |
重要性: |
低 |
描述: |
从有效性的观点来看,调查一个附加RTE读API(它将返回值作为结果,无rte_status)是否有任何优势。如果有,那么它应该被包含在规范中。 |
基本原理: |
当调用程序RTE_Read()对收到的信息的状态不感兴趣时,它可以更有效地使用一个API(它将结果作为返回值). |
使用案例: |
对RTE_Read的许多调用被期望用于应用软件组件。允许RTE生成有效的代码,它不需要特别的代码优化编译器。 |
相关性: |
必须调查当前的”嵌入式”编译器是否能够生成有效的代码,不管此值是被直接地返回(在此,作为建议的方法)还是状态结果被返回但是未被使用。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.2.3 [BRF00092]接收队列行为的扩展
标识: |
BRF00092 |
发起人: |
Daimler |
日期: |
2007年05月29日 |
简述: |
接收队列行为的扩展 |
重要性: |
低 |
描述: |
RTE的接收队列应该被改变,使之表现得像一个轮询允许接收器缓冲器一样(从最后一次轮询开始,它会显示一个接收行为)。 |
因此,如果出现一个溢流现象的话,接收缓冲器应能够覆写最老的信号。如果出现一个溢流现象的话,当前的行为会拒绝接收到的信号。 |
|
基本原理: |
到现在为止,只有在接收到一个信号之后才可能得到一个接收显示,而对于某些应用来说,轮询是更可行的。 |
因此,一个尺寸为1的接收缓冲器是适用的,如果再收到信号,它将覆写其内容。如果应用得到它轮询的信号,这表明是一个接收行为,如果是一个空的队列,这种情况将被显示。 |
|
使用案例: |
从最后一次轮询开始,如果此信号还没有被收到,软件组件将异步地(向FlexRay)轮询一个信号的值并得到信息。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
与RTE中的队列处理相似(如果队列尺寸为1的话) |
接收者: |
-- |
3.2.4 [BRF00259]用Rte_IFeedback扩展RTE API
标识: |
BRF00259 |
发起人: |
Daimler |
日期: |
2008年01月31日 |
简述: |
用Rte_IFeedback扩展RTE API |
重要性: |
中等 |
描述: |
当前的R3.0 RTE SWS只提供一个Rte_Feedback API来询问发送状态(用于明确的通信)。它也应该可用于含蓄的通信,在该通信中,可运行状态实体可以询问在前一次任务执行中提供的数据是否已经被发送。 |
基本原理: |
允许询问含蓄通信的发送状态。 |
使用案例: |
一个可运行实体应能够检查最后一次执行中提供的信息是否已经被发送。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.3 触发事件概念
3.3.1 [BRF00031]触发的事件
标识: |
BRF00031 |
发起人: |
Continental |
日期: |
2007年05月03日 |
简述: |
触发的事件 |
重要性: |
高 |
描述: |
SWS_RTE定义7种事件,但是它不支持周期性地发生却不基于定时的事件(例如,在传动系统应用中的曲柄轴事件)。 |
现有的定时事件似乎真的与基于时间的事件有关。事实上,定时事件有一个”周期的”适宜性。 |
|
这些周期性事件应该像定时事件一样触发一系列类别1的可运行状态,例如,触发一个相应的任务,然后可运行状态按照一个给定的顺序被执行。这些事件可以由BSW(确定的)或者SWC(即将被讨论)生成。 |
|
一个全球的周期性事件可以被定义。现有的定时事件是周期性事件的一个特例。 |
|
基本原理: |
可运行状态的同步和异步触发基于不定时发生的循环,用于时间关键的应用(例如,传动系统) |
使用案例: |
- 在一个燃烧引擎中,用于控制一个燃烧引擎的几个过程的角度同步处理必须与曲柄轴和凸轮轴位置同步。 - 过程的角度周期触发(例如,一个燃烧引擎的大气流计算)。 此过程的特性与定时事件是相同的,但是其频率是由引擎速度定义的。 - 在发生与曲柄轴有关的事件时,过程的不定时触发。 例如,在曲柄轴信号中,对一个齿合的第一次有效检测。 - 在最大引擎速度时,此类事件的发生概率非常高,而触发的可运行状态实体所需要的延迟和抖动非常低。据此,应该避免与ECU的通信系统发生耦合。 -总是期望在一个本地ECU中处理此类事件。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
与凸轮轴有关的事件:硬件可以提供一系列事件,可以表现得像一个数据收到的事件一样:用安排好顺序的可运行状态触发一个任务。 |
接收者: |
-- |
3.4 丰富测量和校准,允许per-Instance存储器作为可测量的概念
3.4.1[BRF00076]丰富测量和校准,允许per-Instance存储器作为可测量的存储器
标识: |
BRF00076 |
发起人: |
Continental |
日期: |
2007年06月14日 |
简述: |
丰富测量和校准,允许Per-instance存储器作为可测量的存储器 |
重要性: |
中等 |
描述: |
为per-instance存储器的测量提供RTE支持。 PIM是由RTE提供的,因此,此支持只能由RTE提供。 |
基本原理: |
通过测量工具向per-instance存储器提供访问权。 |
使用案例: |
PIM可以被用于存储中间的计算,并且在测量时,需要对PIM进行访问。 |
由于将PIM用作NVRam存储器的RAMBuffer ,PIM可以包含在功能的执行过程中被修改的数据(相对位置计数器的调整或者传感器退化)。 |
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.5 在RTE类型标题文件概念中避免出现复制的类型定义
3.5.1 [BRF00078]在RTE类型标题文件中避免出现复制的类型定义
标识: |
BRF00078 |
发起人: |
Continental |
日期: |
2007年06月14日 |
简述: |
避免在RTE类型标题文件中出现复制的类型定义 |
重要性: |
低 |
描述: |
如果RTE发生器的输入中包含了类型以及与之相同的名称,那么当前的RTE规范不适用。
|
基本原理: |
通过避免不必要的编译器警告可以达到较高的代码质量。 在C实现中,避免名称空间冲突。 |
使用案例: |
在单独的版本管理下,在完全定义的子封装中的系统描述的功能结构。 一个数据转换器组件的定义,重新计算从一个范围到另一个范围的数据(这些范围有相同的命名类型)。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.6 在端口处的完整性和缩放
3.6.1 [BRF00101]端口接口处的自我缩放信号
标识: |
BRF00101 |
发起者: |
Valeo |
日期: |
2007年06月25日 |
简述: |
自我缩放端口接口 |
重要性: |
中等 |
描述: |
允许端口连接到不兼容的接口:
因此,RTE应该允许信号的自动再次缩放。 RTE应该为发送器/服务器一方和接收器/客户一方的端口指定信号的缩放,以允许RTE中的自动再次缩放。 下列的信号属性应该被指定
由于RTE发生器必须创造适配器,所以接插件需要被塑造为VFB级别。不能完全靠RTE发生器执行此操作。 |
基本原理: |
避免写软件组件粘合,以接口由整合者/子系统设计者提供的两个不同软件组件转换代码(例如,使用一个计算方法)。因此,不需要对受影响的软件组件中的信号解析度进行再次计算。 |
使用案例: |
软件组件的整合 - RTE生成缩放变化(C cast),以接口不同的软件组件 -避免写软件组件粘合,以接口2个不同的软件组件 在诊断中,信号的解析度必须按照OBDII的ISO文件中的规定来提供(例如,引擎速度)。如果RTE可以按照正确的解析度提供这些信号,那么软件组件不需要执行再次计算。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
系统模板必须被修改 |
接收者: |
-- |
3.6.2[BRF00097]用于ECU间通信的内部数据类型和网络数据类型之间的转换
标识: |
BRF00097 |
发起人: |
AUTOSAR WP方法和配置 |
日期: |
2007年06月21日(FMC) |
简述: |
用于ECU间通信的内部数据类型和网络数据类型之间的转换 |
重要性: |
低 |
描述: |
能够为一个ECU中的发送器-接收器通信中所使用的数据元素的不同数据类型(高解析度)以及ECU间所使用的数据元素的不同数据类型(低解析度)指定并生成转换程序,以保存串行数据链接带宽和非生产性的开发工作。 为一个ECU中的软件组件之间的发送器-接收器通信中所使用的、有高解析度的数据元素(例如,real32,int32,int16)指定一个数据类型。 软件组件之间的ECU间发送器-接收器通信中所规定的、有较低解析度的另一个数据类型主要被用于保存数据链接带宽。 两个不同数据类型之间的关系可以用软件组件模板中定义的数据类型语义来描述。 例如,此关系可以是将两个软件组件连接到两个不同ECU的装配连接(也被定义到软件组件模板中)的通信规范中的一个属性。一个替代的方法是将接口类型定义中的”回落”数据类型用于ECU间的通信。按照这种方式,信息总是会出现,即使你选择将一个软件组件移动到相同的ECU中,这样通信变为ECU内通信。 转换程序(从高到低的解析度和从低到高的解析度)可以在RTE或者COM接口功能中被生成和使用。 |
基本原理: |
现在,你必须将相同的数据类型用于一个数据元素,不管数据元素是被用于一个ECU中的通信还是两个ECU之间的通信。这将限制你可以用于数据元素的解析度。 其中一项工作就是创造一个考虑到这些转换的特殊通信软件组件。这是一个非生产性的工作,你可以使用数据类型语义来描述软件组件模板中的高解析度数据类型和低解析度类型之间的关系。 不同解析度的数据类型之间的转换程序可以由RTE或者COM配置发生器生成。 |
使用案例: |
在一个ECU中,软件组件想要使用高解析度的数据类型用于计算,以得到一个小的ε(计算公差)。 如果/当数据元素通过串行通信总线被发送时,开发者指定哪一个数据类型将被使用。在接收另一个ECU上的软件组件时,数据元素的数据类型被转换成高解析度的数据类型。 按照这种方式,我们不需要将特殊的通信软件组件引入到处理必要转换的每一个ECU上。 使用案例是沃尔沃传动系统处的ECU中的一个LOT,并且对RTE或者COM的支持将会提升ECU软件开发的效率。 |
相关性: |
软件组件模板,RTE和/或COM配置发生器。现在,我们将一个特殊的通信组件用于数据类型之间的转换。 |
冲突: |
当数据在两个ECU之间(而不是在一个ECU中)被发送时,软件组件不能明确地发现数据类型解析度变低。这应该被标记到软件组成物图表中(软件组件模板的一部分)。对于连接两个不同ECU上的两个软件组件的装配连接来说,请务必参阅通信规范。 在一个ECU中被发送的数据的数据类型解析度总是与接口类型定义中选择的数据类型解析度相同。 |
支持材料: |
-- |
接收者: |
-- |
3.6.3 [BRF00074]在运行时过程中的数据语义范围检查
标识: |
BRF00074 |
发起人: |
Daimler |
日期: |
2007年06月11日 |
简述: |
在运行时过程中的数据语义范围检查 |
重要性: |
中等 |
描述: |
在RTE中提供功能,使之能检查S/R和C/S的数据元素值的范围。此检查应该是可以配置的。默认为OFF. |
基本原理: |
对于调试来说,需要检查软件组件是否正在发送数据,以提供指定范围内的数据。如果有偏差,它将引起一个开发错误。 |
使用案例: |
— 在开发阶段,检查发送数据的范围。禁止此特征用于生产代码。
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
发起人: |
-- |
3.7 不明确的通信提升概念
3.7.1 [BRF00079]由于资源需要,对不明确的通信语义进行优化
标识: |
BRF00079 |
发起人: |
Continental |
日期: |
2007年06月14日 |
简述: |
由于资源需要,对不明确的通信语义进行优化 |
重要性: |
高 |
描述: |
当有非先占式多任务的合作可运行状态放置策略可以被应用时,优化不明确的S/R通信的缓冲器使用情况。 当前,不明确通信的语义被局限于复制策略,在其中,每个数据至少需要1+(使用数据的任务优先权的数目)个缓冲器。 在非先占式多任务环境中,数据的复制可以被避免。 此外,应该使数据被接收或者发送的时间点具有更高的灵活性。 如果数据在第一次被消耗之前被收到或者在产生之后被发送,那么数据一致性也能被保证。因此,不需要对任务启动或者任务结束做硬性限制。 |
基本原理: |
优化不明确的通信,使之遵守受限制的资源以及汽车嵌入式系统的硬实时限制。 |
使用案例: |
可运行状态放置策略可以减少对用于S/R不明确通信的任务特定缓冲器的使用。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
RTE SWS(R2.1)从总体上描述了数据一致性机制。
根据RTE小组的决定被拒绝的材料() |
接收者: |
-- |
3.8 A2L 生成支持概念
3.8.1 [BRF00021]A2L生成支持
标识: |
BRF00021 |
发起人: |
AUTOSAR WP软件结构和操作系统 |
日期: |
2007年05月03日 |
简述: |
A2L 生成支持 |
重要性: |
高 |
描述: |
RTE发生器必须生成一个XML文件,以定义数据元素/Calprm/CalprmElementGroup与(由A2L发生器使用的)RTE变型之间的映射。 |
基本原理: |
支持A2L文件生成 |
使用案例: |
支持A2L文件生成 |
相关性: |
可能需要一个SWC-T更新/升级 |
冲突: |
-- |
支持材料: |
此XML文件是用于生成A2L文件的后续工具的一个输出 |
接收者: |
-- |
3.9 DEM行为概念
3.9.1 [BRF00230]DEM行为要求
标识: |
BRF00230 |
发起人: |
Daimler |
日期: |
2008年01月25日 |
简述: |
DEM行为要求 |
重要性: |
中 |
描述: |
协调DEM行为要求,以允许常见的故障管理器(DEM)实现 使要求变得恰当,使之用于 - DTCs的存储 - 状态处理和支持的状态 - 环境数据处理(事件日志及数据更新) - DTC优先化 - DTC自愈 - 覆写 - 等等 这些要求(以及必须被识别的其它要求)在所有的AUTOSAR规范中必须是常见的,使之有一个常见的和可测试的DEM-BSW. |
基本原理: |
现在,DEM主要规定了用于实现与一个故障管理器的行为有关的要求,这些要求可以在ISO 14229-1和ISO15031-5/SAEJ1979中被找到。 但是,当一个故障由一个软件组件显示时(例如,Dem_SetEventStatus),故障管理器的实际行为不会被定义。关于故障的存储以及相关的环境数据,每一个OEM有不同的要求,例如某些OEM要求存储故障第一次发生的日志和相同故障最近一次发生的日志,而其它OEM存储同一个故障每一次发生的日志。此行为会从简单DTC存储和DTC状态实现变化到环境数据存储和自愈,优先化和 覆写条件。 |
使用案例: |
只有当前面提到协调被达到时,一个DEM的常见实现(它可以被每一个AUTOSAR参与其中的OEM实现)才能被达到。到那时,AUTOSAR软件供应商只能提供一个DEM外壳,它必须由一个OEM特定的故障管理器(DEM)版本”填充”。 |
相关性: |
-- |
冲突: |
故障管理器通常被定义到OEM特定的要求规范中,如果某个存储概念被使用的话,它可以被视为一个具有竞争力的优势。 内容要求的协调需要参与其中的OEM同意常见的实现,并可能导致几个OEM不得不改变其内部规范。 |
支持材料: |
-- |
接收者: |
-- |
3.9.2 [BRF00231]通知的转发,关于新的冻结 帧数据
标识: |
BRF00231 |
发起人: |
BMW和Elektrobit |
日期: |
2008年01月18日 |
简述: |
通知的转发,关于新的冻结 帧数据 |
重要性: |
中等 |
描述: |
DEM应能够通知其它软件组件(或者BSW模块)关于新的冻结帧数据(例如,时间标识)。 如果为每一个事件配置此功能,它应该被执行于事件存储器中的此事件的一个新的冻结帧的每一个条目。 |
基本原理: |
在DEM SWS的当前版本中,不可能提供冻结帧数据(如时间标识)到另一个与DCM无关的软件组件/BSW模块。 此外,此功能提供一个简单的方式用于提供此数据到其它组件(每一次,只要当新的数据可用时),这样就不需要循环的轮询了。 |
使用案例: |
模块,如一个特殊的”诊断激活响应处理器”需要提供功能提供的信息。 |
相关性: |
无 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.9.3 [BRF00232]事件处理的控制
标识: |
BRF00232 |
发起人: |
BMW和Elektrobit |
日期: |
2008年01月18日 |
简述: |
事件处理的控制 |
重要性: |
高 |
描述: |
DEM模块应该为DTC检测提供锁定功能。此功能是可以根据事件来配置的。 |
基本原理: |
它应能禁用某些专门事件的间隙,例如OBD的参数错误。 |
使用案例: |
当ECU处于一个特殊的操作模式时(例如,装配模式,传输模式,或者闪存模式),某些专门事件不需要从事件处理器中被清理。 |
相关性: |
无 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.9.4 [BRF00233]存储器溢流显示
标识: |
BRF00233 |
发起人: |
BMW和Elekrobit |
日期: |
2008年01月18日 |
简述: |
存储器溢流显示 |
重要性: |
中等 |
描述: |
如果事件存储器被装满并且下一个发生的事件将被存储到此事件中,那么DEM模块应该向每一个事件存储器显示此信息。 |
基本原理: |
如果存储器的尺寸受到限制,那么有必要显示存储器溢流并提供一个替换策略。 |
使用案例: |
存储器溢流表明某些根本原因不是由事件存储器的内容来描述的。 |
相关性: |
无 |
冲突: |
-- |
支持材料: |
AUTOSAR中未规定替换策略。它应该通过一个API功能被显示。 此信息可以被连接到一个扩展的数据日志。 |
接收者: |
-- |
3.10 对大数据类型概念的支持
3.10.1[BRF00004]对可变长度数据类型的支持
标识: |
BRF00004 |
发起人: |
AUTOSAR PL |
日期: |
2007年04月26日 |
简述: |
对可变长度数据类型的支持 |
重要性: |
中等 |
描述: |
通常,它必须转移任意尺寸的数据(可以大于8个字节)。这必须被所有受影响的通信功能覆盖。 |
基本原理: |
不可以对固定长度的串进行处理,因为许多ECU资源都是通过此方式被分配的。 如果一个固定长度的空间被保留却未被使用,那么它将浪费内存和带宽。 如果交替地使用几个接口和信号来为不同的长度空间服务,那么它将使APIs复杂化,并且会浪费配置自由。 |
使用案例: |
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
其它信息必须被转移。这既可以是一条终止信息(如0x00终止C串),也可以是一条专门的长度信息。 RTE,COM和PDUR将会收到影响。 如果转移应该由CAN或者LIN来完成,必须使用一个机制来转移分散的应用数据。分散和重组必须在某个地方被处理。 CAN和LIN将帧的长度限制为8个字节。 当前的传输协议定义(能够转移的最大字节数)仅被用于诊断的目的。 |
接收者: |
-- |
3.10.2 [BRF00005]支持数据类型尺寸>8个字节(信号尺寸)
标识: |
BRF00005 |
发起人: |
AUTOSAR PL |
日期: |
2007年04月26日 |
简述: |
支持数据类型尺寸>8个字节(信号尺寸) |
重要性: |
高 |
描述: |
有时候,它必须转移一个尺寸大于8个字节的数据。如果复杂的数据类型包含连贯的数据元素,那么它的尺寸通常会大于8个字节。当前,软件组件负责处理连贯数据的大数据尺寸(或者概述的尺寸)。 此大数据类型的转移必须被所有受影响的通信功能覆盖。 |
基本原理: |
转移此大数据类型的方法比软件组件责任中的方法更好。一个中心的解决方法可以避免相同问题多个实现。 |
使用案例: |
一个软件组件提供大量的、占用空间超过64位的连贯数据。 |
相关性: |
-- |
冲突: |
CAN和LIN将帧的长度限制为8个字节。 当前的传输协议定义(能够转移大量的字节)仅用于诊断的目的。 |
支持材料: |
COM以及(也许)PDUR将会受到影响。 如果转移应该由CAN或者LIN来完成,必须使用一个机制来转移分散的应用数据。分散和重组必须在某个地方被处理。 |
接收者: |
-- |
3.10.3 [BRF00290]支持有动态尺寸的数组类型
标识: |
BRF00290 |
发起人: |
BMW |
日期: |
2008年01月30日 |
简述: |
数组类型应该提供尺寸信息。 |
重要性: |
中等 |
描述: |
发行版3.0中的AUTOSAR规范仅支持在规范时间(”最大元素数”)已知的一个最大尺寸的数组类型。使用数组的软件组件可能并不总是需要最大的数组尺寸。在被软件组件调用时,RTE不知道到底有多少数组元素被实际使用。这会导致物理传输媒介上的带宽的不必要的使用。为了避免这种不必要的通信,软件组件需要一个机制来通知RTE关于使用的数组元素数。 它足以为字节和字符数组提供此尺寸信息。 |
基本原理: |
在MM/T/HMI范围内,在某些情况下可能需要使用到动态长度的数据类型。MM/T/HMI通常能够确保动态数据被用于显示一个曲目清单或者一个POI清单(兴趣点)。 这些清单的尺寸可以从几个元素(CD曲目清单)变化到一个很大很复杂的数据类型(导航目的地数据,如[国家,城市,街道名称,房子编号])。总是发送最大数目的元素将会导致过多的使用不需要的带宽。 字节和字符数组包含带有动态信息的串,因此内容的长度变化是明显的。 |
使用案例: |
-- |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.11 VMM AMM概念
3.11.1[BRF00045]支持’正常’通信的禁用
标识: |
BRF00045 |
发起人: |
AUTOSAR PL |
日期: |
2007年05月03日 |
简述: |
支持’正常’通信的禁用 |
重要性: |
低 |
描述: |
根据ISO 14229-1(服务$28),它应能够禁用正常的通信,同时,使一系列预定的PDU保持激活,包括诊断通信。当前,DCM和ComM不支持此操作。 根据”AUTOSAR_SRS_Mode_Mgmt.SRS”中的BSW09083,ComM仅支持三种通信模式:
|
基本原理: |
在执行诊断任务过程中,它必须能够抑制正常的通信,以设置最大的带宽。 |
使用案例: |
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
在没有禁用诊断信息的情况下,GM应能禁用/允许”网络管理通信信息和正常通信信息”(根据ISO 14229-1中的附录B.1)。 |
接收者: |
-- |
3.11.2 [BRF00060] 控制运行时可变的LIN时序表
标识: |
BRF00060 |
发起人: |
BMW |
日期: |
2007年05月03日 |
简述: |
控制运行时可变的LIN时序表 |
重要性: |
高 |
描述: |
鉴于LIN接口已经提供了功能来执行时序表的变化,在运行时期间,如果有必要,有可能并且被允许,需要一个’授权’来开始时序表的变化。 |
基本原理: |
LIN接口不能决定是否以及何时去转换时序表。一个较高的’优先权’用于决定转换的需要。 |
使用案例: |
改变外部镜子的控制模式,从由开关控制的转变为由钥匙控制的 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.11.3 [BR00073]端口组
标识: |
BRF00073 |
发起人: |
Denso |
日期: |
2007年05月25日 |
简述: |
端口组 |
重要性: |
中等 |
描述: |
端口组应该表示VFB中的通信管理的用户概念(内部行为),并且应该被用于相同功能所需要的一个软件组件的端口组。这些端口在逻辑上是一个COMM-user。一个端口组应该作为一个用户与COMM进行通信。 |
基本原理: |
在AUTOSAR 发行版2.1中,它不可能使用软件组件模板来表示COMM用户。相应地,不能根据一个用户的语义判断其是完全的通信,安静的通信还是无通信。一个软件组件的哪些端口受到此用户的模式的影响? 作为一个添加的值,通过评估与相应的端口相连的模式组以及通信硬件,一个’COMM 配置器’可以自动地将用户的矩阵设置为需要的通信基础结构。 |
使用案例: |
常见的使用案例是:一个软件组件有一些高度可用的端口,而某些功能仅被用于某些特殊的功能。通过将这些端口分为两个端口组,此目的可以被达到。 |
相关性: |
ComM配置器,软件组件模板,evtl.RTE |
冲突: |
无 |
支持材料: |
-- |
发起人: |
-- |
3.11.4 [BRF00103]对模式相关IPDU组的控制
标识: |
BRF00103 |
发起人: |
Denso |
日期: |
2007年06月29日 |
简述: |
对模式相关IPDU组的控制 |
重要性: |
中等 |
描述: |
它只应该允许IPDU组出线在选择的汽车模式中。 |
基本原理: |
在发行版2.1中,它只可能限制一个通道的通信。在许多情况下,取决于模式,它必须保持通道的完整通信,但是限制被允许发送的IPDU组。 |
使用案例: |
这可以被用于在汽车的一个电源模式中可用但是在另一个电源模式中不可用的信号。注意:将整个通道限制为无通信通常是不够的。此特征可以减小关键模式中的总线负载。 |
相关性: |
VMM/AMM;COM;ComM |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.11.5[BRF00104]与模式有关的初始值的复位
标识: |
BRF00104 |
发起人: |
Denso |
日期: |
2007年06月29日 |
简述: |
与模式有关的初始值的复位 |
重要性: |
中等 |
描述: |
在进入一个汽车模式时,它应能够将每一个信号初始值重置为一个可配置的初始值。 |
基本原理: |
在发行版2.1中,它只能设置一次一个信号的初始值。但是,在某些电源模式下,一个信号将不可用。为了迅速地恢复,但信号再次可用时,它应能够恢复一个初始值。 |
使用案例: |
这可以被用于在汽车的一个电源模式中可用但是在另一个电源模式中不可用的信号。注意:将整个通道限制为无通信通常是不足的。 |
相关性: |
VMM/AMM;COM;ComM;BRF00103 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.11.6[BRF00189]允许软件组件请求专门的模式
标识: |
BRF00189 |
发起人: |
AUTOSAR WP汽车和应用模式管理 |
日期: |
2007年12月03日 |
简述: |
允许软件组件请求专门的模式 |
重要性: |
高 |
描述: |
如果被配置到每一个ECU上,一个或者几个ECU软件组件可以请求一个模式。模式请求被传播到一个特定的功能,该功能会根据收到的模式请求控制受影响的BSW. |
基本原理: |
取决于其内部状态,一个软件组件必须要能够开始或者请求(最低要求)可操作模式的变化。此功能可以被用于将功耗(和功率发射)调整为应用状态或者整个汽车状态。 由于可不能定义模式相关的行为(它是通用的并且与用户无关),软件组件必须要能够开始模式变化。用户特定的行为将被实现到用户特定的软件组件中。 |
使用案例: |
使用案例需要根据模式信息来控制基本软件和可运行状态执行.. |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.11.7 [BRF00190]模式请求的、可配置的BSW内部评估
标识: |
BRF00190 |
发起人: |
AUTOSAR WP汽车和应用模式管理 |
日期: |
2007年12月03日 |
简述: |
模式请求的可配置的BSW内部评估 |
重要性: |
高 |
描述: |
由于是一个参数驱动的行为,BSW内部模式控制功能的行为将是可以配置的。 当模式控制功能的原则为通用原则时,具体的行为可以被配置为用户特定的。 |
基本原理: |
通过使用模式控制的通用机制,它能够实现用户特定的,软件组件的模式相关行为,但是不必在任何软件组件中实现一个用户特定的模式控制。 |
使用案例: |
使用案例,它需要根据模式信息来控制基本软件和可运行状态执行。 |
相关性: |
BRF00189 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.11.8 [BRF00191]模式信息的传送
标识: |
BRF00191 |
发起人: |
AUTOSAR WP汽车和应用模式管理 |
日期: |
2007年12月03日 |
简述: |
一个模式可以影响几个ECU上的软件组件。因此,通过配置,模式信息必须被传送到几个ECU. |
重要性: |
高 |
描述: |
一个模式可以影响几个ECU上的软件组件。因此,通过配置,模式信息必须被传送到几个ECU. |
基本原理: |
一个系统级别的模式同步是必需的,以使整个系统保持一致。 |
使用案例: |
所有的使用案例需要控制基本软件和可运行状态控制。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.12 固定的数据交换概念
3.12.1[BRF00105]系统参数
标识: |
BRF000105 |
发起人: |
Continental |
日期: |
2007年07月02日 |
简述: |
在编译时间(由带有宏的RTE实现)期间或者在运行时间(由校准实现)期间被设置的系统参数 |
重要性: |
中等 |
描述: |
标准发送器-接收器机制被用于动态地交换数据。#define macros的交换不需要一个明确的和动态的读取,既然该值是固定的。在编译时间内,该值应该被设置到所有的用户中。 这应该被端口规范化,以展示相关性。此特征可以被校准参数概念的一个扩展实现:对一个CalPrm来说,一个参数设置类型可以显示它是一个先前固定的(设置类型=编译时间,例如,一个#define macro)还是一个后面固定的(设置类型=运行时间,例如,读取闪存中的校准数据)。此新的参数设置类型帮助RTE选择正确的实现。 消耗此CalPrm的一个软件组件的实现不应该取决于它是编译时间还是运行时间。所以一个固定的数据不应该被用于预编译指令(例如,#F),即使设置类型=编译时间。作为一个替代方法,集成者可以决定使用闪存中的校准数据(设置类型=运行时)。在这种情况下,RTE API实现将会产生一个编译错误,既然#IF只可以与宏一起使用。 此类#IF指令的使用涉及到”变型处理”概念。 |
基本原理: |
某些软件组件可以保持一些固定的数据(#define macro),这些数据可以被其它软件组件使用。在编译时,固定的数据应该被设置到所有的用户中,但是,不会用当前的发送器-接收器通信机制来设置。 |
使用案例: |
|
相关性: |
BRF00157:期望此特征添加一个新的元素,以将一个”未连接的”Rport设置到一个固定的值。 校准概念 BRF00029:变型处理 BRF00167:用宏值设置变型 |
冲突: |
问题:一个Calprm既可以被用作一个算法中的数据,也可以作为变型的一个输入。 例子:在一个传动系统应用中,圆柱体的一个参数编号可以被用到一个for循环中或者被用到一个预编译指令中,以设置一个变型。 |
支持材料: |
-- |
接收者: |
-- |
3.12.2 [BRF00157]用于RPort的固定值
标识: |
BRF00157 |
发起人: |
Continential |
日期: |
2007年10月04日 |
简述: |
用于Rport的固定值 |
重要性: |
低 |
描述: |
为未连接的发送器-接收器RPort提供初始值 |
基本原理: |
如果相同的软件组件被用于不同的AUTOSAR系统中,那么在较低功能的系统中,软件组件通常没有需要的端口。在这种情况下,发送器-接收器RPort的初始值必须被提供。 |
使用案例: |
能轻易地再次使用有不同总体功能的系统中的软件组件。允许AUTOSAR系统的精益设计。避免天然软件组件的创建的开销提供初始值。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
当前,由于系统完整性检查的原因,RTE拒绝用未连接的RPort进行配置。 建议:定义一个VFB级别的专门的元素,它能够为有需要的发送器接收器端口提供静态初始值。 |
接收者: |
-- |
3.13 变型处理概念
3.13.1[BRF00029]VFB级别的变型处理
标识: |
BRF00029 |
发起人: |
GM |
日期: |
2007年05月03日 |
简述: |
-- |
重要性: |
高 |
描述: |
规定一个机制,用于描述VFB级别的可变性,以及此可变性是如何被进一步分解为方法和模板的。 |
基本原理: |
汽车中的电子系统的设计支持几种变型,以节省劳力和金钱,并提升质量。支持变型的概念需要时VFB级别的。 |
使用案例: |
|
相关性: |
主要工作将被执行到AUTOSAR模板的WP通用方法中以及用于包含概念的配置中。 |
冲突: |
-- |
支持材料: |
支持材料:AUTOSAR BSW已经支持用于某些BSW模块的几个配置。缺少的是恰当的方法和来自较高级别模板的输入(SWC-T,Sys-T,EcuC-T)以及VFB级别的一个概念。 |
接收者: |
-- |
3.13.2[BRF00155]允许一个软件组件有不同的接口
标识: |
BRF00155 |
发起人: |
Renault |
日期: |
2007年09月07日 |
简述: |
允许一个软件组件有不同的接口 |
重要性: |
中等 |
描述: |
通过允许或者禁止基于参数的端口接口来实现多样化,并使用#define来完成预编译优化。 |
基本原理: |
多样性管理:根据一个参数来重组有不同接口的、在单个组件类型中的一个软件组件的所有变型。 此特征将减少在版本管理系统中被追踪的目标数,既然相同的组件参考可以被用到不同的配置中。 |
使用案例: |
如果被使用到一个柴油发送机或者汽油发送机中的话,相同的组件可以有不同的接口,但是部分功能是不可改变的。例如,两个变型都有许多共同的传感器,和几个需要不同接口的特殊传感器。 |
相关性: |
软件组件模板 RTE SWS |
冲突: |
为了将VFB机制用于实际软件组件实现中的变型处理,这可以是BRF00029的一个扩展, |
支持材料: |
-- |
接收者: |
-- |
3.13.3[BRF00167]用于设置变型的宏值
标识: |
BRF00167 |
发起人: |
Continental |
日期: |
2007年10月12日 |
简述: |
用于设置变型的宏值 |
重要性: |
中等 |
描述: |
宏可以被用于禁止/激活一个代码变型。 一个宏由一个软件组件产生(BRF00105,CalPrm,SetWhile =编译时间),然后由其它软件组件使用。宏被使用到编译指令(例如,#IF)中,以激活或者禁止算法的某些部分。 |
基本原理: |
经常用宏值来处理代码变型。 |
使用案例: |
详见BRF00029 |
相关性: |
BRF00105 BRF00029 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.14总线监控问题概念
3.14.1[BRF00087]API询问FlexRay速率和偏移校正值
标识: |
BRF00087 |
发起人: |
Daimler |
日期: |
2007年05月29日 |
简述: |
API询问FlexRay速率和偏移校正值 |
重要性: |
低 |
描述: |
|
基本原理: |
它可以被用于获得当前的漂移速率和每一个FlexRay控制器的偏移。 新的特征需要满足安全要求OSR107 AUTOSAR应该提供ECU硬件监控和测试,以检测下列组件中的故障:
|
使用案例: |
对专门的FlexRay控制器的’漂移’的监控可以缩短错误分析的时间。 对专门的FlexRay控制器的’漂移’的监控可以预测硬件错误。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.14.2[BRF00093]检测丢失的FlexRay启动帧
标识: |
BRF00093 |
发起人: |
Daimler |
日期: |
2007年05月29日 |
简述: |
检测丢失的FlexRay启动帧 |
重要性: |
低 |
描述: |
它应能够检测这种情况:没有启动帧出现,但是由于有可用的同步帧,FlexRay仍然在运行。 |
基本原理: |
每个网络至少由2个冷启动节点组成,这些冷启动节点发送启动帧。如果没有启动帧出现的话,所有的冷启动节点会被关闭;因此,在没有预先关闭所有节点的情况下,任何节点都不可能将其自身集成到网络中。 此显示可以被用于”强迫所有节点关闭”,以允许所有节点重启。 |
使用案例: |
包含3个冷启动节点和2个同步节点的一个网络。如果一个错误(例如,复位或者低电压)使3个冷启动节点进入睡眠/执行一次重启,那么必须重启FlexRay,以允许所有FlexRay节点的再次集成。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.14.3[BRF00264]将FlexRay收发器错误报告给诊断
标识: |
BRF000264 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
将FlexRay收发器错误报告给诊断 |
重要性: |
高 |
描述: |
此特征的目的是提供收发器可用的错误和状态信息给主机。当不同的收发器提供不同状态信息并且使它们可用于不同的方式时,此特征尝试去标准化最少的共同错误和状态信息,从而为收发器所有权信息提供空间。 |
基本原理: |
AUTOSAR收发器驱动隐藏收发器实现的细节。与物理收发器驱动相连的上层接口提供一个标准化的错误接口,也许,0 -127反映所有收发器支持的强制性错误,128 – 255可以反映收发器特定的错误信息。 |
使用案例: |
诊断需要检测这些错误来了解系统特性的状态。 |
相关性: |
错误处理,DET , DCM , FlexRay驱动,FlexRay接口。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.14.4[BRF00265]报告应用的FlexRay时钟校正项
标识: |
BRF00265 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
报告应用的FlexRay时钟校正项 |
重要性: |
高 |
描述: |
规范 |
基本原理: |
没有功能用于提供应用的时钟校正项到上层。 |
使用案例: |
诊断需要检测这些错误来理解系统特性的状态。 在开发以及持续的操作过程中有用。 |
相关性: |
错误处理,DET , DCM , FlexRay驱动,FlexRay接口。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.14.5[BRF00266]报告聚合的FlexRay通道状态错误
标识: |
BRF00266 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
报告聚合的FlexRay通道状态错误 |
重要性: |
高 |
描述: |
详见规范 |
基本原理: |
总线的正确诊断需要集合的通道状态错误。 |
使用案例: |
诊断需要检测此错误来了解系统特性的状态。 在系统的开发和运行过程中,检测和区别不同的错误类型。 |
相关性: |
错误处理,DET , DCM , FlexRay驱动,FlexRay接口。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.14.6[BRF00267]报告同步帧的FlexRay状态数据数
标识: |
BRF00267 |
发起人: |
GM |
日期: |
2008年01年31日 |
简述: |
报告同步帧的状态数据数 |
重要性: |
高 |
描述: |
详见标准 |
基本原理: |
状态数据包含了每一个通道接收的或者发送的同步帧数。 |
使用案例: |
诊断所必需的,用于检测不同节点所使用的时钟校正项的永久不对称性。 可以用于设置DTC.允许服务丢失的节点。 |
相关性: |
错误处理,DET , DCM , FlexRay驱动,FlexRay接口。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.14.7 [BRF00299]报告标识清单的FlexRay状态数据
标识: |
BRF00299 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
报告标识清单的状态数据 |
重要性: |
高 |
描述: |
详见规范 |
基本原理: |
状态数据包含了每一个通道上接收的或者发送的标识清单。 |
使用案例: |
诊断所必需的,用于检测不同节点所使用的时钟校正项的永久不对称性。 可以用于设置DTC.允许服务丢失的节点。 |
相关性: |
错误处理,DET ,DCM ,FlexRay驱动,FlexRay接口。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.15 支持SAE J1939协议特征的概念
3.15.1[BRF00168]支持SAE J1939协议特征
标识: |
BRF00168 |
发起人: |
Volvo ,Daimler和Vector |
日期: |
2007年10月22日 |
简述: |
支持SAE J1939协议的子集。 |
重要性: |
高 |
描述: |
选择的SAE J1939协议特征的子集,允许它与SAE J1939组件进行恰当的通信。 CAN标志符处理:一个功能,它需要了解与一个PGN有关的源地址。相同的PGN可以被同一辆汽车内的多个发送器发送。在配置过程中,有相同PGN的源地址的结合被限制(5-10种结合)和知道。不需要动态寻址;CAN标志符中的优先权位是固定的。在配置时间,CAN标志符被完全知悉。 在改变EOL数据(参数)而不重新编译CAN驱动软件的情况下,重新配置应该是可能的。自身的TX信息也需要这些特征。
信息请求:不需要向其它设备请求信息。
传输层:SAE J1939传输协议CMDT(连接模式数据传递)和BAM(广播通知信息传送)都应该被支持。
诊断信息:将被周期地发送出去,当出现错误时也会被发送。
信息长度:需要有可变长度的参数。需要长度大于64位的参数。
J1939网络管理:仅有J1939网络管理的一个子集被需要:当出现’地址声明’和地址冲突时,较低优先权的ECU将停止工作。 |
基本原理: |
请求的SAE J1939功能的子集将允许它与J1939CAs进行整合和通信。许多卡车OEM需要保持有多个网络的系统。包括SAE J1939. |
使用案例: |
使用案例A:现有的SAE J1939组件可以被集成和再次使用。 使用案例B:SAE J1939协议是许多市场中的一个工业标准。因此,卡车OEMs必须支持J1939. |
相关性: |
RTE规范 COM |
冲突: |
-- |
支持材料: |
某些解释: — PGN位置参数组编号:29位的CAN 标志符被组织到几个字段中。其中一个字段是PGN,它由SAE进行标准化,并用于所有的信息。例如,引擎温度有一个其自己的PGN.
|
接收者: |
-- |
3.16 LIN 2.1标准概念
3.16.1 [BRF00184]调整LIN 2.1规范中的LIN堆栈
标识: |
BRF00184 |
发起人: |
AUTOSAR WP COM Stack |
日期: |
2007年05月03日 |
简述: |
调整LIN 2.1规范中的LIN堆栈 |
重要性: |
低 |
描述: |
调整LIN 2.1规范中的LIN堆栈 |
基本原理: |
-- |
使用案例: |
-- |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.17 FlexRay ISO TP概念
3.17.1 [BRF00192]支持FlexRay信息标志符
标识: |
BRF00192 |
发起人: |
BMW |
日期: |
2007年12月09日 |
简述: |
支持FlexRay信息标志符 |
重要性: |
中等 |
描述: |
FlexRay规范描述了一个通信机制,它通过一个设置的”信息标识符”(它被包含在数据帧中,作为数据负载的一部分)来识别数据帧。对数据帧进行识别是另外一种可能性。 |
基本原理: |
由于FlexRay存在高负载,它不可能形成公共的时序表(覆盖一个以上的模型列)。将一个硬连线的时隙/周期设置转变为具有一定质量的服务方法将解决此问题。 |
使用案例: |
由于不需要改变FlexRay时序表,在一个FlexRay网络中,从一个ECU到另一个ECU的数据活动(在一个软件组件中)将不会导致其它ECU的再次编译。 |
相关性: |
当前,此通信机制已经被分类为’选择性的’。然而每一个现有的FlexRay通信控制器都实现了此功能,并且当前,FlexRay联盟将它规定为强制性的。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.17.2[BRF00252]ISO 10681-2符合FlexRay通信
标识: |
BRF00252 |
发起人: |
Daimler |
日期: |
2008年01月28日 |
简述: |
ISO 10681-2 |
重要性: |
高 |
描述: |
FlexRay通信堆栈(FrDrv , Frlf和FrTp)应该支持ISO-10681-2文件中描述的通信。 |
基本原理: |
|
使用案例: |
|
相关性: |
FrTp , Frlf , FrDrv |
冲突: |
-- |
支持材料: |
文件:ISO 10681-2 公路汽车 – FlexRay上的通信 – 部分2:通信层服务 |
接收者: |
-- |
3.18LIN收发器驱动
3.18.1 [BRF00228]规定LIN收发器
标识: |
BRF00228 |
发起人: |
Bosch |
日期: |
2008年01月25日 |
简述: |
规定LIN收发器 |
重要性: |
高 |
描述: |
AutoSar中没有LIN收发器规范。但是,应该为LIN收发器的行为制定一份规范。 |
基本原理: |
当前,没有针对非现有LIN收发器的接口描述/概念。所以,它需要AutoSar中未规定的所有Lin收发器实现方案。为了弥补此空白,并且有一个完整的描述(从LIN驱动到LIN接口),它也需要LIN收发器文件。 |
使用案例: |
-- |
相关性: |
LIN SRS可以被调整。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.19 FlexRay 协议规范问题概念
3.19.1 [BRF00268]支持FlexRay单槽模式
标识: |
BRF00268 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
支持FlexRay单槽模式 |
重要性: |
高 |
描述: |
FlexRay包括一个”单槽”模式,它可以被配置,以用作启动程序的一个扩展。在集成过程中,所有的FlexRay节点仅在静态字段中发送一个帧(被识别为”关键槽”)。如果它们的定时是不正确的并且它们发送到其它节点的槽中,那么上述方法将减少它们可能占用的帧的数量。一旦它们整合了,将出现两种可能性。 只要当它们整合了,不使用单槽模式的节点将允许它们的其它帧(静态的和动态的)被自动地使能。优先的假设是:它们的集成完全与时序表完全一致,以允许这些发射被使能。 使用单槽模式的节点必须允许使用一个明确的主机命令来发送它们的其它帧。在这种情况下,优先的假设是:主机将首先执行某种明确的确认—在其执行命令之前,其发送的帧被恰当地定时。这包括仅有发送定时有缺陷的情况-以一种不影响整合能力的方式。执行此配置的可能的方式是:配置另一个节点,使用其发送的一个帧内的一个标志来明确地确认单槽帧的定时。如果它从节点接收单帧,那么它将用确认标志设置来简单地发送一个规定的帧。如果主机发现并接收此确认标志,它将发送命令到控制器,以禁用单槽模式,这将使所有的帧被允许。 |
基本原理: |
FlexRay为单槽模式提供支持。 |
使用案例: |
仅有当控制器从单槽模式转换到正常通信(例如,所有槽被激活)后才激活网络管理。 单槽模式被用于诊断,以限制所有槽的发送,直到节点被确保:它不会干扰其它节点发送的正常通信信息,例如,当它处于一个兼容系统模式时,节点从单槽模式过渡。 |
相关性: |
模式管理,COM,汽车模式管理,FlexRay状态管理器 |
冲突: |
|
支持材料: |
根据当前的FR驱动,它不可能使用单槽模式。所有的槽模式都应该被支持。API应该被提供,以转换到ALL_SLOT模式;它应该由Frlf提供。FrSm将不会调用此API,但是,它必须由OEM特定的SM扩展来完成。 错误处理组应该被使用,Fr驱动和Frlf好像是被使用了,但是它未被列入相关性清单中,如果特征请求的话。 |
接受者: |
-- |
3.19.2[BRF00273]支持双FlexRay通道
标识: |
BRF00273 |
发起人: |
AUTOSAR PL |
日期: |
2007年05月03日 |
简述: |
支持双FlexRay通道 |
重要性: |
高 |
描述: |
基本上,有三种类型的集群:
AUTOSAR中的限制明确地表明:(a)被支持,(c)不被支持,(c)的要求不能被达到,除非你可以唤醒所有的设备。 限制条件中没有直接关于b)的,但是,在没有管理冷启动抑制并提供一个机制来协调两个通道上的唤醒的情况下,你不能启动一个双通道集群。 这在前面已经被陈述过。根据我个人的看法,陈述的限制给人的印象是:它缺少唤醒转发,但是实际的限制是:仅有单通道集群被支持。我认为它应该更清楚地表达。 此问题也比FRSM更严重。网络管理也不会正常地工作,除非某些节点将一个通道的网络管理投票与其它通道的网络管理投票串联,但这也是挺棘手的事。 |
基本原理: |
FlexRay提供双通道。 |
使用案例: |
机制应该被改善,以处理由一个”参考配置”组成的大多数通用案例:
需要进一步的分析,以识别所有必要的变换,但是,下列的两个目标应该被及时地识别:
第一个目标需要下列的新机制:
第二个目标需要下列的新机制:
它可以开发(?)章节中描述的分散的时序表,使接收节点可以看到这些时序表。 |
相关性: |
网络管理,FlexRay状态管理器 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.20 FlexRay 规范3.0概念
3.20.1 [BRF00272]支持激活的FlexRay Stars
标识: |
BRF00272 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
支持激活的FlexRay Stars |
重要性: |
高 |
描述: |
激活的Stars是有效的FlexRay拓扑结构的一部分。 |
基本原理: |
|
使用案例: |
|
相关性: |
FlexRay收发器,FlexRay接口,FlexRay状态管理器。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.20.2[BRF00277]支持FlexRay规范3.0
标识: |
BRF00277 |
发起人: |
BMW |
日期: |
2008年01月31日 |
简述: |
支持FlexRay规范3.0 |
重要性: |
高 |
描述: |
AUTOSAR FlexRay Stack应该支持 - FlexRay协议规范3.0 - FlexRay电物理层规范3.0 |
基本原理: |
AUTOSAR发行版4.0也应该满足最新的FlexRay规范。 |
使用案例: |
-将AUTOSAR 4.0软件与最新的FlexRay硬件一起使用 |
相关性: |
FlexRay Stack |
冲突: |
-- |
支持材料: |
http://www.flexray.com/ |
接收者: |
-- |
3.21.1[BRF00283]允许BSW通过TCP/IP进行通信
标识: |
BRF00283 |
发起人: |
BMW |
日期: |
2008年01月21日 |
简述: |
允许BSW通过TCP/IP进行通信 |
重要性: |
高 |
描述: |
添加TCP/IP协议栈。 |
基本原理: |
|
使用案例: |
|
相关性: |
BRF00286(支持以太网作为一个附加的通信媒体) |
冲突: |
|
支持材料: |
RFC 1122,对因特网主机-通信层,IETF的要求(http://www.letf.org/rfc1122.txt?number=1122) IEEE 802.3-2002(以太网) (http://standards.ieee.org/getieee802/802.3.html) |
接收者: |
-- |
标识: |
BRF00284 |
发起人: |
BMW |
日期: |
2008年01月21 |
简述: |
允许所有的应用直接通过TCP/IP进行通信 |
重要性: |
高 |
描述: |
允许应用通过一个TCP/IP协议栈发送和接收数据(将一个标准接口用于RTE中)。 |
基本原理: |
应用之间增加了对通用数据交换的需要,它们不能被轻易地映射到信号中。 |
使用案例: |
|
相关性: |
BRF00286(支持以太网作为一个附加的通信媒体) |
冲突: |
- |
支持材料: |
RFC 1122,对因特网主机-通信层,IETF的要求(http://www.letf.org/rfc1122.txt?number=1122) IEEE 802.3-2002(以太网) (http://standards.ieee.org/getieee802/802.3.html) |
接收者: |
-- |
标识: |
BRF00285 |
发起人: |
BMW |
日期: |
2008年01月21日 |
简述: |
允许PDU路由器通过TCP/IP进行通信 |
重要性: |
高 |
描述: |
允许PDU路由器通过一个TCP/IP协议栈发送和接收IPDUs. |
基本原理: |
发布ISO要求,用于以太网汽车访问。 |
使用案例: |
|
相关性: |
BRF00286(支持以太网作为一个附加的通信媒体) BRF00285(允许PDU路由器通过TCP/IP进行通信) |
冲突: |
|
支持材料: |
RFC 1122,对因特网主机-通信层,IETF的要求(http://www.letf.org/rfc1122.txt?number=1122) IEEE 802.3-2002(以太网) (http://standards.ieee.org/getieee802/802.3.html) |
接收者: |
-- |
3.21.4[BRF00286]支持以太网作为一个附加的通信媒体
标识: |
BRF00286 |
发起人: |
BMW |
日期: |
2008年01月21日 |
简述: |
支持以太网作为一个附加的通信媒体 |
重要性: |
高 |
描述: |
允许以太网被Autosar Com Stack使用。 |
基本原理: |
|
使用案例: |
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
RFC 1122,对因特网主机-通信层,IETF的要求(http://www.letf.org/rfc1122.txt?number=1122) IEEE 802.3-2002(以太网) (http://standards.ieee.org/getieee802/802.3.html) |
接收者: |
-- |
3.21.5[BRF00287]通过IP实现诊断通信
标识: |
BRF00287 |
发起人: |
Daimler |
日期: |
2008年01月30日 |
简述: |
一个通信堆栈(如FlexRay TP或者CAN-TP)的实现,基于ISO TC22/SC3/WG1/TF3中的一个ISO标准,用于TCP/IP(DoIP)诊断通信。 |
重要性: |
高 |
描述: |
此特征应该允许ISO TC22/SC3/WG1/TF3中定义的要求的标准实现。此通信协议栈类似于ISO 15765-2 CAN传输协议或者即将来临的、基于FlexRay传输协议的ISO标准,它应该通过PDI-ID被集成到AUTOSAR结构中,从而可以通过PDU路由器接口被访问。 由于新的DoIP标准与前面提到的CAN和FlexRay传输协议有一点点不同,它必须确保所有必要接口,服务和配置选项被定义,使之与新的DoIP协议进行无缝对接。 |
基本原理: |
像ISO 15765-2和FlexRay一样,新的DoIP标准最可能被将来的发射立法参考,它将被用于测试设备和汽车之间的诊断通信。 正如所有的ISO标准一样,一个普通的实现将改善稳定性和软件质量,并且应该可以被集成于未来的、基于AUTOSAR的ECU软件结构中。 |
使用案例: |
-快速再次编程 -通过计算机网络和因特网进行远程汽车诊断通信 -诊断通信的扩展能力,用于未来的物理层(例如,以太网,WLAN,GPRS,等等) |
相关性: |
此特征请求基于TCP/IP和以太网支持的BMW特征请求(BRF00284) |
冲突: |
|
支持材料: |
IETF RFC 791 因特网协议-DARPA因特网计划-协议规范(1981年9月) IETF RFC 2460 因特网协议,第6版(IPv)规范(1998年12月) IETF RFC 793 传输控制协议 – DARPA因特网计划 – 协议规范(1981年9月) IETF RFC 768 用户数据包协议(1980年8月) IETF RFC 2131 动态主机配置协议(1997年3月) 协议编号 协议编号,IANA, http://www.iana.org/assignments/protocol-numbers(最新更新时间2006年3月28日) IETF RFC 826 一个因特网地址解决协议(1982年11月) IEEE 802.3 IEEE标准集,定义有线以太网的物理层和数据链路层 IETF RFC 792 因特网控制信息协议DARPA因特网计划-协议规范(1981年9月) IETF RFC 1122 对因特网主机-通信层的要求(1989年10月) IETF RFC 1533 DHCP选择和BOOTP商家扩展(1993年10月) IETF RFC 2373 IP版本6 寻址结构(1998年7月) IEEE EUI-64 “指导纲领,用于64位全球标志符(EUI-64)注册授权” http://standards.ieee.org/db/oui/tutorials/EUI64.html,1997年3月。 IETF RFC 2463 因特网控制信息协议(ICMPv6),用于因特网协议版本6(IPv6)规范(1998年10月) IETF RFC 3315 用于IPv6的动态主机配置协议(DHCPv6)(2003年7月) ISO/DIS 15031-5.4 公路汽车-汽车与(用于与发射有关的诊断的)外部设备之间的通信— 部分5:与发射有关的诊断服务(日期:2004年12月10日) ISO 3779 公路汽车-汽车识别码(VIN)- 内容和结构(当前阶段90.93,阶段日期:2003年09月30日 ) 端口编号 端口编号,IANA, http://www.iana.org/assignments/port-numbers(最近更新时间2006年6月06日) IETF RFC 3330 特别使用IPv4 地址(2002年9月) IETF RFC 3927 IPv4本地链接地址的动态配置(2005年5月) IETF RFC 2893 IPv6主机和路由器的过渡机制(2000年8月) |
接收者: |
-- |
3.22 时间决定论概念
3.22.1[BRF00120]对一个网络集群内的一个同步时间基准的规定
标识: |
BRF00120 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
对一个网络集群内的一个同步时间基准的规定 |
重要性: |
高 |
描述: |
AUTOSAR应该为一个网络集群内的一系列ECU提供一个同步的时间基准。 |
基本原理: |
1/允许分布式的软件组件来同步活动 2/检测并补偿其中一个ECU的错误时钟 3/用于决定论行为。 |
使用案例: |
四个ECU上的四个软件组件同时读取车轮速度,用于刹车控制算法。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意:
|
接收者: |
-- |
标识: |
BRF00121 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
运行时定时保护 |
重要性: |
高 |
描述: |
AUTOSAR应该提供静态配置的运行时定时保护和监控。这包括监控任务在规定的时间内被分派,符合它们的时间预算,并且不会独占OS资源。 |
基本原理: |
为了保证安全相关的功能将在其定时限制内执行。独占CPU的任务将被检测和处理(如大的ECU负载,许多中断请求)。 |
使用案例: |
如果一个任务的最后期限未被满足,那么,它可以被重启或者一个错误会被报告。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意: 1/监控任务的执行情况,以检测调度程序的错误行为(例如,与实时的偏离); 2/由于可运行状态会被映射到任务中,可运行状态监控可以通过一个累积的方式来完成或者通过将单个可运行状态设置到ECU配置中的任务而完成。 |
接收者: |
-- |
3.22.3[BRF00122]支持定时限制
标识: |
BRF00122 |
发起人: |
AUTOSAR安全团队 |
日期: |
2007年05月09日 |
简述: |
支持较高的定时界限。 |
重要性: |
高 |
描述: |
它应该可以开发基于AUTOSAR的实现(对抖动、延迟和执行时间有可变的定时限制)。这意味着任务和通信计时策略不应该与此相矛盾。 与任务计时,通信计时以及(对外部事件的)响应性有关的要求。 |
基本原理: |
-- |
使用案例: |
-- |
相关性: |
BRF00121 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.22.4[BRF00123]对外部事件的响应性
标识: |
BRF00123 |
发起人: |
AUTOSAR安全团队 |
日期: |
2007年05月09日 |
简述: |
对外部事件的响应性 |
重要性: |
高 |
描述: |
AUTOSAR应该允许使用外部事件作为时序安排的一个引发剂。 |
基本原理: |
由于某些外部事件需要一个及时的响应,以确保这些事件有正确的、能够激发任务的行为。 |
使用案例: |
由记号驱动的计时程序将从一个引擎的曲柄轴的角度来计算。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
外部事件包括输入输出及中断 |
接收者: |
-- |
3.22.5[BRF00125]监控本地时间
标识: |
BRF00125 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
监控本地时间 |
重要性: |
高 |
描述: |
AUTOSAR应该提供一个机制用于监控ECU本地时间。 |
基本原理: |
这是一个必要的基础,用于决定安全功能的执行和系统失效的检测(在保证的时间间隔内由安全集成功能完成)。 |
使用案例: |
本地时间被监控,以保证ECU上的安全相关可运行状态有正确的定时。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意: 1/此方法通常需要一个独立的时钟。这可以由一个硬件看门狗来实现。作为一种选择,一个不同的ECU及其本地时间可以被用作一个看门狗。另一种方案是:使用一个ADC和电容器。 |
接收者: |
-- |
3.22.6[BRF00126]软件组件的同步服务
标识: |
BRF00126 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
软件组件的同步服务 |
重要性: |
高 |
描述: |
AUTOSAR应该提供机制,以允许相同或者不同ECU上的软件组件同步其行为 |
基本原理: |
允许可运行状态遵守其定时限制。 |
使用案例: |
1/两个可运行状态必须在相同的时间窗口内从一个传感器读取数据,这样,它们才可以进行投票; 2/(在不同ECU上的)两个分散的软件组件执行同步。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.22.7[BRF00127]服务,用于访问同步的时间基准
标识: |
BRF00127 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
服务,用于访问本地时间和全球时间 |
重要性: |
高 |
描述: |
AUTOSAR应该提供一个服务来访问同步时间基准,可用于BSWM和SWC. |
基本原理: |
允许软件组件执行与时间有关的动作,特别是同步和监控。 |
使用案例: |
一个安全相关的功能可能需要对一个特殊操作的执行进行计时,或者它可能需要知道两次事件的时间间隔到底是多少。此定时信息也可以与另一个ECU的另一个任务进行对比或者通过另一个ECU的另一个任务被计算出,为了达到此目的,这两个任务必须使用相同的时间基准。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意: 1/大多数安全相关的功能将被确定地安排时序,这就意味着它们知道自从上一次启动运行到现在已经过去多长时间了。但是,可能会出现这样的情况:一个任务本身需要更准确的定时,或者需要更准确的定时来帮助一个任务与另一个ECU上的另一个任务进行同步。 |
接收者: |
-- |
3.22.8[BRF00278]将AUTOSAR OS与一个明确定义的提供总线系统中的全球时间进行同步
标识: |
BRF00278 |
发起人: |
BMW |
日期: |
2008年01月31日 |
简述: |
将AUTOSAR OS与一个明确定义的提供总线系统中的全球时间进行同步 |
重要性: |
中等 |
描述: |
它应该可以将AUTOSAR OS与一个明确定义的、快速的提供总线系统中的全球时间进行同步 |
基本原理: |
|
使用案例: |
|
相关性: |
AUTOSAR OS |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.23.1[BRF00279]有非静态配置的FF CC缓冲器的触发器配置
标识: |
BRF00279 |
发起人: |
BMW |
日期: |
2008年01月31日 |
简述: |
有非静态配置的FF CC缓冲器的触发器配置 |
重要性: |
高 |
描述: |
在运行时,它应能执行一个CC缓冲器再配置(例如,它不会在系统配置时间内被定义) 与硬件有关的配置参数由下列条目组成:
|
基本原理: |
-由XCP主动分配给XCP从动的动态带宽。 |
使用案例: |
-参数的处理,用于调整的目的(例如,底盘悬挂,马达管理…) |
相关性: |
Frlf,FrDrv |
冲突: |
-- |
支持材料: |
http://www.asam.net/doc_int/getfile/getfile.php?id=376 |
接收者: |
-- |
3.23.2[BRF00280]AUTOSAR BSW XCP模块
标识: |
BRF00280 |
发起人: |
BMW |
日期: |
2008年01月30日 |
简述: |
AUTOSAR BSW XCP模块 |
重要性: |
高 |
描述: |
XCP应该是一个AUTOSAR BSW,因为它已经在第一个AUTOSAR结构中被展示。 |
基本原理: |
|
使用案例: |
|
相关性: |
|
冲突: |
-- |
支持材料: |
http://www.autosar.org/download/AUTOSAR_LayerSoftwareArchitecture.pdf http://www.asam.net/doc_int/getfile/getfile.php?php?id=376 |
接收者: |
-- |
3.24网络管理协调概念
3.24.1[BRF00256]网络管理协调器应能够协调任何类型的AUTOSAR总线
标识: |
BRF00256 |
发起人: |
FMC |
日期: |
2008年01月25日 |
简述: |
网络管理协调器应能够协调任何类型的AUTOSAR总线 |
重要性: |
高 |
描述: |
“通用的网络管理接口”必须尽量通用,以支持网络之间的协调/同步。 |
基本原理: |
“通用的网络管理接口”必须支持任何类型网络之间的协调/同步,AUTOSAR中未包含的、总线特定的网络管理除外。它不应该是AUTOSAR的责任,但是会由OEM扩展标准组件的功能。 |
使用案例: |
协调多个网络的关闭。 同步多个网络的关闭。 改善关闭算法。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
发起人: |
-- |
3.24.2[BRF00271]网络管理协调器应该支持到FlexRay的网络管理网关
标识: |
BRF00271 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
网络管理协调器应该支持到FlexRay的网络管理网关 |
重要性: |
高 |
描述: |
当FlexRay是其中一个协调子网时,当前的网络管理协调器概念不可行。下面两个基本情况可以被考虑:
本文件的其余部分主要聚焦于前者,但是本文件的末尾对后者做了简短的介绍。 |
基本原理: |
|
使用案例: |
同步的关闭需要发生在FlexRay集群和CAN集群之间以及FlexRay集群和FlexRay集群之间。 |
相关性: |
网络管理接口,CAN网络管理,FlexRay网络管理 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.24.3[BRF00274]FlexRay网络管理时序安排定时窗解除
标识: |
BRF00274 |
发起人: |
GM |
日期: |
2008年01月31日 |
简述: |
FlexRay网络管理时序安排定时窗解除 |
重要性: |
高 |
描述: |
在使用静态字段时,定时窗被用于安排网络管理任务。网络管理Vector硬件服务太受限制,需要一个定时窗解除。特别是在相同的周期内一个网络管理任务可以被安排时序的时间与网络管理信息被发送到一个槽中的时间有关系时。一个定时窗口解除可以被用于下列两种窗口:
|
基本原理: |
|
使用案例: |
|
相关性: |
错误处理,DET,DCM,FlexRay驱动,FlexRay接口。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.25 软件组件的功能诊断概念
3.25.1[BRF00027]软件组件的功能诊断
标识: |
BRF00027 |
发起人: |
AUTOSAR PL |
日期: |
2007年05月03日 |
简述: |
软件组件的功能诊断 |
重要性: |
低 |
描述: |
每一个软件组件必须支持诊断BSWC的接口,以访问诊断相关的数据。这包括下列的元素(每一个元素必须有一个单独的元素可用,使DSP能够访问这些元素):
特殊的程序可以被启动,停止,以及通过诊断服务0x31请求的执行结果。 |
基本原理: |
诊断对工程,制造和服务来说是很重要的,它可以帮助排除故障,验证装配过程以及成功地识别问题并更换经销商的故障元件。 过去,诊断应用通过相关变量/元素(AUTOSAR设计中并不需要这些变量/元素)的存储器位置直接访问必要的数据。因此,每一个必要的软件组件中的单独接口(端口)必须支持”描述”中定义的所有特征。 |
使用案例: |
|
相关性: |
DCM,DEM |
冲突: |
|
支持材料: |
ISO14229-1,ISO 15031-5/SAEJ1979,ISO15031-6/SAEJ2012,CCR1968.2,EU 70/220/EWG |
接收者: |
-- |
3.25.2[BRF00229]软件组件的去中心化模块的诊断配置
标识: |
BRF00229 |
发起人: |
Daimler |
日期: |
2008年01月25日 |
简述: |
软件组件的去中心化模块的诊断配置 |
重要性: |
高 |
描述: |
每一个软件组件必须为软件组件,DEM&DCM提供其它诊断配置信息,使之能够生成端口用于连接这些模块,使诊断数据可以通过DCM被访问。 下列的元素需要由每一个软件组件和接口提供,因为这些元素需要被指定:
|
基本原理: |
根据去中心化的配置&接口要求,每一个软件组件应该提供和实现诊断接口,以允许DC(DSP)M和DEM中的代码生成和端口连接。一个诊断设计指导纲领应该定义用于每一个软件组件的这些接口(例如,新的文件和/或软件组件模板的更新)。 |
使用案例: |
ο由于现今的功能和相关的诊断是由几个公司开发的。因此,对于每一个功能及其诊断监控(例如,一个引擎控制器中的扭矩管理)来说,诊断能力都是被单独定义的,在开发过程中,它们没有必要彼此兼容。 ο系统整合以及诊断的结合,因为通过DCM和DEM的可访问性需要连接单独的功能和诊断特征,使之被编译为一个完整的诊断系统(如果它与OBD2认证有关的话)
ο开发去中心化模块的软件及其诊断,不需要永久性地与其它软件组件开发者进行交互作用。 ο结合模块并抽取模块特定的诊断数据 ο从软件组件链接诊断数据到DCM和DEM |
相关性: |
WP通用方法和配置 |
冲突: |
-- |
支持材料: |
ISO 14229-1 |
接收者: |
-- |
3.26 FlexRay网络可靠性概念
3.26.1[BRF00302]FlexRay发送完成确认
标识: |
BRF00302 |
发起人: |
Toyota和Bosch |
日期: |
2008年06月15日 |
简述: |
发送完成确定 |
重要性: |
高 |
描述: |
一条总线上的错误是根据发送和软件组件的检测信息来决定的。 |
基本原理: |
FlexRay网络可靠性的提升 |
使用案例: |
FlexRay错误处理 |
相关性: |
Fr,FrTrcv |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.26.2[BRF00303]FlexRay发送暂停时间处理
标识: |
BRF00303 |
发起人: |
Toyota和Bosch |
日期: |
2008年06月15日 |
简述: |
发送暂停时间处理 |
重要性: |
高 |
描述: |
当COM请求的动态帧在固定的时间内未被发送完时,使COM取消帧的发送的信息会被自动地发送。 |
基本原理: |
提升FlexRay网络的可靠性 |
使用案例: |
FlexRay错误处理 |
相关性: |
Frlf |
冲突: |
-- |
支持材料: |
-- |
发起人: |
-- |
3.26.3[BRF00304]FlexRay接收完成确认
标识: |
BRF00304 |
发起人: |
Toyota和Bosch |
日期: |
2008年06月15日 |
简述: |
接收完成确定 |
重要性: |
高 |
描述: |
在接收时,即使在一条总线上检测到一个错误,如果帧被判断为正常,那么它可以确定接收已经被完成了。 |
基本原理: |
提升FlexRay网络可靠性 |
使用案例: |
FlexRay错误处理 |
相关性: |
Fr |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.26.4[BRF00305]FlexRay有效负荷长度检查
标识: |
BRF00305 |
发起人: |
Toyata和Bosch |
日期: |
2008年06月15日 |
简述: |
有效负荷长度确定 |
重要性: |
高 |
描述: |
对这种情况的处理:可以规定假设的有效负荷长度与实际收到的有效负荷长度不同。 |
基本原理: |
提高FlexRay网络可靠性 |
使用案例: |
FlexRay错误处理。 |
相关性: |
Fr |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.26.5[BRF00306]FlexRay硬件检查
标识: |
BRF00306 |
发起人: |
Toyota和Bosch |
日期: |
2008年06月15日 |
简述: |
硬件检查 |
重要性: |
高 |
描述: |
检查本地节点的硬件失效。如下3种硬件故障将被检测:
(3)CC中的缓冲器的CC寄存器/抛锚故障 |
基本原理: |
提升FlexRay网络的可靠性 |
使用案例: |
FlexRay错误处理 |
相关性: |
RamTest,Fr,FrSm,FrTrcv |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.26.6[BRF00307]FlexRay复位/再次初始化
标识: |
BRF00307 |
发起人: |
Toyota和Bosch |
日期: |
2008年06月15日 |
简述: |
复位/再次初始化 |
重要性: |
高 |
描述: |
根据应用说明,使用下列单元来执行复位/再次初始化。
|
基本原理: |
提升FlexRay网络的可靠性 |
使用案例: |
FlexRay错误处理 |
相关性: |
Frlf,FrTrcv,FrSm,ComM |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.27 TTCAN概念
3.27.1[BRF00312]将TTCAN引入到认可的AUTOSAR中
标识: |
BRF00312 |
发起人: |
Bosch |
日期: |
2008年09月10日 |
简述: |
TTCAN时间触发的CAN扩展 |
重要性: |
中 |
描述: |
CAN协议被一个时间触发的调度程度扩展,允许时间触发的CAN信息。TTCAN是一个绝对的CAN超集,但CanSM,CanTP和CanNM中不会有任何的功能变化。超集意味着,TTCAN 也包含所有的CAN功能,例如,一个TTCAN堆栈可以同时为一条CAN总线和一条TTCAN总线服务。 |
基本原理: |
CAN是一个事件驱动的通信系统。即使引入了时间触发的扩展,CAN也可以被用作一个时间触发的总线系统。FlexRay、CAN及LIN之间可以实现一个有共同时间基础的、一致的通信系统。通过增加当前CAN通信的带宽,它可以达到一个接近100%的总线负载。根本的CAN协议的错误处理概念被支持安全相关应用的、可预测的通信扩展。 |
使用案例: |
-分布式的控制应用,对低延迟和低抖动作出了要求。 - 子总线与其它时间触发的协议,例如,FlexRay - 线控系统应用 - 曲柄轴同步通信,例如,马达控制单元 |
相关性: |
CAN |
冲突: |
|
支持材料: |
时间调度器是硬件(TTCAN控制器)的一部分。需要其它参数来支持其配置。 ISO 11898-4对TTCAN进行了标准化。 |
接收者: |
-- |
3.28调试概念
3.28.1[BRF00152]BSW变量可以通过外部调试器被访问
标识: |
BRF00152 |
发起人: |
Elektrobit |
日期: |
2007年09月03日 |
简述: |
BSW变量可以通过外部调试器被访问 |
重要性: |
低 |
描述: |
为了被调试,变量必须被定义为全球的、并被公开。 |
基本原理: |
为了允许调试模块来决定一个变量的大小,变量的类型定义需要通过主要的BSW标题文件被访问。 |
使用案例: |
-- |
相关性: |
-- |
冲突: |
-- |
支持材料: |
取代BRF00080和BRF00081 所以,在一个特定的实现中可以被调试的变量将取决于BSW模块。 但是,仍然存在一些要求:
|
接受者: |
-- |
3.28.2[BRF00083]ORTI兼容的XML模块描述
标识: |
BRF00083 |
发起人: |
Keil |
日期: |
2007年06月27日 |
简述: |
ORTI兼容的XML模块描述 |
重要性: |
中等 |
描述: |
每一个BSW模块和RTE应该创造一个额外的、必需的XML信息描述,以执行符号调试。 |
基本原理: |
允许主机工具显示其它信息,如位的编码,值的意义,注解等等。 |
使用案例: |
在调试会话过程中,显示人类可读的调试数据 |
相关性: |
请求与ORTI的功能向下兼容性 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.28.3[BRF00084]M2元模型的调试扩展
标识: |
BRF00084 |
发起人: |
Keil |
日期: |
2007年06月12日 |
简述: |
M2元模型的调试扩展 |
重要性: |
中等 |
描述: |
M2元模型的调试扩展,功能向下兼容到ORTI。 |
基本原理: |
调整ORTI,使之适合AUTOSAR |
使用案例: |
使所有ORTI功能与AUTOSAR接口的前提条件。ORTI规定了当前未被元模型覆盖的功能。 |
相关性: |
AUTOSAR元模型,BRF00083 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.28.4[BRF00085]访问PduR,以便调试
标识: |
BRF00085 |
发起人: |
Keil |
日期: |
2007年06月12日 |
简述: |
访问PduR,以便调试 |
重要性: |
高 |
描述: |
当前,所有的信息被PduR转发到Com或者Dcm.调试模块不能使用PduR-Com接口或者PduR-Dcm接口来发送或者接收调试信息。一个好的解决方案是:将一个附加通信模块”调试”添加到PduR上。 |
基本原理: |
将调试集成到通信堆栈中,以远程地访问调试目标。 |
使用案例: |
调试主机和调试目标之间的通信使用PduR来访问目标(另一个ECU)。 |
相关性: |
一个附加BSW模块”调试模块”存在,并且将使用此附加的接口。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.29 DLT概念
3.29.1[BRF00224]允许监控DEM,RTE和COM,以改善诊断
标识: |
BRF00224 |
发起人: |
BMW |
日期: |
2007年12月14日 |
简述: |
允许监控DEM,RTE和COM,以改善诊断. |
重要性: |
中等 |
描述: |
AUTOSAR应该标准化对BSW模块COM,DEM和RTE的监控,以及管理软件组件的活动以及它们与COM和DEM的交互作用。 当前,RTE允许此监控(通过追踪),但是应该为DEM和COM增加挂钩。 |
基本原理: |
在当前版本的AUTOSAR中,DCM和DEM使用诊断并实现了几个特征,以满足现有的诊断标准,如ISO14229或者ISO 15765.这些标准定义了ECU级别的诊断。它们假设功能不会被分散到几个ECU. 对于即将来临的、软件组件及其封闭交互作用的广泛使用来说,将一个ECU中的设置DTC的关系用于表明一个分布式特征的失效可能并不足以理解错误行为。基于功能的诊断正试着去覆盖此主题,但是现阶段该领域并没有标准可用。通过在DEM,COM和RTE中提供监控能力,不同类型的功能诊断可以被实现。 |
使用案例: |
当前,新的诊断概念(它们需要这些接口用于其工作)正在被考虑。 |
相关性: |
无 |
冲突: |
未知 |
支持材料: |
(当前)无 |
接收者: |
-- |
3.29.2[BRF00294]标准化的日志&追溯格式/协议
标识: |
BRF00294 |
发起人: |
BMW/Fraunhofer ESK |
日期: |
2008年01月30日 |
简述: |
从一个AUTOSAR系统报告的所有日志,追溯和错误数据应该有一个标准的格式。它应该使用一个标准的高水平发送协议以及一个数据存储格式。 |
重要性: |
高 |
描述: |
一个特定的二进制格式应该被定义,它满足了日志和追溯机制的所有要求。所以,与源,以及上下文(如时间戳,可运行状态的数量)有关的一些信息应该被发送,以满足与滤波和可追溯性有关的某些要求。发送的数据(有效负荷)也应该有一个标准的格式,从而能够以正确的方式理解它们。 |
基本原理: |
既然日志和追溯是验证可测试性和产品质量的一种重要机制,有必要标准化存储的和发送的数据。这对日志或者追溯数据的存档,对比和分析来说是很重要的。它也可以构造通用的工具来理解进来的数据。 |
使用案例: |
- 软件组件发送一个日志 - DLT将其转换成DLT数据包格式 -DLT通过一个接口发送数据包到一个数据存储客户(个人电脑) - 不同ECU的存储数据都会被客户理解 - 不同ECU的日志可以被结合,以理解分布式应用的行为之间的关系。 |
相关性: |
DLT |
冲突: |
|
支持材料: |
|
接收者: |
-- |
3.29.3[BRF00295]用于日志&追溯的DET追溯接口
标识: |
BRF00295 |
发起人: |
BMW/Fraunhofer ESK |
日期: |
2008年01月30日 |
简述: |
DET应该转发其追溯事件到DLT. |
重要性: |
中等 |
描述: |
在调试过程中,DET从BSW和软件组件的错误中接收追溯事件。如果一个DLT模块存在,这些事件应该被转发到DLT以收集日志和追溯结果。 |
基本原理: |
为了对所有的日志,追溯和错误信息有一个概述,并将它们设置到正确的上下文中,需要将所有的这些信息和事件列入到一个清单(上下文)中。使用一个以上的机制来向一个调试接口报告错误,日志和追溯结果也是不实际的。所以,所有的这些源应该被发送到DLT. |
使用案例: |
|
相关性: |
DET,DLT |
冲突: |
BRF00224包含同样的要求 |
支持材料: |
|
接收者: |
-- |
3.29.4 [BRF00296]日志&追溯所需要的RTE/VFB追溯接口
标识: |
BRF00296 |
发起人: |
BMW |
日期: |
2008年01月30日 |
简述: |
RTE应该提供一个接口用于调用DLT的RTE/VFB的追溯。在生产阶段,它也应能够追溯VFB。 |
重要性: |
中等 |
描述: |
此刻,RTE提供了追溯VFB的可能性。没有机制规定(RTE如何被配置)一个定义的BSW模块可以接收追溯调用。一个或者多个BSW模块应能够接收VFB追溯信息。 如果有可能的话,RTE应该提供一个机制来允许,禁止RTE接口组的运行时期间的追溯。RTE端口/接口应该由软件组件或者其它分组机制进行分组。 |
基本原理: |
在调试阶段,调试和DLT同时需要一个RTE追溯接口。在生产阶段,DLT也需要RTE追溯。 将来,越来越多的应用将被集成到一个ECU钟。结果,软件组件之间的通信将在本地被完成,而不会通过一条外部可追溯总线(如CAN或者FlexRay)。通过VFB追溯内部通信是很重要的。 在运行时期间,为了避免过大的CPU负载,追溯应该单独地分组,允许和禁止。 |
使用案例: |
|
相关性: |
RTE,调试,DLT |
冲突: |
BRF00224结合了几个要求 |
支持材料: |
-- |
接收者: |
-- |
3.29.5[BRF00297]日志&追溯需要的DEM追溯接口
标识: |
BRF00297 |
发起人: |
BMW |
日期: |
2008年01月30日 |
简述: |
DEM应该将进来的事件转发到DLT接口。 |
重要性: |
中等 |
描述: |
DEM应该转发错误事件到DLT. |
基本原理: |
为了对所有的日志,追溯错误信息有一个概述,并将它们设置到正确的上下文中(将错误事件报告给DEM),需要将所有的信息和事件包含到一个清单(上下文)中。这使得对报告的错误的分析更加有效,并给出了一个正确的前进顺序图(用于报告一个错误)。 |
使用案例: |
|
相关性: |
DLT,DEM |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.29.6[BRF00298]使用诊断服务的日志&追溯调试接口
标识: |
BRF00298 |
发起人: |
BMW |
日期: |
2008年01月30日 |
简述: |
DCM应该为DLT提供一个接口,以通过一个诊断服务传送一个日志和追溯数据。 |
重要性: |
高 |
描述: |
DCM应该为DLT提供一个接口,以通过诊断服务发送和接收数据。日志和追溯数据通过此服务被发送,并且DLT的控制请求被接收。 为此,DCM应该实现事件响应服务(详见UDS规范)。DCM应该为DLT提供一个接口,以发送数据和接收控制请求。 |
基本原理: |
日志&追溯需要一个接口来将日志&追溯数据发送到ECU外。DCM通过标准化的诊断来向ECU提供一个总线相关的访问。这在生产阶段是可用的,并提供一个安全的会话控制。 由于日志和追溯信息是由事件触发的,并且ECU上的存储受到限制,那么当它们发生时,这些信息必须被发送。 |
使用案例: |
|
相关性: |
DCM,DLT |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.29.7[BRF00300]软件组件的标准化的、接口/服务日志&追溯
标识: |
BRF00300 |
发起人: |
BMW |
日期: |
2008年01月30日 |
简述: |
AUTOSAR应该为软件组件的日志&追溯提供一个标准的服务 |
重要性: |
高 |
描述: |
日志和追溯是许多ECU需要的一个调试机制。一个日志&追溯服务提供一个机制从几个软件组件写日志&追溯条目到一个中心化的日志&追溯BSW模块。如果有必要并且通过一个测试接口和/或一个诊断服务向一个测试客户提供一个连接,那么日志&追溯服务将会缓冲日志&追溯条目。每一个日志&追溯条目将提供属性(如时间戳,优先权,上下文,日志信息标识和可选的参数)。 |
基本原理: |
每一个Tier1使用其自己的机制来提供一个这种日志接口,使用一些内部或者外部调试接口。不同的ECU也会有不同的日志内容格式。在测试几个ECU时,需要使用许多不同的工具和解析器来得到日志以外的正确信息。有标准日志内容的一个标准诊断日志元件应能够帮助减少测试步骤并允许新的自动测试机制。一个标准的日志内容和协议能够减少工具的数量。 |
使用案例: |
|
相关性: |
DLT |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.30 与存储器有关的概念
3.30.1[BRF00022]对NVRAM存储器访问概念的修改
标识: |
BRF00022 |
发起人: |
AUTOSAR PL |
日期: |
2007年05月03日 |
简述: |
对NVRAM存储器访问概念的修改 |
重要性: |
低 |
描述: |
修改NVRAM访问概念,从基于模块的访问修改为基于数据元素的访问。 |
基本原理: |
当前,软件组件的确会按模块来访问NVRAM,但是,模块的数据元素设置不应该由软件组件预先决定。 这样,在使用小的模块时将不会浪费NVRAM空间。 |
使用案例: |
允许整合者将NVRAM数据分区到模块中。允许移植到有小的NVRAM区间的其它软件平台。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.31 构造系统丰富概念
3.31.1 [BRF00057]存储器映射概念
标识: |
BRF00057 |
发起人: |
Bosch |
日期: |
2007年10月09日 |
简述: |
存储器映射概念 |
重要性: |
高 |
描述: |
AUTOSAR应该定义一个基于AUTOSAR阶段I中的软件组件_存储器_映射的一个存储器映射机制。 此机制应该支持XML中的BSW模块和软件组件所使用的抽象存储器阶段,以及基于这些描述的存储器映射标题文件的生成。 |
基本原理: |
对于当前定义的机制,需要付出极大的努力用于集成软件组件和BSW模块。定义一个可以简化整合的存储器映射概念。 |
使用案例: |
易于从不同的制定人整合存储器映射文件。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.31.2[BRF00077]软件组件的存储器映射
标识: |
BRF00077 |
发起人: |
Continental |
日期: |
2007年06月14日 |
简述: |
软件组件的存储器映射 |
重要性: |
低 |
描述: |
由于R2.1的存储器映射仅被用于BSW,由于使用过的前缀 |
基本原理: |
易于集成应用软件 |
使用案例: |
软件组件的集成被交付为常用构造环境中的源代码。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.32支持窗口化的看门狗概念
3.32.1[BRF00159]支持窗口化的看门狗
标识: |
BRF00159 |
发起人: |
Valeo |
日期: |
2007年05月03日 |
简述: |
支持窗口化的看门狗 |
重要性: |
低 |
描述: |
AUTOSAR BSW应该支持硬件窗口看门狗,并在正确的时间同步更新硬件看门狗。一个窗口看门狗是一个更受限制的看门狗,它需要在一个明确定义的时间跨度内被触发(不应该在t1之前触发,也不应该在t2之后被触发)。 |
基本原理: |
窗口看门狗在嵌入式系统中是很知名的,art-AUTOSAR的状态应该支持它。 窗口看门狗比正常的看门狗更受限制,从而形成更安全的系统。 |
使用案例: |
检测一个任务已经丢失其同步的情况。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.33 闹钟概念
3.33.1[BRF00196]闹钟
标识: |
BRF00196 |
发起人: |
GM |
日期: |
2007年12月06日 |
简述: |
闹钟 |
重要性: |
高 |
描述: |
提供一个实时闹钟,用于唤醒的目的。软件组件可以设置或者取消唤醒闹钟。 软件组件必须要能够请求一个控制器离开睡眠状态(当它们将来需要功能时)。将来是指将来的几个小时到几周的时间。软件组件必须要能够设置并取消相对于或者绝对于当前时间的闹钟,并请求当前时间。当两个闹钟服务被请求时,最早到期的闹钟将享有优先权。 在运行模式过程中,除了唤醒功能之外,此特征也会提供定时功能。 |
基本原理: |
允许基于时间的内部唤醒请求离开一个睡眠状态(而不是仅有外部输入/输出事件)。 |
使用案例: |
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.34 在BSW结构中允许CDD
3.34.1 [BRF00225]在BSW结构中允许CDD
标识: |
BRF00225 |
发起人: |
MBTech |
日期: |
2007年01月10日 |
简述: |
在BSW结构中允许CDD |
重要性: |
高 |
描述: |
在BSW结构中允许CDD的实现。 AUTOSAR堆栈允许CDD与所有的BSW模块接口。但是,BSW规范通常不允许这么做。它必须 固定的,或者CCD访问BSW接口的能力必须受到限制,否则不可能写CDD. |
基本原理: |
允许按照AUTOSAR结构中的定义来写CDD. |
使用案例: |
不需要给出CDD的使用案例。但是,为了陈述某些当前的问题:
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.35 库的概念
3.35.1 [BRF00165]集成HIS加密功能
标识: |
BRF00165 |
发起人: |
BMW |
日期: |
2007年10月18日 |
简述: |
集成HIS加密功能 |
重要性: |
低 |
描述: |
有必要(并且已经计划)向BSW和软件组件提供某些加密功能。 |
基本原理: |
对于复杂的和/或者受到保护的功能的实现来说,加密功能是必需的。为了避免顾客特定的调整,需要将方便的功能集成到BSW中。 |
使用案例: |
-它应该不可能改变某些未授权的特殊参数 -它应该不可能激活某些未授权的特殊功能 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.35.2[BRF00311]标准的AUTOSAR库
标识: |
BRF00311 |
发起人: |
Continental |
日期: |
2008年02月01日 |
简述: |
标准的AUTOSAR库 |
重要性: |
高 |
描述: |
AUTOSAR联盟应该为常用的功能定义库:定点数,插值法,浮点,位处理,特殊的功能。仅有接口应该被定义。这些功能可以被用到BSW模块中或者适用的软件组件中,作为纯粹的功能调用。 |
基本原理: |
避免增加非标准的库 |
使用案例: |
-- |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
发起人: |
-- |
3.36 引导加载器交互作用概念
3.36.1[BRF00034]引导加载器的交互作用
标识: |
BRF00034 |
发起人: |
Freescale |
日期: |
2007年09月06日 |
简述: |
引导加载器的交互作用 |
重要性: |
中等 |
描述: |
在运行时期间,AUTOSAR软件可以转换到引导加载器模式,以允许更新闪存中的软件或者参数。在完成之后,引导加载器可以提升AUTOSAR软件的性能。如果AUTOSAR软件和引导加载器可以交换某些数据,那么它可能会很有帮助(复位原因,更新计数器,发生的更新,等等)。对于出现在某些SBC中的、自由运行的窗口化看门狗来说,它甚至有必要同步AUTOSAR软件和引导加载器中的看门狗驱动。 |
基本原理: |
有必要交换AUTOSAR软件和引导加载器之间的数据,并同步AUTOSAR软件和引导加载器中的看门狗驱动。 |
使用案例: |
从AUTOSAR软件转换到请求的引导加载器,用于软件或参数更新或者诊断。 |
相关性: |
-- |
冲突: |
与唤醒概念,MCU以及WDG驱动存在潜在的冲突 |
支持材料: |
-- |
接收者: |
-- |
3.36.2[BRF00262]DCM应该支持Ecu复位服务
标识: |
BRF00262 |
发起人: |
Vector Informatik |
日期: |
2007年01月28日 |
简述: |
DCM应该支持EcuReset服务 |
重要性: |
高 |
描述: |
在出现外部测试器请求时,DCM必须进行强制关闭。 有不同的方式可以这么做: 1 硬复位
3 软复位
ASR3.0中已经支持硬复位。对WdM的一个附加要求是:在遇到一个非预期的复位时不会报告一个错误。 键关闭/开启复位:可以由计划的汽车管理器处理(通过模拟一个点火键关闭/开启)。 软复位:应该由Ecu管理器处理,在关闭被执行之后并且所有的可运行状态被停止之后,NvM必须写Nv数据。在写Nv数据之后并且在ECU被复位之前,一个正响应必须被发送。 允许/禁止快速的电源关闭:ECU必须进入一个恒定功耗模式。可以通过进入睡眠模式而达到,而不需要ECU的任何后运行。 |
基本原理: |
通常,大规模生产需要部分此诊断服务。 |
使用案例: |
ECU复位,以达到一个预定的ECU状态。 ECU复位,以装载新的校准值。 强行立即关闭到睡眠模式,以测量汽车的功耗,并检测松动连接。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.36.3[BRF00263]DCM应该内部支持跳转到快速引导加载器
标识: |
BRF00263 |
发起人: |
Vector Informatik |
日期: |
2007年01月28日 |
简述: |
DCM应该内部支持跳转到快速引导加载器 |
重要性: |
高 |
描述: |
通常,诊断通信协议(例如,UDS)被用于跳转到引导加载器。根据HIS,引导加载器和DCM之间的数据交换必须在Nv存储器中被完成。 因此,内部堆栈应该被扩展,以支持至少两个不同的配置。一个子集用于引导加载器,至少一个子集用于应用。 在闪存扇区转换过程中,引导加载器(子集配置)也可以写数据到闪存中,FEE/FA必须复制未知的模块。 这就意味着FEE/EA必须检测一个’更新的’配置,未使用的或者不兼容的模块可以被删除到自由内存中。 |
基本原理: |
不被当前的AUTOSAR结构支持。 |
使用案例: |
跳转到引导加载器所必需的。 |
相关性: |
规范的WP维护 |
冲突: |
FEE/EA不支持多个配置或者访问两个应用中的相同数据。 |
支持材料: |
-- |
接收者: |
-- |
3.37 多核结构概念
3.37.1[BRF00199]实时能力&可预测性
标识: |
BRF00199 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
实时能力&可预测性 |
重要性: |
高 |
描述: |
每一个多核操作系统解决方案应该符合汽车实时系统的要求。此外,实时行为应该是可以预测的。AUTOSAR单核OS概念的实时能力和可预测性应该被用作参考。 |
基本原理: |
实时能力和可预测性是汽车领域中的单核系统的技术水平。AUTOSAR OS和OSEK就是其中的两个例子。 |
使用案例: |
-- |
相关性: |
OS规范 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.2[BRF00200]不被锁死的相互排斥
标识: |
BRF00200 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
不被锁死的相互排斥 |
重要性: |
高 |
描述: |
每一个多核操作系统解决方案应该支持核之间的一个不被锁死的相互排斥机制。 |
基本原理: |
在一个多核系统中,需要一个相互排斥机制来同步不同的核。此相互排斥机制应该是不被锁死的。 |
使用案例: |
-- |
相关性: |
OS规范 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.3[BRF00204]多核系统,其中一个核作为智能的外围设备
标识: |
BRF00204 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
多核系统,其中一个核作为智能的外围设备 |
重要性: |
高 |
描述: |
它应能将核作为智能的外围设备。例如,在没有操作系统的情况下,它应能够使用输入/输出来执行特定的任务。 |
基本原理: |
这提供了减小”主”核上的中断负载的可能性,以及使之不受高频输入/输出任务的影响。 |
使用案例: |
-- |
相关性: |
可能与OS规范有关,可能在MCAL驱动上。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.4[BRF00205]多核系统,每个核有一个OS
标识: |
BRF00205 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
多核系统,每个核一个OS |
重要性: |
高 |
描述: |
它应能够将多个相邻耦合的CPU核用于功能独立的子系统(每个核有一个子系统),每一个核都有独立的操作系统。 |
基本原理: |
为多个相邻耦合的CPU核(用于功能独立的子系统,每个核有一个OS)提供使用方法。 |
使用案例: |
将独立的应用集成到一个多核系统上。 |
相关性: |
OS规范,可能在MCAL驱动上 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.5[BRF00206]多核系统,一个操作系统控制所有的核
标识: |
BRF00206 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
多核系统,一个操作系统控制所有的核 |
重要性: |
高 |
描述: |
它应能够使用一个常用的操作系统来管理多个相邻耦合的CPU核。 |
基本原理: |
使用一个常用的操作系统来提供一个解决方案的原因是:
|
使用案例: |
应用(例如,信号处理应用),需要通过算法并行化来达到高性能的计算 带常用BSW的多核系统 随着给定的核的数量而增长的应用可以轻易地使用较高数量的核(向上的可扩展性)。 为多核设计的应用可以被减少(例如,用于低花费系统)为较少的(例如,一个核)核(向下的可扩展性)。 将引擎控制系统转移到多核中,将以前独立的应用集成到一个多核ECU中 |
相关性: |
OS规范,可能在MCAL驱动上 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.6[BRF00207]防锁死
标识: |
BRF00207 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
防锁死 |
重要性: |
高 |
描述: |
所有操作系统机制的使用不应该导致锁死。 BRF00206的子特征。 |
基本原理: |
避免应用产生锁死现象。确保操作系统的实时能力和可预测性。 |
使用案例: |
资源共享机制应该保证应用不被锁死。 |
相关性: |
OS规范 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.7[BRF00208]避免不受约束的堵塞
标识: |
BRF00208 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
避免不受约束的堵塞 |
重要性: |
高 |
描述: |
所有操作系统机制的使用不应导致不受约束的堵塞。 |
基本原理: |
确保操作系统的实时能力和可预测性。 |
使用案例: |
-- |
相关性: |
OS规范,BRF00206的子特征。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
|
3.37.8[BRF00209]一个核上的单核系统的服务兼容性
标识: |
BRF00209 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
一个核上的单核系统的服务兼容性 |
重要性: |
高 |
描述: |
在引发并操作同一个核上的目标(例如,一个任务)时,操作系统服务的行为(例如,任务激活)应该与单核系统一致。 |
基本原理: |
在本地使用时,单核系统的已知操作系统服务应该与一个多核系统的操作系统服务一致(例如,没有交叉的核边界)。 |
使用案例: |
-- |
相关性: |
OS规范,BRF00206的子特征。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.9[BRF00210]横跨多个核的单核系统的高度服务兼容性
标识: |
BRF00210 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
横跨多个核的单核系统的高度服务兼容性 |
重要性: |
高 |
描述: |
|
基本原理: |
与单核系统(单核系统允许不同的行为)相比,操作系统服务的用户不应该面对不同的行为。 |
使用案例: |
-- |
相关性: |
OS规范,BRF00206的子特征 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.10[BRF00211]对核的任务进行静态设置
标识: |
BRF00211 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
对核的任务进行静态设置 |
重要性: |
高 |
描述: |
它应能向核静态地设置任务。 |
基本原理: |
系统整合者应能够配置系统,这样一个给定的任务总是能够在他/她选择的一个核上被执行。 |
使用案例: |
-- |
相关性: |
OS规范,BRF00206的子特征。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
发起人: |
-- |
3.37.11[BRF00212]横跨多个核的任务的激活
|
标识: |
BRF00212 |
|
|
|
发起人: |
Bosch |
|
|
|
日期: |
2007年09月26日 |
|
|
|
简述: |
横跨多个核的任务的激活 |
|
|
|
重要性: |
高 |
|
|
|
描述: |
在一个给定的核上运行的软件应能激活另一个核上的任务。这应该适用于激活任务的所有可能性,例如,不仅仅是使用ActivateTask()API调用来激活任务。 |
|
|
|
基本原理: |
在没有对所有任务激励(尤其是在BSW组件中)进行再次编程的情况下,不同项目(例如,低花费的高端汽车)中的核之间的任务应该可以进行离线再布置。此外,系统整合者应能将子功能设置到一个能够自由地处理电源的核中。 |
|
|
|
使用案例: |
第三方软件组件被交付为目标代码。 |
|
|
|
相关性: |
OS规范,BRF00206的子特征 |
|
|
|
冲突: |
-- |
|
|
|
支持材料: |
-- |
|
|
|
接收者: |
-- |
|
|
|
3.37.12[BRF00214]横跨多个核的资源 |
|
||
标识: |
BRF00214 |
|||
发起人: |
Bosch |
|||
日期: |
2007年09月26日 |
|||
简述: |
横跨多个核的资源 |
|||
重要性: |
高 |
|||
描述: |
资源的单核机制应该被扩展为一个多核版本,允许在不同的核上的任务之间形成一个关键的部分。此扩展的资源机制应该恰当地处理锁死并避免优先权倒置。如果通过扩展现有的机制不能达到需要的行为,那么一个可替代的相互排斥机制应该被提供。 |
|||
基本原理: |
在没有引入一个新的相互排斥机制的情况下,不同项目中(例如,低花费的高端汽车)的核之间的任务应该可以进行离线再布置。此外,系统整合者应能将子功能设置到一个能够自由地处理电源的核中。但是,不清楚需要的行为是否能够被有效地塑造,因此,至少需要一个跨核工作的相互排斥机制。 |
|||
使用案例: |
不同核上的任务之间的共用外围设备。不同核上的任务之间的共用数据。 |
|||
相关性: |
OS规范,BRF00206的子特征。 |
|||
冲突: |
-- |
|||
支持材料: |
-- |
|||
接收者: |
-- |
3.37.13[BRF00215]静态地设置中断到核
标识: |
BRF00215 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
静态地设置中断到核 |
重要性: |
高 |
描述: |
它应能静态地设置IRQs到核。 |
基本原理: |
如果IRQs未被静态地设置到核,那么系统行为是不可预测的。 |
使用案例: |
-- |
相关性: |
OS规范,可能是MCAL驱动,BRF00206的子特征。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.14[BRF00216]允许/禁止中断API调用在本地工作
标识: |
BRF00216 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
允许/禁止中断API调用在本地工作 |
重要性: |
高 |
描述: |
所有禁止和允许中断API调用只应该在本地核上有效。 |
基本原理: |
总体来讲,禁止中断不足以在一个多核系统上构建一个关键部分。此外,要使禁止的/允许的中断API调用在所有的核上有效将会导致系统产生不必要的性能降级。 |
使用案例: |
-- |
相关性: |
OS规范,BRF00206的子特征。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.15[BRF00217]事件机制应该跨核工作
标识: |
BRF00217 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
事件机制应该跨核工作 |
重要性: |
高 |
描述: |
它应能够发送一个事件到一个不同的核上的一个任务。单核事件机制应该被扩展为一个多核版本,这样,它才可能将事件从一个核发送到另一个核。 |
基本原理: |
在没有引入一个新的事件机制的情况下,不同项目(例如,低花费的高端汽车)中的核之间的任务应该可以进行离线再布置。 |
使用案例: |
-- |
相关性: |
OS规范,BRF00206的子特征。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.16[BRF00218]核数量的离线配置能力
标识: |
BRF00218 |
发起人: |
Bosch |
日期: |
2007年09月26日 |
简述: |
核数量的离线配置能力 |
重要性: |
高 |
描述: |
操作系统管理的核的数量应该是可以配置的。 |
基本原理: |
操作系统规范不应该被仅限于某个数量的核。 |
使用案例: |
将操作系统用于有不同的核数量的项目中。 |
相关性: |
OS规范,BRF00206的子特征。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.17[BRF00220]初始化和启动
标识: |
BRF00220 |
发起人: |
Vector |
日期: |
2007年11月29日 |
简述: |
定义的操作系统的初始化/启动 |
重要性: |
高 |
描述: |
操作系统的初始化/启动必须被同步 |
基本原理: |
如果核运行独立的Oss,那么它必须顶呀启动。例如,如果一个操作系统还没有完成StartOS,那么任务不能在多个核之间被执行。要么需要StartOS的一个同步,要么一个特殊的错误处理必须被定义。 |
使用案例: |
所有多核系统的启动 |
相关性: |
OS规范 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.18[BRF00221]核之间受控制的数据交换
标识: |
BRF00221 |
发起人: |
Vector |
日期: |
2007年11月29日 |
简述: |
核之间受控制的数据交换 |
重要性: |
高 |
描述: |
用于交换核之间的数据的一个受控制的机制必须保证数据连续性与高速缓存生效/无效策略无关 |
基本原理: |
在软件中,有高速缓存失效的微控制器必须被考虑。在软件中,高速缓存失效使之必须定义一个数据交换API(它将包括高速缓存失效的情况)。API可能必须被做成原子级别的。 |
使用案例: |
通过共用的内存进行每一次数据交换 |
相关性: |
OS规范 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.19[BRF00222]常见的配置
标识: |
BRF00222 |
发起人: |
Vector |
日期: |
2007年11月29日 |
简述: |
横跨几个核的常见配置 |
重要性: |
高 |
描述: |
如果目标将在几个核之间被寻址,那么必须生成分隔的目标标识。 |
基本原理: |
例如,如果任务在多个核之间被激活,那么标识在这些核之间必须是独一无二的。这将导致一个常用的配置,并影响快速的/编程策略。 |
使用案例: |
激活多个核之间的任务或者设置事件 |
相关性: |
OS规范 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.37.20[BRF00223]核之间的定时器同步
标识: |
BRF00223 |
发起人: |
Vector |
日期: |
2007年11月29日 |
简述: |
核之间的定时器同步 |
重要性: |
中 |
描述: |
为了运行同步的应用,需要一个同步的时间基准。 |
基本原理: |
必须及时地同步跨核的任务。这可以通过集中方式来完成。例如,通过同步计数器或者通过使用共用的硬件定时器,闹钟可以激活跨核的任务。一个标准的方式必须被定义。 |
使用案例: |
及时同步的应用 |
相关性: |
OS规范 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.38 错误处理概念
3.38.1[BRF00156]错误处理规范
标识: |
BRF00156 |
发起人: |
Renault |
日期: |
2007年09月07日 |
简述: |
错误处理规范 |
重要性: |
中等 |
描述: |
描述BSW的异常行为(对错误的检测,对错误的响应,对其它BSW处理错误条件的要求,等等)。
此概念的产品是
|
基本原理: |
AUTOSAR规范定义了BSW模块的功能行为。它允许从一个BSW模块(或者一个BSW模块群)的一个实现转换到另一个实现。 但是,异常行为的某些细节(检测,响应,等等)将被丢失,以允许导致相同错误拓扑,错误行为的模块进行交换。 |
使用案例: |
-在 -BSW的交换,它对错误条件会产生相同的行为 |
相关性: |
来自WP功能安全和过程的支持 来自各种BSW中的专家的支持 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.38.2[BRF00193]标准错误清单
标识: |
BRF00193 |
发起人: |
AUTOSAR WP错误处理 |
日期: |
2007年11月12日 |
简述: |
标准错误清单 |
重要性: |
中等 |
描述: |
列出应该由AUTOSAR结构进行处理的现有错误和新的错误。(特殊的实现错误仍然被允许;错误检测将取决于硬件) 当这些错误中的其中一个被检测到时,描述/定义AUTOSAR结构的行为。 |
基本原理: |
|
使用案例: |
处理不同(但相似)的错误时的不一致性。
|
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.38.3[BRF00275]分区的错误处理能力
标识: |
BRF00275 |
发起人: |
AUTOSAR WP错误处理 |
日期: |
2008年01月31日 |
简述: |
增加分区的错误处理能力(BSW级别以及应用级别),例如,问题请求操作系统结束和/或重启一个分区。 |
重要性: |
高 |
描述: |
错误恢复有时会请求软件组件的重启,以移除错误状态或者关闭有故障的软件组件。当前,这只可以在ECU级别被完成(ECU复位)。为了允许BSW级别和应用级别的软件组件的结束和重启,需要获得对操纵系统级别服务的访问权,以执行软件组件的结束和重启。由于软件组件被包含在分区中作为错误包含区域,操作应该建立在分区的基础之上。 |
基本原理: |
当前,对一个失效软件组件的默认恢复动作是重启ECU(例如,通过一个看门狗定时器)。对于某些应用来说,这可能是太过粗糙的,期望重启单独的软件组件或者软件组件组。既然一个”应用”可以由几个(可能是分散的软件)软件组件组成,恢复变得与应用有关,它必须由以上的RTE进行控制。 为了停止错误传播,软件组件可以被放置到分区中,之后,这些分区将作为错误包含区域。这些分区将经历错误处理机制,包括存储器和定时保护。如果一个错误被检测到,分区可以在错误传播到分区以外之前被结束或者重启。分区允许对那些可以被同时结束/重启的软件组件进行逻辑分组。 此外,应用级别的错误处理通常是应用特定的,也可以是OEM特定的(不同的策略可以被使用)。为了实现不同的策略,它可以实现一个特定的”错误处理管理器”(BSW级别的或者应用级别的),用于管理汽车级别的监控应用并实现错误处理策略。此类监控可以从本地ECU上的看门狗,DEM等上收集错误信息,甚至是从其它ECU上获得信息,并使用它们来执行恰当的错误恢复动作。为了能够以分区的结束和/或重启的方式来执行错误处理,需要操作系统级别的支持。 可以想象对此访问的限制。例如,它只能访问某些处理应用/系统监控的特殊类型(“享有特权的”)的软件组件(如一个配置问题)。 |
使用案例: |
|
相关性: |
“定时决定论”概念是否可用将取决于此特征(强制地结束一个软件组件)。 此特征取决于分区的引入。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.39 SRS核测试
3.39.1[BRF00185]测试模式
标识: |
BRF00185 |
发起人: |
AUTOSAR WP微控制器抽象 |
日期: |
2007年12月05日 |
简述: |
测试模式 |
重要性: |
高 |
描述: |
测试模块(例如,随机存取存储器测试,闪存测试,核测试…)应该提供前台模式和背景模式:
|
基本原理: |
提供一个灵活的测试方式。 |
使用案例: |
例如,在启动时,使用前台模式来执行一个测试,在正常操作过程中,使用背景模式来执行一个测试。 在前台模式下,通过RTE或者复杂的设备驱动(取决于总体的ECU安全概念),测试可用于外部设备(安全微控制器)。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.40 SRS闪存测试
3.40.1[BRF00186]测试结果处理
标识: |
BRF00186 |
发起人: |
AUTOSAR WP微控制器抽象 |
日期: |
2007年12月05日 |
简述: |
测试结果处理 |
重要性: |
高 |
描述: |
对于测试结果处理来说,下列的概念应该被使用:
|
基本原理: |
支持一个调用程序,它可以是一个外部微控制器,包含一个”黄金的参考值”。 |
使用案例: |
使用一个外部安全微控制器,它包含参考值,因此能够验证测试的正确性。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.41 软件组件E2E通信保护概念
3.41.1[BRF00114]软件组件的端对端的通信保护
标识: |
BRF00114 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
软件组件的端对端的通信保护 |
重要性: |
高 |
描述: |
在此概念(特征)内,我们定义了对RTE和配置的扩展,以支持远程ECU上的、软件组件之间的端对端的安全通信。端对端的通信保护是不同工业(包括汽车)中的大量安全相关系统的技术水平。 当前,某些现有的网络堆栈为安全协议(例如,校验和)提供一小部分机制。但是,这些机制的目的是可用性和容错性,而不是安全(FlexRay是一个例外)。 从逻辑上讲,概念在VFB和软件组件之间创建了一个层次。这可以通过下列方式来实现: 1/安全协议库-验证通信(例如,一条信息的一个CRC是否是正确的或者是否是准时的)并被RTE或者软件组件调用的一系列无状态库功能。 2/引入其它可配置的属性(字段),用于由安全协议库所使用的软件组件端口(例如,端口地址)。 端口属性保持通信的状态信息,而无状态库功能执行检查。 由于有这些扩展,任何ECU间的通信都可以被用于发送安全相关的数据。安全协议将工作在AUTOSAR支持的任何网络/总线上(包括CAN,LIN,SPI和FlexRay)。 取决于:(1)一个被使用网络的可靠性和类型,(2)被发送数据的大小和危急程度,(3)应用的容错性;需要被恰当地配置的协议。配置加入了对使用的机制和机制强度的选择(例如,CRC8和CRC16)。这将由整合者进行选择。 此外,屈居于:(1)通信模型(客户-服务器与发送者-接收者),(2)通信的多样性(1:n与1:1及n:1);某些机制会或者不会被提供(例如,在1:n的发送器-接收器通信中没有目的地地址)。 与任何其它概念都没有相关性。特别地,我们不会依靠”通信堆栈”概念。 |
基本原理: |
1/检测并容忍RTE,通信软件和其它BWM,以及通信硬件中的故障。 |
使用案例: |
软件组件位于遥控ECU上,交换安全相关的数据。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.42 存储器分区概念
3.42.1[BRF00115]被分组到单独的用户模式存储器分区内的软件组件
标识: |
BRF00115 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
被分组到单独的用户模式存储器分区内的软件组件 |
重要性: |
高 |
描述: |
此特征定义了单独的用户模式存储器分区中运行的软件组件的分组所必须的操作系统和RTE功能的扩展。最重要的AUTOSAR扩展是操作系统之间的应用通信(横跨存储器分区的界限)。将对配置和错误处理进行进一步(更细)的扩展。BSW的分区不在概念/特征的范围内 – 仅有软件组件被覆盖。 通过这些扩展,它将能够设置保护界限,抑制某些类型的硬件和软件故障的传播。当一个ECU上有几个软件组件,以及当软件组件有不同的ASIL或者当它们源于不同的组织时,这将变得特别有趣。这对软件组件的调试和测试也是有用的。存储器分区通过限制对存储器和存储器映射之硬件的访问权而提供保护。存储器分区意味着在不同存储器区域(分区)中的操作系统应用受到保护,彼此不会发生冲突。特别地,在一个分区内执行的代码不能以一种不受控制的方式修改另一个分区的内存,即使是通过间接的方式。此外,存储器分区允许保护只读的存储器片段,以及保护存储器映射的硬件。管理者/用户模式通过限制对CPU的访问权而提供保护。 当前,操作系统使得一个分区的概念与相关的操作系统应用的概念一致。换句话说,每一个操作系统应用有其自身的存储器分区,有单独的堆栈,数据和代码。操作系统假设(需要)一个MPU用于提供存储器保护(通过分段)。未规定对MMU的支持(通过分页)。 但是,操作系统应用之间并没有通信机制。操作系统本身并不会为操作系统应用之间提供通信-相反,操作系统会明确地将分区之间的通信(例如,用于转移受保护存储区域之间的数据的基本技术)委托给RTE.RTE假定其角色,但是并不会提供这些机制。 因此,操纵系统之间的应用通信(例如,同一个ECU内的不同操作系统应用之间的通信)是主要的丢失功能。可能的RTE通信模式扩展将由此概念进行概述,这样它们不仅工作在操作系统应用内,ECU之间,也工作在操作系统应用之间。 |
基本原理: |
这避免了下列的失效模式被传播:
|
使用案例: |
概念/特征允许一个ECU上的软件组件进行如下组合: 不同ASIL的软件组件 来自不同商家的软件组件 在调试/测试中的软件组件 |
相关性: |
AUTOSAR操作系统中有一个明确的硬件相关性。”被分组到单独的用户模式存储器分区中的软件组件”仅可能在为内存保护提供硬件支持的处理器上(MPU, MMU)。 用于应用级别的软件组件管理(停止,启动,重启)的另一个特征[BRF00275]对此特征是非常有用的,但是不会被严格要求。 |
冲突: |
-- |
支持材料: |
-- |
接收者: |
-- |
3.43程序流程监控概念
3.43.1[BRF00131]逻辑程序流程监控
标识: |
BRF00131 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
逻辑程序流程监控 |
重要性: |
高 |
描述: |
通过扩展看门狗管理器的方式来添加软件组件和BSW模块的逻辑程序流程 监控。 在应用的正确执行过程中,一个程序的执行顺序的逻辑监控能够检测到有效 程序顺序中的分歧。如果一个或者多个程序指令被按照一个不正确的顺序被 处理或者根本未被处理,那么一个不正确的程序流程将会产生。 为了减少由程序顺序的逻辑监控导致的间接费用,在AUTOSAR中,它可以 将被管理实体(SE)的定义限制为安全相关的任务/可运行状态。至少这些 必须被监控,但是非安全相关的任务也可以被监控。 |
基本原理: |
这允许检测下列的故障:
在程序顺序的执行过程中的故障可以导致数据破坏,处理冲突,或者失效静态违反。 ISO26262,IEC61508,MISRA中要求/推荐/建议逻辑程序流程监控。 |
使用案例: |
安全相关的软件模块:
|
相关性: |
其它概念取决于此特征(例如,“多控制器支持”,“防御行为”,“时间决定 论”)。 |
冲突: |
|
支持材料: |
需要将检查点正确地放置到程序中。 这是由开发者或者一个应用级别的生产者完成的(它们都不在AUTOSAR的 范围之内)。 程序流程的逻辑监控可以被定义成各种方式(它们同时会用到硬件和软件资 源)。此概念推荐了一种同时使用软件和硬件的方法:大多数工作是由看门 狗管理器BSW-M来完成的,部分错误处理工作(ECU复位)是由一个硬件 看门狗来完成的。 |
接收者: |
-- |
3.44 BSWM防御行为概念
3.44.1[BRF00128]保护BSW,使之不能在未授权的情况下被使用
标识: |
BRF00128 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年11月02日 |
简述: |
保护BSW,使之不能在未授权的情况下被使用 |
重要性: |
高 |
描述: |
AUTOSAR应该保护BSWs,使之不能在未授权的情况下被软件组件和其它BSWMs使用。 |
基本原理: |
为了避免软件组件破坏或者干扰安全相关软件组件的AUTOSAR服务调用,也为了避免非安全相关的BSWMs破坏或者干扰BSW的使用(由安全相关的BSWMs使用)。 |
使用案例: |
仅有被选中的软件模块才被允许请求ECU的关闭。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意事项: 1/AUTOSAR规定了对BSWMs的访问限制。例如,中断程序仅有有限的权力来调用操作系统服务; 2/在配置时间设置的访问规则必须在运行时被执行。 |
接收者: |
-- |
3.44.2[BRF00129]对数据的保护
标识: |
BRF00129 |
发起人: |
安全团队 |
日期: |
2006年11月02日 |
简述: |
对数据的保护 |
重要性: |
高 |
描述: |
AUTOSAR应该保护其在随机存取存储器和非易失性存储器中的安全相关数据不受破坏。 |
基本原理: |
允许AUTOSAR以一个安全的方式来处理其内部数据。 |
使用案例: |
容错数据保护的请求者,比如: 1/ECU状态管理器:ECU状态数据; 2/DEM,FIM:检测到的当前错误。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
1/此要求对AUTOSAR结构有影响:此要求应该定义校验和服务应该如何被BSWMs使用(而不只是自由地询问数据保护的可用服务); 2/同时适用于随机存取存储器和非易失性存储器:有校验和的数据保护也可以被用于随机存取存储器中的数据(用于未被存储到非易失性存储器中的、长期的、安全相关的数据)。 |
接收者: |
-- |
3.45 通信堆栈概念
3.45.1[BRF00110]对通信的保护
标识: |
BRF00110 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
对通信的保护 |
重要性: |
高 |
描述: |
AUTOSAR应该保护安全相关的数据通信,使之不被破坏。 |
基本原理: |
检测相同ECU或者不同ECU上的软件组件之间的交换数据何时被破坏。 |
使用案例: |
两个ECU上的两个软件组件交换安全相关的数据 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意事项: 1/这可以由一个安全协议来实现,它将保护发送者/接收者地址(或者信息标识),通过有时间监控的校验和控制信息和数据; 2/所有当前被支持的通信堆栈(CAN,LIN和FlexRay)应该有一个通信保护; 3/所有当前被支持的内部ECU通信堆栈(如SPI)应该有一个通信保护。 |
接收者: |
-- |
3.45.2[BRF00111]数据顺序控制
标识: |
BRF00111 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
数据流程控制 |
重要性: |
高 |
描述: |
AUTOSAR应该为数据顺序控制提供机制。 |
基本原理: |
接收器必须要能够检查一个信号是否按照顺序被接收。 |
使用案例: |
一个分布式的、安全相关的传动控制系统通过CAN接收一个扭矩请求信号 (其顺序计数器的值大于预期)。此错误被理解为几条信息已经丢失并且传动系统中可能有一个不连续的状态。这将通过对传动系统的再次初始化进行处理。这可以通过对传动系统的再次初始化而完成。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意事项: 1/这可以通过添加顺序数到信号或者帧而达到(如PDU计数器)。 2/如果接收器检测到一个错误顺序,它可以决定丢弃信息还是再次初始化通信。 |
发起人: |
-- |
3.45.3[BRF00112]路径完整性
标识: |
BRF00112 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
路径完整性 |
重要性: |
高 |
描述: |
AUTOSAR应该提供一个机制来检测软件组件之间的错误路径并支持信号的正确路径。 |
基本原理: |
检测一个信号何时来自一个非预期的软件组件发送器,或者收到的信号何时正在提供不想要的信息。 |
使用案例: |
如果接收器(例如,COM BSWM)收到一条不想要的信息,那么它会报告一个错误并丢弃它。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意: 1/识别可以被使用的路径,信息标识,或者发送器和接收器标识。 |
接收人: |
-- |
3.54.4[BRF00113]通信看门狗
标识: |
BRF00113 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
通信看门狗 |
重要性: |
高 |
描述: |
AUTOSAR应该提供一个机制来检测是否周期信号在定义的时间间隔(暂停时间)内未被交换。 |
基本原理: |
这可以被用于检测通信系统中的错误(信息的丢失)。 暂停时间通常被用于决定一个通信系统是否正在工作或者一个单独的ECU是否正在进行通信。从一个特殊的ECU接收信息失败意味着信息或者功能的丢失,因此,可能导致软件组件或者系统操作中产生一个变化。 |
使用案例: |
如果一个防滑系统的操作使用了一个太过时的传感器值,那么它的动作可能会发生错误。可以使用一个通信看门狗来监控持续更新的传感器值。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意事项: 1/这可以通过在接收器一侧设置一个定时器而完成。如果一条信息来得太迟,那么,即使它是正确的(正确的顺序编号,校验和等等),它也应该被视为一个错误(之后发生什么事情就是另外一个问题了:到发送器的一个再次发送请求或者错误报告,等等)。 |
接收人: |
-- |
3.45.5[BRF00241]多通信链接
标识: |
BRF00241 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
多通信链接 |
重要性: |
高 |
描述: |
AUTOSAR应该支持多通信链接。 |
基本原理: |
容忍其中一个通道上的故障。 |
使用案例: |
1/如果在一个给定的系统中有多余的通信硬件(如两条独立的CAN总线,或者一条CAN总线和一条FlexRay总线),那么,为了提供容错性,可以在每一个通道上使用一个安全协议(例如,有校验和的受保护数据,地址标识,计数器和暂停时间)。此时,接收器可以执行1oo2投票(例如,使用两条正确接收的信息中的一条); 2/如果一个通道完全失效,那么第二个通道可以被用于减少的功能通信。 |
相关性: |
BRF00206 |
冲突: |
-- |
支持材料: |
注意事项: 1/假设在配置时间,它可以静态地配置那些被使用的通信链接。 |
接收人: |
-- |
3.45.6[BRF00242]网络通信监控
标识: |
BRF00242 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
网络通信监控 |
重要性: |
高 |
描述: |
AUTOSAR应该监控网络通信。 |
基本原理: |
检测网络通信的高级别问题,增加系统的故障检测能力。 |
使用案例: |
1/如果一个网络通道被检测出问题,那么第二个通道可以被使用。 2/如果一个网络通道被检测出问题,那么对错误的反应可以是软件组件功能的再配置(例如,巡航控制关闭或者降级)。 |
相关性: |
-- |
冲突: |
-- |
支持材料: |
注意事项: 1/可能的监控机制:
|
接收人: |
-- |
3.46 电气油门监控适用性概念
3.46.1[BRF00301]使一个AUTOSAR应用与电气油门监控概念相兼容的能力
标识: |
BRF00301 |
发起人: |
AUTOSAR安全团队 |
日期: |
2008年01月25日 |
简述: |
使一个AUTOSAR应用与电气油门监控概念相兼容的能力 |
重要性: |
高 |
描述: |
一个应该必须要能够遵守安全概念(已知为电气油门监控概念)并使用AUTOSAR标准。 注意:电气油门监控概念是由AKEGAS工作组进行标准化的,它并不是AUTOSAR标准的一部分。在此,它被用作一个典型的项目,因为它是一个标准化的汽车安全概念。 此特征要求AUTOSAR标准必须要能够使电气油门监控概念可以被使用。 |
基本原理: |
一个完整的分析已经被完成;结果是一系列要求,它覆盖了AUTOSAR安全团队的电气油门专家提出的两个主要假设。 |
使用案例: |
电气油门监控概念是一个标准的汽车安全概念。 |
冲突: |
-- |
支持材料: |
标准的电气油门监控概念,用于汽油和柴油引擎的引擎管理系统,V2.0,2004年04月29日 |
接收人: |
-- |
3.46.2[BRF00248]输入/输出数据和输入/输出硬件的测试和监控
标识: |
BRF00248 |
发起人: |
AUTOSAR安全团队 |
日期: |
2006年02月27日 |
简述: |
输入/输出数据和输入/输出硬件的测试和监控 |
重要性: |
高 |
描述: |
AUTOSAR应该将机制用于输入/输出硬件元素以及用输入/输出硬件元素接收/发送的安全相关值的测试和监控。 |
基本原理: |
检测测得的传感器数据或者输出激励器数据中的错误,以及检测输入/输出硬件中的失效。 |
使用案例: |
-- |
冲突: |
-- |
支持材料: |
-- |
接收人: |
-- |
发起人: |
-- |
3.46.3[BRF00251]对SPI总线的优先访问权
|
标识: |
BRF00251 |
|
|
|
发起人: |
AUTOSAR安全团队 |
|
|
|
日期: |
2007年11月23日 |
|
|
|
简述: |
对SPI总线的优先访问权 |
|
|
|
重要性: |
|
|
|
|
描述: |
对SPI总线的专有访问权/优先访问权应该被授予在主控制器和通过SPI总线进行连接的一个监控单元之间执行定时关键监控协议的软件模块。这对一个AUTOSAR软件组件中的这些软件模块以及一个复杂设备驱动中的这些模块都是可能的。 |
|
|
|
基本原理: |
我们期望有系统能够执行监控协议(例如,标准的电气油门监控概念中所描述的协议)以及其它通信(通过一条SPI总线)。其它通信预计将被AUTOSAR组件或者BSW模块通过标准的AUTOSAR接口进行驱动。监控协议应该根据需要(优先权)来执行,否则,一个可用性处罚将被强制执行。 注意:电气油门监控概念是由AKEGAS工作组进行标准化的,它并不是AUTOSAR标准的一部分。在此,它被用作一个典型的项目,因为它是一个标准化的汽车安全概念。 此特征要求AUTOSAR标准必须要能够使电气油门监控概念可以被使用。 |
|
|
|
使用案例: |
在一条SPI总线上执行一个监控协议以及其它通信。 |
|
|
|
冲突: |
-- |
|
|
|
支持材料: |
标准的电气油门监控概念,用于汽油和柴油引擎的引擎管理系统,V2.0,2004年04月29日 |
|
|
|
接收人: |
-- |
|
|
|
3.46.4[BRF00243]通信保护,防止数据损坏和丢失 |
|
||
标识: |
BRF00243 |
|||
发起人: |
AUTOSAR安全团队 |
|||
日期: |
2007年11月23日 |
|||
简述: |
通信保护,防止数据损坏和丢失 |
|||
重要性: |
高 |
|||
描述: |
如果应用负责检测,AUTOSAR BSW必须提供一个机制来发送通信保护,以防 止应用的数据损坏或者丢失(端对端的保护协议)。 如果复杂的设备驱动负责检测,那么AUTOSAR BSW必须提供一个机制来发 送通信保护,以防止复杂设备驱动的数据损坏或者丢失。 |
|||
基本原理: |
如果基本软件负责发送或者接收安全数据,那么AUTOSAR BSW必须提供此 类机制。 |
|||
使用案例: |
适用于传递安全相关数据的总线系统。 |
|||
冲突: |
-- |
|||
支持材料: |
-- |
|||
接收人: |
-- |
|||
3.47 与配置有关的特征 |
3.47.1[BRF00042]将XML(而不是OIL)用于操作系统的配置
标识: |
BRF00042 |
发起人: |
AUTOSAR WP软件结构和操作系统 |
日期: |
2007年05月03日 |
简述: |
将XML(而不是OIL)用于操作系统的配置 |
重要性: |
高 |
描述: |
当前,AUTOSAR操作系统将OSEK/VDX的OIL格式用于配置。只将一种格式用于配置将是更好的。 |
基本原理: |
许多人抱怨操作系统正在使用一个不同的格式,这也意味着工具必须处理XML和OIL语言。现在也存在一些bugzilla漏洞,只有当操作系统使用XML时,这些漏洞才能被解决。 |
使用案例: |
一个AUTOSAR ECU的配置 |
相关性: |
-- |
冲突: |
如果AUTOSAR可以将(操作系统)XML配置返回给OSEK/VDX组织,那么它将获得益处。我们必须决定是放弃OIL还是将它作为第二个配置选项。我个人更喜欢放弃OIL支持。 |
支持材料: |
-- |
接收者: |
-- |