使用AADL的模型基工程——SAE体系结构分析和设计语言入门(txt+pdf+epub+mobi电子书下载)

作者：(英)费勒(Feiler,PH),(英)格鲁茨(Gluch,DP),光电控制技术重点实验室

出版社：航空工业出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

使用AADL的模型基工程——SAE体系结构分析和设计语言入门试读：

随着嵌入式系统变得使软件日益密集且依赖于民用计算硬件，系统集成已经成为开发现代应用系统面临的主要工程挑战。包括早期和整个开发寿命期的系统体系结构模型的系统性分析的模型基工程实践，能够为满足设计目标的集成系统从本质上提供更大的置信度。

在寿命期的早期阶段，模型基工程采取预计性分析的形式，例如，通过敏感度分析提出不确定性。随着系统体系结构的细化，模型将包括更细的粒度，并且这种模型的分析也能对设计质量和能力提供更详尽的了解。如果开发了系统组件，并对其实现进行了测量，则通过对预计值与实际测量结果进行比较和替换，可使该细化过程日益呈现出验证的特性。这种实践的关键是：在使用其软件运行时体系结构，其计算平台及其物理环境接口，以及将软件植入硬件的模型的条件下，分析系统的操作特性。渐渐地，源自这些分析的认识将有助于确保更有效的、小偏差系统（Less Error Prone System）的开发和系统集成的过程，并为提交能满足用户预期的系统提供更大的保障。

体系结构分析和设计语言（AADL）为将要延伸到整个系统设计、集成和保障阶段的模型基工程分析实践，提供了严密的、可扩展的基础。利用AADL，能够将系统描绘成各不相同的软件组件和硬件组件以及它们的交互。依据其形式化的基础，可以利用AADL可扩展性结构，对诸如性能、可信性、信息安全和数据完整性等的关键实时计算因子进行初步、严密的分析，能够将额外建立的自定义分析和规范性技术，集成到一个工程环境之中，以帮助开发和分析一个统一的系统体系结构模型。第1部分　模型基工程与AADL

工程师建立模型的范围从晚宴餐巾纸背后的神秘图案到常常通过全刻度物理模拟扩充的正式的数学表达式。总而言之，这些表达式不仅获得并提供对于设计的深入理解，而且还能利用正式的模型在产品可工作之前进行产品的关键特性分析和预计。随着技术的发展，模型的精确性和它们的作用已得到扩展，以至于模型在现代应用系统工程中已经不可或缺。例如，波音777 “是100%利用三维实体建模技术设计的第一种波音飞机”，并且“是波音制造的第一种100%的数字设计和预组装飞机”。

AADL设计为软件系统工程化提供建模和分析能力。这些模型是由软件、硬件和物理系统组件、它们的交互以及这些要素的属性组成的系统体系结构模型。用于建模系统体系结构的语言概念已经很好地定义了语义，这些语义能使对来自同一个体系结构模型起源的不同关键系统要素进行分析。此外，借助AADL的可扩展性结构，自主性分析和规范技术能够结合核心AADL能力，为体系结构建模和分析建立一个完整的工程环境。

当我们的重点放在体系结构建模和分析上时， AADL支持应用特定运行时系统的生成，并根据经验证的AADL模型自动构建完整的系统。这些能力能够包括在一个包括要求分析、体系结构设计和详细设计，以及验证和代码生成的体系结构中心开发环境之中。

第1部分中，我们在模型基软件系统工程环境范围之内，提供了将AADL应用于系统体系结构设计和分析中的指南和典型案例。一开始，介绍了模型基工程和AADL的综述。在第2章和第3章，讨论了使用AADL的基本技术，并提供将其用于简单控制应用的建模和分析的示例。在第4章，提供了将许多AADL能力用于体系结构建模与分析的附加细节。第1章　模型基软件系统工程

模型基工程（MBE）一词指某些工程实践中，在涵盖概念、开发、部署、工作和维修的整个产品寿命期内，模型是重要且必不可少的“宝贝”。进一步说，这一短语用于软件工程，以强调它作为工程原理的成熟性，而且在建模技术中开发先进计算系统时这一短语已经变得不可或缺。在软件工程范围内， MBE常以各种不同的名称出现，包括模型驱动体系结构（MDA）、模型驱动开发（MDD）、模型基开发（MBD）和模型中心开发（MCD）。体系结构描述是IEEE标准（ 《系统和软件工程— — —体系结构描述》 （IEE.42010））的关键要素。本章将介绍作为体系结构中心模型基软件系统工程技术基础的AADL，并且讨论它与其他软件工程实践和技术的关系。1.1　MBE和软件系统工程

抽象和封装是管理复杂软件的关键原理。在面向对象的设计的分类/方法概念中，以及编程和建模语言的模块/软件包（Package）概念中能够找到这些原理。软件包概念聚焦于通过限制它们的可视性和使用，构建软件模型、设计和人工编程，以便提高软件的可修改性（Modifiability）。

体系结构语言引进了用于构建系统体系结构的组件的概念。为此， Simulink适用于构建控制系统， SysML适用于构建物理系统， UML适用于构建概念性体系结构，而AADL适用于构建嵌入式系统的体系结构。

因为软件要求用硬件来执行，用于计算系统的有效的软件MBE实践，不仅必须考虑应用软件的静态体系结构，还要规定运行时体系结构的工作动态，及其在计算机平台上的部署（例如，要在特定处理器上执行的软件长度取多少才合适）。对于嵌入式应用系统案例来说尤其如此。在这些系统中，软件是一个应用平台（例如，飞机、汽车、航天飞机）以及它与操作环境的接口的一个主要的部分。在这种环境中，这些软件系统常常要控制其他系统的行为。例如，在碰撞时，软件会控制汽车安全气囊的膨胀。1.1.1　MBE用于嵌入式实时系统

在本书中，我们使用MBE表示实时嵌入式软件密集型应用系统的模型基工程。这些系统是在一个提供监视、控制或其他功能的操作环境范围内的计算系统。在这些应用系统中，性能、安全性和可信性是极其重要的因素（即极其重要的操作质量属性）。在汽车、航空电子、航空航天、医学、机器人和过程控制中的系统，均属于这一范畴。这些属性的示例包括：控制导弹的制导软件的反应时间，或者飞机中多余度飞行控制系统的故障概率。

