697_AUTOSAR_TR_Methodology_文档阅读23_E2E以及诊断提取

       全部学习汇总: https://github.com/GreyZhang/hack_autosar

       继续梳理《AUTOSAR_TR_Methodology》,感觉这个文档的一个大块快要看出一点眉目了。

       目的

       本活动提供了创建E2E保护用以保护 AUTOSAR 架构中的通信流的粗略概述。

       描述

       当需要在运行时保护与安全相关的数据交换以防止通信链路故障时,需要 E2E 保护机制。

       E2E保护

       AUTOSAR 中的端到端保护实现为由 RTE 调用的 E2E 转换器模块。 首先,序列转换器将数据序列化,然后RTE调用E2E 转换器来保护通信。 软件组件使用普通 RTE API 通过 RTE 进行通信。

       看起来,这个模块如果要做一个单独的应用还是麻烦的。因为功能本身是涉及到RTE的,至于这个序列转换器模块是在哪部分呢?也是E2E的一部分?

       E2E Transformer的配置和生成

       根据通用转换器方法,E2E 转换器可以在系统级别(ECU 间通信)进行配置。 E2E 转换器模块的生成是根据系统描述完成的。不需要ECU配置。

       那么,这个转换器模块是如何进入到配置工具中生效的呢?看着看着,怎么看到的全都是问题点?

       定义E2E 转换器技术任务

       需要定义 E2E 转换器技术任务来定义生成 E2E 转换器模块所需的所有信息,例如预定义的配置文件和状态机配置。

       工作流程

       图 2.58 显示了定义 E2E 转换器拓扑任务,该任务主要在活动通信定义中处理。

       先做一个临时小结:这个应该是SecOC所需要的一个必要模块,虽然描述不多但是还是让我获知了不少信息的。首先,实现这个功能的使用似乎RTE是一个必须的模块;其次,E2E转换器似乎还有另一个阶段的工作或者工具得去探索。

       诊断提取

       目的

       该用例使用诊断提取模板提供了诊断配置的粗略概述。 涉及的活动和可交付成果将在下一个 AUTOSAR 版本中根据该领域的经验进行改进?!!难道现在的版本中,这个还只是一个概念的阶段?

       描述

       AUTOSAR ECU 开发的分布式特性需要高度优化的信息梳理(感觉这个比较符合实际的动作)。尤其是诊断信息(即 DEM 和 DCM 配置)应仅由具有最佳知识的人员梳理,因此能够比一个普通的个人更好地承担责任。 ECU 配置不适合在 ECU 开发项目中的合作伙伴之间交换。

       因此,AUTOSAR 定义了代表诊断功能标准化交换格式的诊断提取模板。 诊断提取模板允许对诊断方面进行分散配置。 诊断提取模板的基本用途是在诊断开发过程中涉及的各方之间交换诊断数据,以允许配置 DCM 和 DEM 并提供相应应用程序接口的描述,以实现诊断服务和故障处理。在 AUTOSAR 方法论中,诊断提取物由可交付的诊断提取物及其子可交付物表示。

       感觉看的有些迷糊,但是大概的意思应该是以前的开发集中管理这部分信息会好一些,但是AUTOSAR通过模板的方式让分布式开发成了可能。

       诊断提取物的内容

       可交付的诊断提取包含所有相关的诊断方面。

              • 诊断服务(例如 IOControl、MemoryByAddress)

              • 诊断事件处理(例如事件、故障代码、条件)

              • 映射(服务映射、诊断映射等)

       诊断提取类别

       根据过程中的阶段,诊断提取可以有几个类别,表示为专门的可交付成果:

              • 诊断抽象系统描述:该可交付成果代表一个高级定义,可以作为创建具体诊断系统提取或诊断 ECU 提取的模板。。

              • 诊断系统提取:此可交付成果代表了多个 ECU 的诊断方面。

              • 诊断ECU 提取:此可交付成果代表单个ECU 的诊断方面。

       分布式配置

       交换的时间和频率以及这些交换文件中的每一个的内容在很大程度上取决于各个项目的设置和情况。诊断提取模板旨在支持诊断需求的分散和独立定义,这些定义可以在开发过程的后期链接在一起。

       在诊断提取模板中主要通过两种方式满足分散配置的方法:

              • 在多个物理文件中分离元素:诊断提取模板的大多数元素可以在多个物理文件中分离。 因此,这些元素的部分(例如某些属性)可以由例如 OEM 定义,而这些元素的其他部分可以由例如 ECU 供应商定义。

              • 自包含映射的使用:许多诊断要求是通过诊断元素之间的映射(例如,DTC 到 DemEvent 映射)建立的。 然而,“去中心化配置”方法要求这些映射几乎可以在 ECU 开发过程中的任何时间由任何相关公司各自的角色灵活定义。 因此,诊断提取模板定义了自包含的映射元素,这些元素引用了两个(或可能更多)诊断元素来定义映射。诊断提取模板的使用将受到下一个 AUTOSAR 版本中“角色和权限”概念的适当应用的限制。

       角色

       诊断提取用例的相关活动在逻辑上分为以下角色(见图 2.60):诊断请求者、软件开发者和诊断集成者。 显然,OEM 充当诊断请求者,ECU 供应商充当诊断集成者。 然而,在一些情况下(例如应用软件组件的内部开发),OEM 可以充当诊断集成商并执行收集和合并任务。

       开发诊断抽象系统描述活动

       诊断方面配置的基本工作流程可以从可选活动开发诊断抽象系统描述开始。 此活动在抽象级别定义诊断要求。 产生的诊断抽象系统描述可被后续活动用作诊断系统提取或诊断 ECU 提取的基础。

       诊断需求的开发

       在开发诊断需求活动中,诊断数据的请求者定义了一个或多个 ECU 的诊断接口。 可以执行以下任务:

              • 定义 DTC 的值

              • 定义 ECU 支持的 UDS 服务和子服务

              • 定义由应用程序开发人员实现的特定组合所需的所需事件

       在此活动期间,几个开发诊断需求 来自不同方的可能会被收集和合并。

       SW-C 开发上下文中的诊断信息

       在软件组件的开发过程中,诊断提取的目的基本上有两个:一方面,诊断系统提取可以作为软件开发人员的要求。 诊断请求者可以指定例如以下问题:

       • 必须由特定 SW-C 实现的特定DID读取内容的定义

       • 特定 SW-C 所需事件的定义

       另一方面,应用程序开发人员可以提供诊断信息作为诊断系统提取和/或使用服务需求的一部分,与 SW-C 相关。 SW-C 描述中的服务需求仍将与诊断系统提取物一起使用,以便注释与诊断系统提取物定义的进一步映射和处理相关的 SW-C 端口。

       在解决所有问题和冲突并合并输入后,将生成最终完整的诊断 ECU 提取物。 基于此交付物,生成相关基础软件模块的初始配置(活动 ECU 集成软件)。

       工作流程

      

       关于诊断部分,内容其实挺多,但是大部分真的是方法性的描述,或者规则性描述。有收获,但是收货不大,很好奇后面的版本中会升级成什么样子呢?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值