Files
autosar_standard_spec_v4.4/Tools/AUTOSAR_RS_InteractionWithBehavioralModels.md
T

9.8 KiB
Raw Blame History

与行为模型交互的需求

AUTOSAR CP Release 4.4.0

文档元信息

项目 内容
文档标题 Requirements on Interaction with Behavioral Models(与行为模型交互的需求)
文档所有者 AUTOSAR
文档责任方 AUTOSAR
文档标识号 102
文档状态 Final(最终版)
所属 AUTOSAR 标准 Classic Platform
所属标准版本 4.4.0

文档变更历史

日期 版本 变更人 变更描述
2018-10-31 4.4.0 AUTOSAR Release Management 将规范标记为已过时
2017-12-08 4.3.1 AUTOSAR Release Management 编辑性修改
2016-11-30 4.3.0 AUTOSAR Release Management 编辑性修改
2014-10-31 4.2.1 AUTOSAR Release Management 编辑性修改
2013-10-31 4.1.2 AUTOSAR Release Management 编辑性修改
2013-03-15 4.1.1 AUTOSAR Administration 为 4.1 版本最终确定
2010-02-02 3.1.4 AUTOSAR Administration 法律免责声明修订
2008-08-13 3.1.1 AUTOSAR Administration 法律免责声明修订
2007-12-21 3.0.1 AUTOSAR Administration 文档元信息扩展;小幅布局调整
2007-01-24 2.1.15 AUTOSAR Administration "用户建议"修订;添加"修订信息"
2006-11-28 2.1.1 AUTOSAR Administration 法律免责声明修订
2006-05-16 2.0 AUTOSAR Administration 初始发布

重要提示:本规范已过时(obsolete),将在后续版本中从标准中移除。


目录

  1. 关于本文档
  2. 需求

1 关于本文档

1.1 引言

本文档定义了对可交付成果"Specification of Interaction with Behavioral Models(与行为模型交互的规范)"的需求。

本规范已过时,将在后续版本中从标准中移除。

1.2 术语

在本节中,定义了贯穿本文档所使用的术语。这些定义在某种程度上特定于 AUTOSAR 的范围,特别是对于此可交付成果。然而,在可能的情况下考虑了这些术语的常见用法。

  • Authoring Tool(创作工具):是 AUTOSAR 工具,针对描述系统(软件组件、ECU 硬件、网络拓扑和系统约束描述)的任何形式的 AUTOSAR 模型进行操作。它被视为针对 AUTOSAR 描述的相应模板的设计输入工具。典型功能可能包括创建、检索、修改、验证和存储此类描述。创作工具可以提供特定于工具的语言或表示法用于设计输入,通常用作工具用户界面处的表达语言。这些语言可能与用于 AUTOSAR 标准描述格式的语言不同。例如,图形行为建模工具可用于使用行为建模语言编辑软件组件描述,并按照软件组件模板存储为 XML 文件。因此,作为创作工具更多是一种工具的特定角色,而不是工具本身的分类。

  • AUTOSAR ModelAUTOSAR 模型):是 AUTOSAR 元模型实例的任何类型表示的通用表达式。它可能是文件系统中的文件集、XML 流、数据库或某些运行软件使用的内存等。

  • AUTOSAR ToolsAUTOSAR 工具):是在 AUTOSAR 方法论中可能出现的软件工具,并支持 AUTOSAR 模型的解释、处理和/或创建。

  • AUTOSAR Authoring ToolsAUTOSAR 创作工具):是针对描述系统(软件组件、ECU 硬件、网络拓扑和系统约束描述)的任何形式的 AUTOSAR 模型进行操作的 AUTOSAR 工具。

  • Behavior(行为):以两种主要变体使用。一方面,行为用作 InternalBehavior 的缩写 —— 作为软件组件模板描述的一部分。另一方面,行为是常见的控制工程术语,用于识别控制设计随时间的功能输入/输出关系。在本文档中,术语 behavior(行为)及其组合(如 behavior models)应理解为此控制工程解释。为避免任何误解,将使用术语 functional behavior(功能行为)——与 InternalBehavior 相对。

  • Behavior ModelBM,行为模型):以功能行为建模语言表达的设计规范或模型。

  • Behavior Modeling LanguageBML,行为建模语言):主要用于捕获函数或系统的功能行为规范或设计的(通常是图形的)表示法。通常,功能行为建模语言被认为是可执行的,即其语义足够精确,可以通过仿真引擎执行功能行为模型。此外,其语义的精度允许将功能行为模型转换为某种编程语言(如 C 语言)的源代码。许多功能行为建模语言基于有限状态机或数据流语义。

  • Behavior Modeling ToolBMT,行为建模工具):用于以功能行为建模语言编辑功能行为模型。

  • Model Frame(模型框架):由结构构建块(通常称为子系统或模块)组成的用于功能行为模型的容器。模型框架是功能行为模型与其环境的契约,因此可以视为 AUTOSAR 引入的软件组件模板的对等物。