图1－1说明了一个嵌入式软件系统体系结构的三种基本要素：

图1－1　嵌入式软件系统体系结构的要素

①涉及通信应用任务的应用运行时体系结构的表述；

②涉及由网络连接的处理器和存储器的计算机平台的表述；

③嵌入式应用及与其进行交互的物理系统和/或环境的表述。不仅是这三种基本要素，还有它们的交互均依赖于：

①在嵌入式应用软件与呈观察、测量、控制和命令状态的物理系统组件之间的逻辑连通性；

②在计算机系统与通过其传感器和作动器的物理系统之间的物理连通性；

③为利用供其执行的计算资源，将应用软件任务部署在计算机平台上。

嵌入式应用软件与物理系统组件之间的逻辑连接，使我们能够保证嵌入式应用做出与物理系统及其行为（包括故障和异常行为）有关的正确假设。计算机系统与物理系统之间的物理连接，使我们能够保证它们在物理上可以交互，并且能够满足诸如电源和重量之类的系统工程要求。软件在计算机硬件上的部署，使我们能够保证这些资源得以正确地共享，并且由系统工程师和控制工程师假定的性能和安全性准则也得到满足。

在这种计算机系统的背景中， MBE模型代表了软件和计算硬件资源，以及与受控物理系统的交互。受控系统的物理特性模型不必明确地包括在内。例如，在一个航电应用中，在飞控系统AADL模型中不必明确地表示出飞机机翼的气动特性，但是由于飞机正在受到这种系统的控制，与飞机部件（如飞机的副翼位置传感器）的交互以及物理感受和控制（如飞机的扰流板作动器、飞机方向舵特性）所需的、明确的硬件模型和特性，要出现在一个飞机的控制系统的AADL综合模型之中。1.1.2　可分析的模型和MBE

通过开展有意义的评估并论究模型的特性，以及它们所代表的系统的特性，可分析的模型提供了预计和设计保障的基础。模型特性在开发过程中规定且重点放在诸如可修改性和维修性上，而系统特性则规定诸如性能、安全性和可靠性一类的工作质量属性。这些模型的范围涵盖从具有最少语法和语义规则（能够仔细检查符合性和正确性）的图形表示（Notation），到以定量描述为基础的、缜密而详细的文本表示（Representation），从而能够轻易地实现精确的模拟和范围广泛的自动化分析。

例如，考虑一个简单的方块图，包括图中使用的用图例定义的图形表示。如果图例简单地将一个矩形确定为一个对象，将一个连接确定为数据流，但并未描述计算意义、执行时序，或者那些要素的运行时特性，则文本表示主要局限于人工检验。有可能要检查通过数据流连接的所有矩形，以及数据流的方向是否相符。但是，只要假定了流范围内的数据一致性，数据通过系统的系统性能和传输时间就不容易达到。

与之相反，带有其要素（例如，并行执行的路径、执行频率和最坏情况执行时间）的运行时特性和时序语义的精确描述的模型能够进行缜密的定量分析。能够快速进行的分析包括自动化的数据一致性检查、速率单调分析、性能评估和详细的系统模拟。诸如状态机和事态逻辑模型一类的正规表示能够提供验证的原理以及能够检查系统行为的符号模型。

不考虑分析性模型，特别是具有强大的形式化基础的模型的优点，在它们的使用中也存在一些隐藏的风险。具有成熟的系统故障经验的公司是不会管它们的分析模型是否告诉他们每件事情如何完美的。这些分析模型常常是由独立的团队开发的（例如，时序模型是由性能团队开发的，信息安全模型是由信息安全团队开发的，而故障模型是由可靠性团队开发的）。他们可能是在开发寿命期的不同时段，根据系统体系结构的进展所编写的文件来开发他们的模型的。其结果是，这些模型彼此之间是不一致的，而且不能反映它们要部署的系统体系结构，如图1－2所示。

图1－2　各种分析模型之间的不一致性

能够利用体系结构中心方法将这些问题写入MBE。使用一个体系结构模型作为单一的信息源开展不同维度的分析。还可以利用与分析模型自动生成相关的信息，通过注释对于系统极为关键的、体系结构模型的各种质量属性来做到这一点，如图1－3所示。

这种体系结构中心方法较传统的MBE方法有两个主要优点。第一，对于体系结构自身的任何更改，如增加或更换一个系统组件，或者增加或更换组件之间的交互，当体系结构更改后，该系统组件或组件交互重新生成以使系统重新生效时，均自动地反映在分析模型之中。第二，更改系统对于访问其他质量属性（例如，由于增加了计算为满足时序要求而可能出现的问题）上的一种质量属性（例如，用于提高信息安全的较大数位编码算法）的影响，很容易通过重新评价不同质量维度的分析模型而确定。

图1－3　基于体系结构中心模型的工程1.1.3　MBE和AADL

由于嵌入式软件在系统集成中地位随着对集成模块化航电（IMA）概念的接受而得到增强，对于可分析体系结构模型的需求在航空航天界于20世纪90年代就已得到了承认。这也导致人们于1999年开始AADL的开发。该语言是按照MetaH仿造的，用于分析和生成嵌入式实时系统语言和工具集的研究原型，是由霍尼韦尔（Honeywell）技术中心开发的，并且在20世纪90年代就已成功地用于各种驾驶仪项目之中。 AADL最初是在2004年11月发布的，且已用于大量工业和研究倡议之中。根据来自工业和研究经验的反馈，AADL已得到完善，经过修订的标准于2009年1月已可提供①。

AADL是带有基于组件的建模概念— — —特别设计成表示嵌入式软件系统的文本和图形语言。 AADL提供了组成软件包的数据和子程序组件，以抽象地表示可以任何编程语言（例如， Java、 C或Ada语言），或者任何应用设计语言（例如，用于控制系统组件的Sim⁃ulink）实现的应用源代码。 AADL提供了线程、线程组和进程，用于表示在受保护的地址空间中执行，并且通过端口、共享数据组件以及表示软件运行时体系结构的服务调用交互的并行任务。动态的运行时体系结构是通过不同的组件层次等级上的模态机获取的，用于表示操作模式、容错配置的动态变化和组件行为。通过使用处理可预计的响应时间的混合自动机规范， AADL标准为任务执行、通信时序和模式变化提供了定义明确的执行语义。

