本文描述了一个非常简单的AADL项目的构建,以及一个示例项目的分析过程。本文主要记录了OSATE工具环境的一些基本操作,适用于刚刚了解OSATE之后,对于整个工具环境无从下手的小白。
因为基于OSATE环境的AADL项目的构建和分析的详细示例较少,而我又有这方面的需要。正当我手足无措之时,无意中发现OSATE的用户帮助文档中有关于构建并分析项目的详细过程,因此就写了这篇文章做简要记录。这篇文章的内容主要基于帮助文档,文档中很多细节都被我略过,如果有需要的话自行阅读OSATE的帮助文档以获取详细信息(帮助文档的相关信息本文第三章有详细描述)。
AADL即体系结构分析和设计语言(Architecture Analysis and Design Language,AADL)。因传统的制造后测试型系统设计方法,在构建当今的嵌入式、软件依赖性系统十分费时费力且成本高。所以,便有了AADL这一模型基软件系统工程框架。AADL 可以通过建模,对诸如性能、可信性、系统安全和数据完整性一类的关键性实时因素,进行简练而严格的分析,并能够在用户工程环境下集成额外建立的客户分析/规范技术,开发完全统一的体系结构模型,从而使得用户能够更容易地构建满足要求的可靠系统。
OSATE (Open Source AADL Tool Environment),即开源 AADL 工具环境,它主要包括三大功能:建模功能、代码生成功能、分析功能。此开源的AADL工具环境官方文档如下。
Welcome to OSATE — OSATE 2.13.0 documentation
本次的AADL项目示例就是以OSATE为基本的开发环境进行的。OSATE本身基于 Eclipse框架 构建,其下载与安装可以参考上述链接的 install 部分。
本文的操作流程主要基于OSATE帮助文档。帮助文档可以在Help -> help Contents中找到。
打开帮助文档如下:
帮助文档主要包括以下八大模块的内容:
内容 | 内容翻译 | 简介 |
---|---|---|
Workbench User Guide | 工作台用户指南 | Eclipse 平台概述。 |
ALISA User Guide | ALISA 用户指南 | 架构主导的增量系统保障(Architecture-led Incremental System Assurance ,ALISA)用户指南。这是一个增量生命周期保障工作台,适用于高保障软件依赖系统。它利用模型中的架构抽象来管理跨系统架构多层的需求,并根据这些需求验证系统实现。该工作台补充了以架构为中心的虚拟系统集成工作台的功能,用于开发此类系统。 |
EGit Documentation | EGit 文档 | Git 版本控制参考。 |
Error Model Annex Documentation | 错误模型附件文档 | 对安全关键系统进行功能危害评估(FHA)、故障影响分析(类似 FMEA)和故障树分析(FTA)模型 V2(EMV2),以及 OSATE 的分析功能参考。 |
OSATE API Reference | OSATE API 参考 | OSATE 应用程序接口参考。 |
OSATE Core Documentation | OSATE 核心文档 | 介绍了OSATE 的基本功能,以及如何使用 AADL 模型。 |
OSATE Graphical Editor Documentation | OSATE 图形编辑器文档 | 图形编辑器的基本功能简介,以及图形编辑器的使用简介。 |
Scripting User Guide | 脚本用户指南 | EASE 提供脚本支持。允许使用各种语言的脚本与 IDE 交互。 JavaScript (Rhino) JavaScript (Nashorn) Jython Python via Py4J Ruby Groovy |
点击 “File -> New -> AADL Project”
输入项目名,确定项目的存储位置
可以看到,在AADL 导航器视图中已经成功创建该项目。
注:
Plugin_Contributions 包含了OSATE 中默认可用的所有 AADL 属性集。其子文件夹 Predeclared_Property_Sets 是由 AADL 标准文档指定并由核心 OSATE 环境提供的。其余的为在其他文档中指定并通过 OSATE 插件提供的。
并且,通过在包规范中提供适当的 with 子句,工作区中的任何项目都可以使用 Plugin_Contribution 中的属性集。(不需要将这些内容复制到项目中就能够使用)。
选择刚刚创建的项目后,点击“File -> New -> AADL Package”。
为包命名。
点击完成,即可看到:
编辑并保存,示例代码如下所示。
- package my_aadl_model
- public
- process MyProcess
- end MyProcess;
-
- system MySystem
- end MySystem;
-
- system implementation MySystem.i
- subcomponents
- sub1: process MyProcess;
- end MySystem.i;
-
- end my_aadl_model;
大多数分析都是在系统的实例模型(instance models)上执行的。实例模型代表了系统的完整嵌套架构。通常,实例模型将从系统实现分类器创建。但 OSATE 允许从除子程序(subprogram)和子程序组(subprogram group)之外的 所有实现分类器 创建实例模型。
可以通过 以下 3种 方式创建实例模型:
在outline视图中选择一个或多个组件分类器,右键选择实例化(Instantiate)。只要没有任何分类器是子程序,该命令就会在上下文菜单中处于活动状态。
在视图中选择一个或多个组件分类器,右键菜单中选择实例化(Instantiate)。分类器可以来自不同的项目,只要没有任何分类器是子程序,该命令就会在上下文菜单中处于活动状态。
首先在大纲视图或 AADL 导航器视图中选中一个或多个组件分类器(分类器可以来自不同的项目,但不能是子程序),然后选择 OSATE -> Instantiate 。
可以使用3.1-3.4所示的任何一种方法进行实例化,这里我们使用第一种方式来完成刚刚编写的示例系统的实力模型创建。
在右侧的 Outline视图中选择 System MySystem.i 然后点击右键菜单中的 Instantiate。
点击 ok。
一般来说,实例模型被创建并放置在名为instances的目录中,该目录与包含根组件分类器的.aadl文件位于同一目录中。如果该目录尚不存在,则创建该目录。仅当状态为“正常”时才会创建该文件。刚刚生成的模型 my_aadl_model_MySystem_i_Instance.aaxl2 如下图所示:
在获得系统模型后,可以使用 OSATE 模型对模型进行分析,以确认设计是否满足预期标准。这里以系统的端到端流延迟分析作为演示(延迟分析插件随 OSATE 预装)。本节采用一个示例项目作为模型分析的操作演示。
延迟分析由OSATE延迟分析插件提供。延迟分析是在包括端到端流的AADL模型上执行的,它会计算最小和最大延迟,并会考虑到各种延迟影响因素。它基于分配给不同架构元素的延迟预算以及架构设计发展过程中的设计信息来实现这一点。AADL模型的范围可以从具有不同分解级别的延迟预算的功能架构,到具有映射到支持分区的硬件平台的执行速率的任务和通信架构。分析的保真度由AADL模型中的详细细节决定。
延迟分析的结果以csv、xls等表格格式呈现。延迟分析可以通过一些首选项设置进行参数化,这些首选项设置允许用户探索架构变化,而无需更改模型中的细节,例如系统是否表现为异步系统或同步系统。
该项目是GitHub上的一个示例项目,以下为项目的链接。GitHub - osate/examples: Examples and case-study that use OSATE
本次使用的是示例中的 “latency-case-study”项目。可以直接从GitHub或以下链接下载。
https://download.csdn.net/download/qq_44667259/88366885 (免费下载)
为了便于项目的管理,这里可以将latency-case-study项目复制到自己设置的工作目录中。
点击File -> Open Projects from File System,
设置项目文件的路径,点击 Finish 完成。
可以看到,项目已被打开。
在 integration.aadl 中找到 System Implementation integration.software_integrated 。单击右键并选择实例化,如下图所示。
点击 OK 。
可以看到,实例模型已经被生成,该文件被放置到 instances 目录下。
左键单击选中 integration_integration_software_integrated_Instance.aaxl2 ,然后点击 Analyses -> Timing -> Check Flow Latency 。
调用上述延迟分析时,会显示一个配置对话框,如下图所示。这用于选择影响延迟计算方式的设置,允许用户在不改变模型的情况下沿着不同的维度进行研究
配置对话框各个选项的含义如下:
- System type:
异步系统(AS):组件时间不同步,即调度可能存在时移。
同步系统(SS):组件时间同步,即跨系统的定期调度是一致的。
- Partition output policy:
用于反映因分区系统中不同的内部通信策略而造成的分区间通信延迟贡献。
分区结束(PE):假设在任务发送数据的分区末尾有可用的分区间连接。如果分区 A 中的任务向分区 B 中的任务发送数据,则如果分区 B 在分区 A 之后执行,后者将在同一主帧中接收数据。
主帧延迟 (MF):假设分区间连接在主帧末尾刷新/实现。如果分区 A 中的任务向分区 B 中的任务发送数据,则无论分区 A 或分区 B 的执行顺序如何,只有在所有剩余分区完成后,新数据才会可用。
- For worst-case processing time use:
用户可以在 截止时间 和 最坏情况计算执行时间 之间选择作为最坏情况处理时间。对于最佳情况,我们始终使用计算执行时间。此设置仅在没有可用响应时间时才相关。
截止日期 (DL):截止日期表示假设任务是可安排的最坏情况下的完成时间。
最大计算执行时间 (ET):在不考虑资源调度的情况下考虑处理时间时,最大计算执行时间非常有用。
- For best-case queuing latency on incoming ports:
影响如何确定最佳情况排队延迟。对于最坏的情况,我们总是使用完整队列。
假设队列为空 (EQ):没有延迟,因为假设队列为空。
假设队列已满 (FQ):使用最小计算执行时间乘以队列大小来确定最佳情况排队时间。- Disable queuing latency in the results:
确定是否报告异步总线的最坏情况排队延迟。
禁用:最坏情况下的排队延迟始终报告为0。
启用:报告最坏情况的排队延迟。
此处可以自定义或按照默认选项进行。
延迟分析完成后,报告结果(采用三种不同的格式)将被放在 instances 文件夹的 reports 子文件夹下,同时,我们也可以看到输出的错误信息(端到端流 etef0 和 etef1 未能满足预期的延迟约束)。
对于 .csv 和 .xls等文件,可能无法直接在eclipse中打开,可以自行添加打开方式。在Window中选择 Preferences。
在General -> Editors -> File Associations 下,点击 Add。
输入 *.csv (先以csv文件演示)
选中刚刚添加的 *.csv ,然后点击关联编辑器的 Add
选择外部程序,浏览并选择指定的程序并点击OK。
将 *.xls 也按照上述方法添加,然后点击应用并关闭(此处我选择了WPS作为默认的关联编辑器)。
打开以下任意一个生成的报告即可。
文件打开后如下所示,可以看到etef0和etef1的端到端流延迟分析详情:
如有不当或错误之处,恳请您的指正,谢谢!!!