1.3 关于需求

每个需求都有其唯一标识符,以前缀 "RS_ATBM_" 开头(意为 Authoring Tool 的 REQuirement,创作工具的需求)。

1.3.1 结构

每个需求定义为一个表格。表格的结构如下:

字段 含义
Initiator(发起人) 发起工作包编号、公司等
Date(日期) 最后更改日期
Requirement(需求) 需求的标准文本
Description(描述) 需求的详细描述
Rationale(基本原理) 为什么这是必要的,其省略可能导致什么后果
Use Case(用例) 场景示例,使该需求成为必要或有用
Dependencies(依赖) 对依赖和被依赖需求的引用
Conflicts(冲突) 对冲突需求的引用
Supporting Material(支持材料) 指向其他文档的链接
Comment(评论) 附加说明

1.3.2 使用的约定

在需求中,使用以下特定语义(取自互联网工程任务组 IETF 的请求评论 RFC 2119):

本文档中的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 RFC 2119 中的描述进行解释。请注意,使用这些词的文档的需求级别会修改这些词的作用力。

  • MUST:该词,或 "REQUIRED" 或 "SHALL",意味着该定义是规范的绝对要求。

  • MUST NOT:该短语,或 "SHALL NOT",意味着该定义是规范的绝对禁止。

  • SHOULD:该词,或形容词 "RECOMMENDED",意味着在特定情况下可能存在有效理由忽略特定项目,但在选择不同路线之前必须充分理解并仔细权衡其全部含义。

  • SHOULD NOT:该短语,或 "NOT RECOMMENDED",意味着在特定情况下可能存在有效理由使特定行为可接受或甚至有用,但在实现使用此标签描述的任何行为之前,应充分理解其全部含义并仔细权衡案例。

  • MAY:该词,或形容词 "OPTIONAL",意味着项目是真正可选的。一个供应商可能选择包含该项目,因为特定市场需要它或因为供应商认为它增强了产品,而另一个供应商可能省略同一项目。不包含特定选项的实现 MUST 准备好与包含该选项的另一个实现进行互操作,尽管功能可能有所降低。同样,包含特定选项的实现 MUST 准备好与不包含该选项的另一个实现进行互操作(当然,除了该选项提供的功能之外)。

1.3.3 指导原则

应引用现有规范(以单一需求的形式)。与这些规范的差异被指定为附加需求。

所有需求应具有以下属性:

  • Redundancy(冗余性) 需求不应在一个需求内或其他需求中重复。

  • Clearness(清晰性) 所有需求应仅允许一种解释的可能性。使用的、不在术语表中的技术术语必须定义。

  • Atomicity(原子性) 每个需求应仅包含一个需求。如果需求无法拆分为更多需求,则该需求是原子的。

  • Testability(可测试性) 需求应可通过分析、评审或测试进行测试。

  • Traceability(可追溯性) 需求的来源和状态应始终可见。

2 需求

本章提供了相关需求的定义。

2.1 [RS_ATBM_00015] 定义交互

字段 内容
ID RS_ATBM_00015
Initiator(发起人) WP Authoring Tools
Date(日期) 04.02.2005
Requirement(需求) 定义交互
Description(描述) 必须提供行为模型与 AUTOSAR 描述之间交互的概念。
Rationale(基本原理) 为了支持模型驱动方法,必须定义软件组件的 AUTOSAR 接口描述与在 Simulink、TargetLink、ASCET-SD 等行为建模工具中建模的行为模型之间的耦合。
Use Case(用例) 使用行为建模工具根据软件组件的接口描述对软件组件的行为进行建模。获取现有行为模型并根据行为模型的结构创建软件组件。
Dependencies(依赖) --
Conflicts(冲突) --
Supporting Material(支持材料) --
Comment(评论) --
Contributes to(贡献于) --

翻译说明

  • 本文档为 AUTOSAR 经典平台 4.4.0 版本的"与行为模型交互的需求"规范(RS 文档)。
  • 该规范已被标记为过时(obsolete),将在后续版本中移除。
  • 仅包含一个核心需求 RS_ATBM_00015。
  • 保留所有需求 ID(如 RS_ATBM_00015)。
  • 保留工具名(Simulink、TargetLink、ASCET-SD)。
  • 保留 ⌈AUTOSAR confidential⌋ 方框符。
  • 翻译策略:完整翻译(仅 9 页)。