AADL根据硬件以及虚拟处理器和虚拟总线组件（它们表示虚拟机、分区、虚拟通道和作为运行时系统抽象的协议），提供了表示计算平台体系结构的处理器、存储器和总线组件。物理系统建模通过设备和总线概念受到支持。系统组件用于表示开始应用体系结构、计算机平台和物理系统的复合组件。抽象组件和参数化组件规范支持组件模板和体系结构模式。

AADL是可利用用户定义和分析特定属性，以及专用的附件子语言进行扩展，以支持模型的注释。用于AADL的行为附件标准（附件B）扩展了核心AADL，以便规定组件交互行为，同时进一步精确地规定系统的安全关键性问题。用于AADL的错误模型附件标准（附件E）扩展了核心AADL，以便规定故障行为和错误传播，同时规定系统体系结构的可靠性问题。其他附件仍在开发之中。

此外， AADL的概念已经反映在供嵌入式系统使用的统一建模语言（UML）剖面之中。该剖面是OMG为建模和分析实时嵌入式系统（MARTE）提供UML剖面的工作的一部分。

AADL标准包括根据用于AADL的元模型定义的一个XML （可扩展标记语言）交换格式，用于协助虚拟系统集成的模型交换，并且将有注释的AADL模型自动地变换为分析模型，并且能够将民用的、家用的和研究工具链接到嵌入式系统工程环境之中。这就允许公司将AADL用于他们的现有环境，并且与他们建立的工具库集成在一起，移入可升级的和可扩展的体系结构中心MBE解决方案，从而规定他们的建模、分析和自动生成的需求。1.2　AADL和其他建模语言

在软件和系统工程界，模型基技术是无处不在的。 Mathworks Simulink是用于动态控制和嵌入式系统的模型基设计和模拟环境。它的模块库支持在组件分层结构内的连续时间和分离时间设计的建模。 Simulink模型代表与AADL线程和进程关联的应用组件的控制功能，这些线程和进程是同样作为源文本以编程语言的方式写入的。计算机硬件工程师使用IEEE标准VHDL （甚高速集成电路（VHSIC）硬件描述语言）进行详细设计，并使用了源自处理器存储器开关（PMS）的体系结构块表示（Architecture Block Notation），而这种开关又是比尔（Bell）和纽厄尔（Newell）于1971年发表的经典著作《计算机体系结构：阅读和示例》 （Computer Architectures： Readings and Examples）中使用的。 AADL通过带有与源文本相关的VHDL模型的处理器组件、存储器组件和总线组件支持PMS范例。玛德莉卡（Modelica）是一种面向对象的方程基语言，用于建模包括机械、电气、液压、热和面向过程的组件在内的物理模型。

对象管理组织（Object Management Group， OMG）借助模型驱动体系结构（MDA）、统一建模语言（UML），以及诸如系统建模语言（SysML）和实时嵌入式系统的建模与分析（MARTE）一类的UML剖面，包含了模型基工程范例。作为一种详细设计表示， UML开始用于对象基软件，并利用UML2扩展以支持基于组件的建模。 SysML是作为在UML上面的建模概念层引入的，供系统工程师规范复杂的系统。这种扩展就是所谓的UML剖面。现在，已经定义了MARTE剖面，用于支持建立AADL模型的嵌入式软件系统。

这就将我们领向跨越系统工程、嵌入式软件系统工程、硬件工程、控制工程、应用软件环境，以及机械工程类的其他工程学科的MBE实践。这种MBE实践通过各种建模能力的综合，以预计可满足安全关键性性能、可靠性、信息安全性以及其他工作质量属性，要求体系结构中心的系统协同工程（Co－Engineering of System）。

图1－4示出了嵌入式系统体系结构的三个要素，即嵌入式应用软件及其运行时系统、计算机平台以及将它们连接在一起的物理系统。它还示出了每一个要素的详细设计，以及它们的操作环境。系统工程的重点在于：主要作为其操作环境的系统，利用作为组件之一的计算机平台和作为应用软件规范的系统功能，以诸如SysML一类的体系结构表示，定义了系统和组件的要求、结构、行为和参数。嵌入式软件系统工程的重点在于嵌入式软件运行时体系结构及其与计算机平台的交互，以及物理系统。图1－4在每一个这样的体系结构要素中，以特定的表示示出了组件设计的细化。物理组件模型以类似于Modelica或Sim⁃ulink的表示示出，以获取机械、电气、流体动力学和其他物理状态。计算机硬件模型以类似于VHDL的表示示出，以获取硬件电子线路的逻辑设置。应用软件组件利用编程语言或详细的设计表示（例如，用于控制系统设计的Simulink，或用于一般软件设计的UML）设计和实现。

图1－4　体系结构中心的系统协同工程

本章其余部分详细说明了AADL与MDA/UML之间的交互，以及AADL与SysML之间的关系。1.2.1　AADL、 MDA和UML

模型驱动体系结构（MDA）是一种用于软件系统开发的综合方法，该方法支持产品全寿命期的可寻址管理、交易和技术问题。它以UML以及相关技术和实践为基础。 MDA的中心概念之一是模型细分为平台无关模型（PIM）和平台特定模型（PSM）。这种关系的划分遍及该方法，并且允许建立领域特定的模型，该模型被用作使用新技术的特定实现的基础。

AADL对于使用平台无关要素和平台要素开发体系结构模型是有效的，从而能够利用语言的定义明确的语义，在早期阶段和整个寿命期进行广泛的定量分析。在缺少平台特定信息的情况下，要进行工作质量属性的分析也许是不可能的。通过在早期发现系统级的问题，这些能力支持技术风险的缓解。

UML是“用于分布式对象系统的可视的、明确规定的、结构化和文件化软件产品（Artifact）的图形语言”。 UML起源于软件详细设计的语言，它是一种强调面向对象的方法。但是，它的适用性已扩大到软件系统范围之外。 UML已经发展到包括有助于软件体系结构和基于组件的建模的专用结构。在UM.2.0版本中，所包括的结构提供了基于组件的设计、泛化的（Generalized）接口和分层表示。

