全部学习汇总:GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!
继续学习AUTOSAR的文档,看一下《AUTOSAR_RS_SoftwareComponentTemplate》,这个应该开始涉及到应用软件设计了,估计会有一些RTE相关的内容。

1引言
1.1本文档的范围
本文档收集了对软件组件模板(SWC-T)的需求。
软件组件模板规范[1]将满足本文档中收集的需求。该文档实现了此处所述的大部分需求。
略过一众套话类的内容,看看实质部分。

2需求
本章描述了推动定义软件组件模板规范[1]工作的所有需求。需求可追溯到主要需求[3]和AUTOSAR功能[4]。

2.1类别:AUTOSAR主要需求
本节根据主要需求[3]中定义的相关需求重新定义需求。

2.1.1支持ECU通讯
AUTOSAR应支持具有高可靠性的ECU间和ECU内部通信机制

AUTOSAR应为ECU内部和ECU间通信提供开放和标准化的软件接口

2.1.2应用软件和基础软件模块的接口
AUTOSAR应提供完整的应用软件接口和基础软件模块

2.1.3应用软件的抽象性和独立性
AUTOSAR应从硬件提供应用软件的抽象

AUTOSAR应提供独立于车载通信技术的应用软件

AUTOSAR应提供应用软件与操作系统的独立性

2.1.4功能接口视图
AUTOSAR应提供整个系统的功能接口视图

2.1.5软件保护/解锁机制
AUTOSAR应通过基础设施中的适当服务为软件提供保护/解锁机制

2.1.6保护软件组件免受恶意软件组件的攻击
AUTOSAR应提供保护软件组件免受恶意软件组件攻击的方法

2.1.7组合性
AUTOSAR应提供实现组合性的方法

2.1.8运行期间用于生产和服务目的诊断
AUTOSAR应在运行时提供诊断手段,用于生产和服务目的

2.1.9分层设计方法
AUTOSAR应支持分层设计方法

2.1.10软件组件之间的关系
SW组件之间关系的定义是详尽的和正式的

2.1.11防止非法访问
保护软件组件免遭非法访问

2.1.12车辆多样性管理
AUTOSAR支持车辆多样性管理

2.1.13命名约定
软件组件模板应提供为公共符号定义命名约定的能力
软件组件模板应提供为公共符号定义命名约定的能力。这尤其包括发布文档中使用的需求ID、模块缩写、元数据和配置符号。
避免规范中的歧义和名称冲突。向规范的读者提供元数据的一致统一表示。
允许自动处理规范元素。
软件组件模板没有定义特定的命名约定。这种命名约定实际上是在AUTOSARAISpecification[2]中定义的。

2.2类别:AUTOSAR功能定义需求
本节定义了功能定义[5]中第3.2章中用例的需求。引用的文档在AUTOSAR4.0版中已过时,但它存在于以前的版本中。
2.2.1自顶向下的分层设计
AUTOSAR应支持自顶向下的分层设计

2.2.2原子软件组件的接口
应支持原子软件组件的接口

2.2.3CompositionTypes的自下而上设计
支持CompositionTypes自下而上的设计

2.2.4通讯规范
应支持通信规范

2.2.5与基础软件的交互
应考虑与基础软件的交互

2.2.6传感器执行器组件
应支持设计传感器执行器组件

2.2.7RunnableEntities之间通信的数据一致性
应支持RunnableEntities之间通信的数据一致性

2.2.8物理单位
应支持物理单位的定义

注释
应该支持注释的定义
感觉这一份文档像是看了一堆跟踪矩阵,内容比较零碎,而且偏方法也架构。本身的设计人员经验丰富了其实基本都会考虑这些。这次的小结到此暂停,后面针对SWC的部分专门再梳理一下。
最后
以上就是醉熏大碗最近收集整理的关于773_AUTOSAR_RS_SoftwareComponentTemplate1_总体需求以及特征定义的全部内容,更多相关773_AUTOSAR_RS_SoftwareComponentTemplate1_总体需求以及特征定义内容请搜索靠谱客的其他文章。
发表评论 取消回复