通过在用例情况中获取的应用的语境（Context）和预期使用的建模、通过类图的数据建模、通过分类和组件综合的概念体系结构的表示、通过状态图的行为建模，以及带有活动图和时序图的多个活动组件之间的交互的建模， UML支持软件的开发过程。由此， UML能够写出MDA的平台无关建模（PIM）的问题，但是工业界的用户已经认识到在用平台特定模型（PSM）提出性能关键（嵌入式）系统的非功能特性时的缺点。 AADL通过直接写出软件系统体系结构的性能关键问题来解决这一问题。1.2.2　AADL和SysML

SysML是“一个用于规范、分析、设计和验证复杂系统（包括硬件、软件、信息、过程、人员和设施）的通用（图形）建模语言”。它包括应用领域以及支持应用功能的计算资源的考虑。 SysML是为系统工程而开发的通用（图形）建模语言，它是UM.2.0的一个子集。 SysML模型是描述系统的组件以及它们的交互的图标的集合，用于表达系统的要求、结构、行为和基于方程的参数。

AADL与SysML的基础存在明显的不同。 AADL是带有建模要素图形描绘的严谨的文本建模语言（A.5506A）。 SysML是基于UML的、用于有效的视觉表示的图形语言。它并入了适用于系统工程的、且在UML找不到的两种新图：要求图和参数图。要求图支持更多的结构性要求文件，且能提高可追溯性。参数图以能够进行动态模拟的、精确的数学细节获取物理系统的动态特性。但是，这两个新图在获取和表示计算机的运行时环境（包括线程、进程，以及它们对不同处理器的分配）时均不太有效。 SysML的其余部分缺少用于严格的正规分析的明确基础，如SysML中所述： “为在严谨和易懂之间取得平衡， SysML是利用UML建模方法和精确的自然语言两者的综合规定的。在未来版本中可能加入更正规的限制和语义的使用，以提高语言的精确性。”

在获取一个嵌入式系统体系结构时， SysML与AADL的关系示于图1－4。 SysML重点在于作为其操作系统语境中的一个整体的系统，以及作为一个组件的计算机平台和软件实现系统的功能性。 AADL重点在于物理系统体系结构、嵌入式应用软件的运行时体系结构与计算机平台之间的交互。它提供了实现系统功能对于软件的影响的深入理解，并提供了对于应用运行时体系结构、诸如操作系统和通信协议一类的运行时基础结构，以及在分布式计算机平台上的部署做出的决策。根据嵌入式软件系统的时序、可靠性和故障安全行为，这类重点对于验证由系统工程师和控制工程师做出的、与系统管理和控制相关的验证假设是关键性的。类似亚丽安娜5 （Arian.5）的自毁类的灾难性故障，已经说明了这样一项工程聚焦于补充系统（Complement System）工程的重要性。第2章　使用SAE AADL进行工作

利用AADL，你能获取作为体系结构模型的嵌入式系统的体系结构，而这种模型提供了其运行时体系结构的、定义明确的、可分析的语义。这些描述的组建包括：以接口规范（组件类型）及其实现（组件实现）的蓝图的形式确定并详细描述软件和硬件组件以及它们的交互，并将它们组成软件包。这些软件包有效地代表了各种组件规范库，这些规范库能够用于多种体系结构模型，能够由不同的建模者编写和维护，并且可以是受控版本。软件包分为公开部分和支持信息隐藏的秘密部分。公开部分软件包括可供其他软件包使用的规范。可以使用秘密包部分保护不想暴露给别人的组件实现的细节。 AADL还可以包括属性集，通过它可以为AADL模型引入新的用户定义的属性。

对于线程、进程和数据类的软件组件来说，可以定义它们的运行时特性，包括执行时间、时序安排和截止时间。此外，说明其他代码相关的信息，如执行代码大小、源代码语言、源代码文件名称和源代码大小。

线程（执行路径）、数据和进程（表示编译的代码和数据）是AADL范围内最重要的运行时软件抽象。

在描述硬件时，定义处理器、存储器和总线类的执行平台组件，并利用相关的执行和配置属性表征它们的特性。例如，在定义系统的执行硬件时，说明执行线程的处理器、存储代码和数据的存储器，以及在硬件组件之间提供物理连接的总线。与这些组件关联的属性值则用于定义特性，如处理器速度、存储器字大小等。此外，还能够定义代表与系统操作环境接口的设备，如传感器和作动器。

处理器、存储器、总线和设备是AADL范围内的硬件抽象。它们提供执行环境、物理通信路径，以及用于计算系统的外部接口。

为了完成体系结构的描述，通过将系统的所有复合要素集成到单个组件分层结构之内，能定义一个完全规定的系统实现。这种分层结构建立了各组件中的交互，以及定义可执行的系统所要求的总体结构。这些结构包括数据和事件交换，各组件中的物理连接，以及软件对硬件的分配（例如，存储数据和执行实例的位置、软件执行的位置，以及支持数据和事件传输的硬件）。当你举例说明这种顶层系统实现时，就会获得一个AADL实例模型，它是你正在建模的系统的镜像。该实例模型是分析你的系统工作特性的基础。在开发一个体系结构模型期间，应能够对要求的一致性和依从性进行广泛的分析。这些分析的范围从语法依从性和基本接口数据一致性的检查，到质量属性和行为的严密的评估。例如，通过使用AADL正规的表示和专用的扩展，你能够调查诸如数据延迟、带宽、时序安排和可信性等的属性。2.1　AADL模型

AADL模型的中心是组成软件包（见本书4.4.1节）的组件类型说明和组件实现说明。在组件类型说明中，应定义组件的类别和接口（特征）。它相当于组件的单篇规范。在该类型的组件实现说明中，应定义组件的内部结构（即它们的组成和交互），这相当于根据它的各部分构件组建的蓝图。在这些说明中，你要规定为全面定义组件的运行时特性所要求的属性。这些属性可以是AADL标准中的预先说明的属性之一，或者是通过用于具体分析的标准附件引入的属性，或者是你已经通过附加的属性集引入的用户定义的属性。总之，这些说明（类型说明加上实现说明）定义了组件的样式（Pattern），组件类型和实现称作组件分类符。2.1.1　组件类别

组件被分成应用软件组件、执行平台组件、复合组件或一般（非运行时专用的）组件。这些组件汇总于表2－1。表2－1　组件类别2.1.2　语言的语法

AADL是用与上下文无关的语法描述的正式的说明性语言（A.5506A）①。在该语言中，名称和备用字是与字体无关的。在我们的示例中，备用字按照习惯用小写黑体字示出。示例表（Listing.2－1所示是一个其public部分软件包括一个进程类型说明的软件包controller（控制器）的AADL说明的示例。为Process speed＿control定义了两个feature：一个in data port和一个out data port。这些feature定义了进程类型的数据输入和数据输出的接口。用一个end语句结束软件包和进程说明。示例中示出的空行是任选的。列入空行是为了提高可读性。示例表2－1　示例的AADL说明2.1.3　AADL分类

组件类型说明和实现说明是分类符。利用它们的名称参考分类符，以建立分类符描述的样式的出现。这些参考分类符是写在类型说明和实现说明中包括的单独的文本陈述之中的。例如，在类型说明中，单一的文本说明用于声明：组件具有一个带有名称input＿speed的输入数据端口，并且通过该端口送往组件的数据类型，是通过参考的数据类型（例如，speed＿data）确定的。采样数据类型说明见示例表2－2，它包括参考speed＿ data的一个in data port说明。示例表2－2　采样组件类型说明

作为另一个例子，考虑示例表2－3示出的部分预先说明中的分组件说明。注意，如同在名称control. speed中所反映的这是一个进程类型control的实现。在这个示例中，分组件read＿speed是作为线程组件实现（样式） read＿ data. speed的一个发生（实例）说明的，而分组件control＿laws是作为线程组件实现（样式） control. basic的一个实例说明的。示例表2－3　采样组件实现说明2.1.4　AADL说明汇总

表2－2汇总了AADL说明的集合，该表左侧列出了分类符（组件类型、组件实现和特征组说明）、软件包以及属性集说明和每个说明的简化的示例，该表右侧汇总了左侧列出的说明的结构和内容。表2－2　AADL说明续表2－2

组件类型说明包括7个部分。这些部分按照说明它们的顺序示出。有一部分是features，这部分说明一个组件（如端口）的接口。 flows部分允许在不暴露组件实现的情况下讨论通过组件的流，还要加上诸如流的等待时间或计算错误等的属性。 Modes部分允许讨论组件的工作模式。 prototypes部分允许按照一个模板确定组件类型的参数，并允许使用extends结构细化组件类型模板。在组件类型或实现说明中，还可以包括properties部分。 properties部分是用于说明与组件或特征组关联的属性的地方。还可以利用属性值修饰在表右侧列出的许多说明（即特征、流、模式）。例如，当说明线程分组件时，可以为该线程分组件的周期性属性赋予一个特定值。附件库和附件分子句说明能够扩展AADL语言的功能。

组件实现包括多达9个部分。扩展、原型、属性和附件分子句部分对于组件类型具有相同的作用。根据由其分类符引用的各种分组件实例，使用分组件部分规定组件的构成。在连接部分中，应指出各分组件是如何通过组件类型的特征交互的，以及这些分组件是如何与外部的组件交互的。调用部分概述了调用来自内部线程的子程序的顺序，以及调用子程序实现的顺序。流部分详细描述了组件类型中的流规范，是如何作为流经分组件的流具体实现的。模式部分可以增加将模式转换为组件类型中规定的模式信息，或者转换为文件化的组件实现特定模式。

除了组件分类符之外，还有特征组类型分类符。特征组类型定义了一批组件特征。可以指出：通过将特征归类为每个子系统的特征组，并用单个连接将它们连接在一起，在两个子系统之间可以存在一批连接。在建模过程的早期阶段，还能够在无须详细描述各个特征的情况下，如同定义的子系统体系结构那样连接各项特征，且在稍后通过填写特征组类型，提供该特征的细节。当要说明一个组件类型说明中的特征组时，要引用特征组类型。示例表2－2中示出了这种情况，在该表中，特征组error＿set引用了特征组类型all＿errors。

软件包允许将组件类型、组件实现和特征组类型组成一个命名的（特征）组类型之中。软件包表示供其语境使用的独立的命名空间，因而一个组件类型将由其软件包名称及其组件类型名称（例如，在软件包controllers中说明的组件类型pitch＿control将被称作con⁃trollers：：pitch＿control）确定。将组件规范组成软件包的一个目的是需允许不同的团队开发一个系统，且每个团队能独立地负责不同部分的工作。在这种情况下，软件包可以作为版本控制的单元使用。

属性集使你能够在一个独立的命名空间中定义新的属性和属性类型。这些属性是通过它们的属性集名称，以及属性或属性类型名称确定的。在一个定制的描述和扩展的分析（例如，增加一个专用的信息安全级的属性以进行系统级信息安全分析）中，这样做是特别有价值的。属性集不是在软件包内部说明的，而是作为一个AADL模型的一部分单独说明的。2.1.5　AADL模型的结构

要分清系统体系结构的结构与AADL模型的结构之间的区别。应使用互相影响的组件的分层来表示系统的分层。使用软件包将组件接口规范（组件类型）以及它们的蓝图（组件实现）加入到软件库中，以利于协作团队进一步开发体系结构模型。还能通过将它们组成不同的属性集引入新的属性。换句话说， AADL模型由软件包和属性集组成。所有的AADL说明均必须包括在一个软件包或属性集说明之内。

软件包和属性集说明不能以任何方式嵌套（即：既不能在别的软件包或属性集范围内说明一个软件包，也不能在别的属性集，或者软件包的范围内说明一个属性）。但是，能够嵌套软件包的名称，就像在Java语言中的软件包一样。例如，你能够说明一个称作sei：：boats：：gps的软件包。

图2 .1示出了AADL模型的结构，图中矩形表示说明。在类型与实现说明间的虚线箭头表示：实现属于由箭头指向的类型。修饰矩形和实现链接的星号表示出现0次或多次。可能存在与单一类型关联的多个实现，也可能存在没有实现的类型。此外，当在一个软件包中可能存在多个附件库说明时，每一个附件只应有一个附件库。

图2－1　AADL模型的结构

你能够具有包括在单一文件内的完整的AADL模型，或者具有被分到多个文件中的软件包和属性集，即使每个软件包和每个属性集的内容均具有一个单独的文件。这些文件能够由不同的团队成员分别处理，并且可以是版本受控的。分成若干个文件的规范是工具专用的。例如，当标准未要求时，开源AADL工具环境（OSATE）假定：每个软件包和属性集都在一个单独的文件内。 AADL标准允许AADL模型存放在替换文件系统的数据库内。在这种情况下，软件包和文件是不一致的。2.2　系统规范和系统实例

一批AADL软件包和可选属性集表示AADL中的系统规范，称为AADL说明性模型。它表示用于描述一个嵌入式系统的结构、属性和连通性的体系结构蓝图。

一个系统实例模型（或者简称为实例模型）是系统模型的实例，它使用带有说明性系统模型的系统组件实现作为它的根源。能够建立整个系统的实例模型，或者通过选择相应的系统实现说明作为起点，建立感兴趣的特定分系统的实例模型。说明性模型的组件实现，被理解为建立和连接系统的所有组件实例的蓝图。

使用这种实例模型去分析你的系统体系结构，并且使用分析能力组建或者作为类似于OSATE的工具集的扩展，或者通过借助标准化交换表示的独立分析生成它的实现。有关模型组建和验证工具的附加信息，请参见本书第15章。2.2.1　组建系统实例模型

系统实例模型表示一个有全面规定的说明性模型生成的工作的物理系统。在全面规定的说明性模型中，运行时体系结构被表示到带有应用软件组件的线程级和子程序调用级，这些应用软件组件是作为子程序类型和数据组件类型建模的。此外，全面规定的系统包括执行应用代码的处理器、存储应用代码和数据的存储器、代表嵌入式应用的物理环境的设备，以及连接这些组件的总线。

AADL允许你将系统建模到与开发阶段和感兴趣的分析有关的保真度水平。换句话说，可以根据主要子系统，或者根据带线程或不带线程的进程，建立部分完成的系统模型。能够建立这种部分模型的实例，并对其进行分析。 AADL允许你组建整个系统的实例模型，或者任一子系统的实例模型。还可以通过选取相关系统实现作为你的实例的根源来做到这一点。

可利用类似于OSATE的工具生成实例模型。这种生成过程是通过首先例示包括顶层系统实现的各种要素，进而例示它们的组件和分组件等（例如，从系统到进程再到线程）来完成的。导出的系统实例模型明确地表示组成该系统的要素所需的各种运行时问题（例如，将每个线程绑定到处理器，将要求的运行时属性分配给系统的每个要素）。2.2.2　AADL文本域图形表示

到目前为止，我们专注于讨论文本表示。 AADL概念的定义明确的语义是AADL的一个重要优点，尤其是当将其应用于定量的系统体系结构分析时。但是，还有与AADL要素的文本表示相对应的标准图形表示。这些表示都是在SAE AADL标准（A.5506A）中定义的。图2－2示出了用于线程的文本表示及其对应的图形表示。用于线程类型的图形表示是一个虚线的、用线程data＿processing示出的平行四边形。数据端口表示为装饰有类型图标的小三角形，用数据端口raw＿ speed和speed＿ out示出。一个线程的执行Period （周期）的数值包括在线程图标顶部的椭圆形框内。

图2－2　AADL图形和文本表示

图2－3　OSATE图形表示

图2－4　OSATE AADL文本表示

在开发系统的AADL模型时，这些表示可以使用其中之一，也可以一起使用。首选形式属于个人选择的问题，并且取决于你使用的建模工具的能力。例如，你能够建立一个嵌入式系统图形体系结构的最初的结构，并且用文本AADL细化模型，或者依靠建立和编辑AADL模型的专用图形接口以及与之对应的文本表示细化模型。系统实例作为用XML表示的系统实例规范（模型）组建并存储。分析和代码生成工具能够处理系统实例规范模型。

通读本书，我们就能够将开源AADL工具环境（OSATE），用作我们的AADL表示法的示例环境及其模型基工程实践中的应用（OSATE）①。所描述的能力不是OSATE环境的唯一能力，而且AADL的使用也未要求OSATE。如图2－3和图2－4所示， OSATE支持AADL的图形表示和文本表示，并提供了这两种表示②的编辑能力。例如，你能够通过从一个调色板中选择建模要素，并根据组件库（软件包）确定组件类型，用图表（见图2－3）为系统建立一个组件实现。然后，你能够通过形式基（Forms－based）的AADL属性视图填写组件的属性。换句话说，为建立初始模型，使用图形编辑器的工作并不要求详细了解AADL文本语言的语法。随后你能够转换文本视图（见图2－4），并且在适当的时候细化AADL的文本模型。2.2.3　分析模型

AADL概念的定义中明确的语义允许对AADL实例模型进行各种形式的定量分析。为了建立分析用的AADL实例模型，你能够举例说明带有执行平台说明模型的一个部分应用系统或完整应用系统的示例。在这种实例模型中，能够根据应用分系统的CPU周期和存储器要求分配资源预算，以及你的执行平台的资源能力。获得了这种数据，你就能够分析应用组件对于执行平台的各种绑定，并保证预算不会超出平台的能力。你还能够将流规范加入各个子系统组件，将端对端流加入应用系统。根据这些流规范，就能够进行诸如端对端响应时间分析一类的流分析。所有这些分析都能够在没有足够详细的系统模型的情况下完成。在体系结构开发完成时，能够进行广泛详尽的、完整的系统实例模型分析，以评估与所要求的功能和质量等级的一致性。

在系统开发阶段的早期，人们希望具有部分规定的但可供分析的系统模型。例如，你可能应该在尚未提供其详细的实现（例如，在子系统仅作为抽象或系统组件建模之处）之前，将应用系统表示为一组交互的子系统。许多这类分析能够利用部分说明的模型进行。例如，你能够检查所有端口是否均已连接，一个连接包括的端口之间数据是否一致，以及资源预算是否在系统规定的能力范围之内。第3章　使用AADL建模和分析的基础

在本章中，我们说明了基本AADL模型的开发并提出了使用某些AADL核心能力的通用指南。为此，我们希望提供体系结构建模与分析的基本知识，并使读者能开始将应用AADL的方法用于更复杂的软件依赖型系统。

当阅读本章的第1部分时，可能要使用一个AADL开发工具组建规范，并进行所描述的分析。 OSATE支持本章中所讨论的全部建模和分析。3.1　简单模型的开发

在本节中，我们按部就班地给出AADL模型的开发和分析。我们建立一个控制系统模型，该系统提供了一维速度控制，以及能够利用这种体系结构模型进行的某种分析验证。速度控制功能是汽艇自动驾驶仪（PBA）系统（详见附录A）的一部分。尽管这个实例是专用于汽艇的，但这个示例说明了AADL的使用，也适用于诸如航空、汽车和地面车辆速度控制系统类的类似的控制应用。

我们使用的方法是一个引导，验证了AADL的某些核心要素和能力的使用。我们没有考虑该语言的许多较广泛的工程能力。例如，没有撰写这种简单模型时使用的软件包、原型或组件扩展。这些扩展在本章后续部分讨论。我们随后生成基本说明模型及其实例，并展现系统实例的调度分析。在阅读本章期间，可能需要参考第2部分，以详细了解本示例使用的具体的AADL要素或分析。

一开始，我们使用AADL系统、进程和设备组件组建一个高级系统的代表。在构建这种原有的代表时，我们详述了所有要素的运行时组成；将软件分配到硬件资源；并给各要素的属性赋值到建立和分析一个系统实例所要求的水平。在这些步骤中，我们假定：各项要求已足够详细到为体系结构设计决策和该示例中的权衡说明提供了合理的基础。此外，当我们引用为许多步骤诸如内容广泛的特定体系结构开发和设计方法时，我们没有推崇一种方法而贬低另一种方法。3.1.1　模型组件的定义

第一步是定义组成系统的组件，并将它们放入软件包之内。定义并获取组件的过程类似于确定面向对象的方法中的对象。重要的是要了解可能包括功能的抽象包装的组件，并且在系统及其环境中表示系统的确定事物。组件的定义通常是一个迭代增进的过程，最初的一组组件不可能表示一组完整的组件，而且有些组件可能需要修改、分解或者与其他组件混装。

首先，我们要审查PBA速度控制装置的描述，并定义一个简化的速度控制模型。在该模型中，我们要包括一个用于输入PBA相关信息的驾驶员接口单元、一个用于为PBA传送速度数据的速度传感器，以及一个用于响应PBA命令的油门操纵杆。

对于每一个已确定的组件来说，我们将开发类型定义，特别是定义组件的名称、运行时类别和接口。因为我们最初开发的是一个高级（概念）模型，我们将组件类别限制为系统、进程和设备。

最初的一组组件示于表3－1，表中包括AADL文本和相应的图形两种表示。对于这种示例而言，该模型所要求的所有组件的文本表示均包括在单个软件包之中，并且不需要涉及软件包外的分类符。因此，当引用分类符时是不需要软件包名称的。考虑到图形表示，明确示出了实现关系。注意：当与其对应的类型图标的装饰符相比较时，实现的图标具有一个明显的装饰符。表3－1　速度控制示例的组件类型和组件实现续表3－1

将速度传感器、驾驶员接口和油门操纵杆建模为设备，并将PBA控制功能表示为一个进程。我们使用组件的设备类别作为与外部环境的接口— — —我们并不想进行深入的分解（例如，一个设备只能具有一个作为分组件的总线）。

AADL中的设备能够代表可以包括嵌入式处理器和软件的复杂组件的抽象。对于设备组件来说，我们仅表示对于分析和明确表示一个组件所必需的那些特性。例如，在建模一个辅助GPS接收器时，我们事实上可能只对在通信端口可获得的位置数据感兴趣。而事实上，我们并不要求将具有一个嵌入式处理器、存储器、触摸屏用户接口和相关软件的GPS接收器，用于系统的分析或建模。作为选择，设备能够代表相对简单的外部环境，例如，一个速度传感器，它仅输出其频率正比于正在感受的速度的一系列脉冲。如果要求与外部环境的复杂接口，就能够使用系统组件。在这种情况下，能够详细说明它的组成，并且如果需要的话，还要包括一个简单的设备分组件，以表示对该环境的接口。

控制功能的进程组件的使用反映了这样的决策：即PBA的核心控制处理要用软件来实现。软件运行时组件将包括在这种进程类型的实现之内。表3－1中的实现说明并未包括任何细节。随着设计的进展，我们将增加这些说明（即增加分组件和属性，如果适用的话）。

PBA组件的接口是在组件类型中说明的端口特征，并且反映在该类型的每个实现之中。例如，类型sensor经由数据端口sensor＿ data输出速度值。驾驶员接口类型interface经由数据端口set＿speed提供设定的速度值，并且生成一个经由事件端口disengage释放速度控制的信号。

注意：我们已经明确而简明地使用了模型的端口和其他要素的命名（例如，在输入和输出端口用于命令数据的command＿data和cmd）。命名的特异性（Specificity）由你决定，前提是它们符合标识符（例如，初始字符不能是一个数字）的AADL命名限制。注意命名是用例不敏感的，而Control与control名称是相同的。

在PBA示例中，我们已经选择将专用的运行时组件类别赋予每个组件（例如，将速度传感器命名为设备）。但是，在作为成熟设计的现实开发中，这些组件的定义是可以改变的（例如，一个计算PBA速度控制规律的组件，最初可以表示为一个系统，后来可以改为一个进程或线程）。使用我们在本书中概述的方法，可对AADL模型进行人工更改（即将系统模型更改为进程类别说明）。一个可选的方法是使用通用的抽象组件类别（即不定义特定的运行时本质）。在开发的后期，可使用AADL extend （扩展）能力，将这种抽象类别转换成特定的运行时类别（例如，将一个抽象组件转换为一个线程）。我们已经选择使用前述方法简化该陈述，并将精力集中于决定以及与作为具体运行时组件的系统表示相关的问题。本书3.5节中提供了使用抽象组件类别的讨论。

我们为每种组件类型定义了一个实现。这些说明是部分的，因为我们忽略了一个完整的体系结构规范所需的基本细节。例如，我们没有定义与端口关联的数据类型。我们将按照后面的步骤中的要求，写出这些遗漏的细节。但是，我们能够在缺乏许多这类细节的情况下，就我们的简单示例进行大量的分析。3.1.2　顶层模型的开发

下一步，我们通过说明分组件的实例以及它们的连接，将各个组件实现集成到一个系统之中。我们通过定义一个如示例表3－1 （其中，我们定义了一个系统类型Complete （表示全系统的整体）及其实现Complete. PBA＿speed＿control）中所示的封闭系统类型和实现，示例表3－1　整个PBA系统的分组件

来做到这一点。对于这个封闭系统来说，我们选择的命名并无什么特别之处。另一种命名模式，例如， PBA的类型和PBA. speed的实现，也可以使用。

在实现范围内，我们说明了4种分组件.3种分组件代表速度传感器、油门杆和驾驶员接口单元。进程分组件speed＿control代表为PBA提供速度控制的软件。注意没有用于系统类型Complete的外部接口。系统的分组件中的所有交互均位于实现Complete. PBA＿speed＿control的内部，且具有为外部环境（例如，确定来自汽艇的速度信息的传感器）提供接口以组成系统的设备。

在实现范围内，我们为各分组件的每个端口定义了连接。例如，连接DC2是在进程speed＿control上的command＿data端口与设备油门杆（throttle）上的cmd数据端口之间的数据连接。各个连接是通过连接特性①用示例表3 .1的图形表示标记的。例如，在interface＿unit设备上的事件端口disengage与speed＿control进程上的事件端口disengage之间的连接EC4是作为＜＜Event＞＞标记的。它是我们用于匹配大多数端口名称的选择。它并未要求具有相同名称的连接端口。但是，如果规定了的话，它们必须具有匹配的数据分类符（在这种初始表示中，忽略了它们）。

图形描述可以不同于示例表3 .1中所示的，这取决于你的开发环境。例如，在OS⁃ATE中，你不能明确地显示其内容。相反，以单独的图形表示的一个实现的内部结构，能够通过表示实现Complete. PBA＿speed＿control的图标分层地访问。3.1.3　控制软件的细节描述

此刻，我们开始详细构建进程speed＿control。它包括涉及PBA系统提供速度控制所要求的、区分功能和责任的决定。因为我们已经将速度控制作为自主能力处理了，我们暗示了在PBA的方向或其他要素与速度控制系统之间没有交互。而在先进的控制系统中是不可能存在这种情况的。此外，就本例的目的而言，我们将速度控制进程分为两个分组件。第一个分组件是接收来自速度传感器的输入、确定数据的比例和对数据进行滤波，并向第二个线程发送处理数据的线程。第二个分组件是执行PBA速度控制规则，并将命令送给油门杆作动器的线程。而且，对于一个真实的速度控制系统而言，这种简化并不适合（例如，控制规则可能包括大量的计算，为有效起见，必须将这些计算分为多个线程，或者可以包括通过各种各样的速度或方向条件触发的复杂的模式转换）②。

因为用于两种线程的接口是不同的，我们为每种线程定义了类型和实现，如示例表3－2所示。我们已使用了属性关联，以便为线程分配执行特性。每个线程均为周期为50ms （使用Period （周期）属性关联分配的）的一个周期性线程（使用Dispatch Protocol（派遣协议）属性关联分配的）。

周期执行与线程周期数值的分配反映了设计决定。通常，这些数值是以应用领域和/或控制工程师的输入为基础的。我们这里使用的分配值不必是最佳的，但它们可选择用于提供能够进行系统性能分析的具体数值。它们并未反映任何特定控制系统的数值。示例表3－2　PBA控制线程说明

我们详细地描述了表3－1中示出的进程实现control. speed，以包括两个线程分组件以及它们的交互（connection），如示例表3－3所示，表中示出了5个连接。它们之中，有4个连接用于连接进程边界处的端口与线程（即： DC1、 DC3、 DC4和EC1）上的端口。第5个连接将线程scale ＿ speed ＿ data上的输出数据端口proc ＿ data连接到线程speed＿control＿laws上的输入数据端口proc＿data。示例表3－3　进程实现control. speed续示例表3－33.1.4　添加硬件组件

此刻，我们已经定义了速度控制系统的软件组件。我们现在定义支持该软件所要求的执行硬件。在建模硬件将控制软件绑定到该硬件时，我们能够分析系统的执行计时和时序安排问题。

在示例表3－4中，我们定义了处理器、存储器和总线。处理器将执行PBA的控制代码（线程），而存储器将存储系统的可执行代码（进程）。此外，我们已经说明了：处理器类型Real＿ Time和存储器类型RAM要求对总线实现Marine. Standard的实例的访问。该总线将为系统提供物理路径。在建模过程的后期，我们将为这些说明添加属性。示例表3－4　执行平台说明3.1.5　物理连接的说明

为了继续系统的集成，我们通过说明实现的各分组件，增加了要求将执行平台组件集成到系统实现Complete. PBA＿speed＿control中的实例。此外，我们还说明了连接到总线的这些组件。它是通过将处理器和存储器组件上要求的（requires）接口连接到总线组件上实现的。

因为在处理器上执行的PBA控制软件必须从传感器和驾驶员接口单元接收数据，并向油门杆作动器发送命令，我们认为这些传感器和作动器设备与总线的连接良好。为此，我们在这三种设备的类型说明中增加了要求的总线访问（requires bus access）说明，并将它们与该总线连接起来。这三种设备的更新的说明见示例表3 .5，而系统带有物理（总线）连接说明的图形表示见示例表3－6。

在示例表3－6中，我们已经将处理器RT＿1GHz①、总线Standard＿ Marine＿ Bus和存储器Stand＿Memory定义为分组件。此外，已经说明了总线Standard＿ Marine ＿ Bus与每个物理组件的requires bus access特征的连接（例如，从Standard＿Marine＿Bus到RT＿GHz. BA1以及到处理器RT＿1GHz. BA1上的requires bus access特征的连接）。示例表3－5　更新的设备说明

试读结束[说明：试读内容隐藏了图片]

下载完整电子书