Lustre和MARTE等建模语言的区别

在选择建模语言时，我们总是会陷入一些纠结的过程，因为针对一个场景，可能并不只有一个建模语言适用，但是语言之间或多或少会有一些区别，相较于常用的开发语言，java，c++或是python有比较明显的适用场景，嵌入式领域的一些建模语言比较小众，有些建模语言看似可以使用，但是如果深入使用，特别是在科研中，会遇到一些无法解决的问题。

接下来，为了研究需要，我将介绍一下几种常见嵌入式建模语言的区别，有些会做一些实践，有些只进行适当的介绍，毕竟有些语言我也不会去使用，大家根据自己需要，再深入了解。

这篇我先做个简介，后续实践上的比较有时间在更。

零、模型驱动开发

模型驱动开发方法(model driven development,简称 MDD)能够在早期阶段对系统进行分析与验证,有助于保证系统的质量属性,并有效控制开发时间与成本.而质量属性是由系统体系结构决定的[1].因此,基于体系结构模型驱动(model-based architecture-driven)的设计与开发方法成为复杂嵌入式系统领域的重要研究内容.其中一个重要的方面就是研究合适的体系结构描述语言。

安全关键领域常用的建模语言主要有：规范与描述语言SDL，结构分析与设计语言AADL，系统模型语言SysML，抽象语法ASN .1，同步语言Lustre等，安全关键系统的实现主要需要通过规约，分析，设计，继承，验证，测试等多个阶段，从一个宏观的系统模型，到系统中具体某一个需要实现的功能逻辑，每一个层次都需要进行建模，然后通过形式化验证的方法来保证系统的安全性。

一、UML

常用的体系结构描述语言主要有 UML(unified modeling language) 和 ADL(architecture description language).UML 侧重描述系统的软件体系结构,为了支持嵌入式实时系统的非功能属性分析,OMG(Object Management Group)先后定义了 UML Profile for SPT(schedulability, performance, and time,简称 SPT),UML Profile for Qos/FT(quality of service and fault tolerance,简称 Qos/FT)[3]以及 UML Profile MARTE(modeling and analysis of real-time and embedded systems),它们继承了 UML 的多模型多分析方法,因此模型之间可能存在不一致性。

而 C2,Darwin,Wright,Aesop,Unicon,Rapide 等 ADL 都是通用领域的软件体系结构描述语言,难以满足软硬件协同设计、实时响应、资源受限等特定需求;MetaH 是面向航空电子系统的 ADL,可以用于嵌入式实时系统体系结构描述与分析,但 MetaH 在支持运行时体系结构描述、可扩展、与其他 ADL 兼容以及复杂系统设计等方面有所欠缺.

二、AADL、SDL

SDL的重点在于对系统功能模块进行建模，对系统某一个具体的功能模块进行详细的**贴介于代码层面的细节建模。在模型驱动的软件开发方法中，AADL适用于详细设计过程中对系统整体结构进行建模，进行仿真和形式化方法进行验证分析。**SDL适用于详细设计过程中，对整个系统的某一个细小的功能模块建模，进行模型验证与代码生成。

SDL(Specification and Description Language)语言是CCITT推荐的规格与描述性语言。由ITU-T发展和标准化，定义在兰皮书Z .100建议中(1992年，1996年增补)。作为国际标准化的正式语言，它被用来规范描述实时系统。目前，SDL-96是SDL的最新版本。作为SDL相关技术，本文把Z .120建议：消息序列图(message sequence charts ,MSC)和Z .105建议：抽象语法符号-(abstract syntax notation-one ,ASN .1)作为SDL的一部分理解。

使用SDL，可以半图形、半文本地定义特定类型的嵌入式系统的功能描述。这种方法的高度正式性，使得SDL工具有可能生成和测试完整的嵌入式应用。

美国汽车工程师协会SAE(Society of Automotive Engineers)在MetaH、HOOD、UML、ADL的基础上，提出嵌入式系统体系结构分析与设计语言 AADL (ArchitectureAnalysis and Design Language)，并发布为SAE AS5506标准。AADL语言与之对应地提供了软件体系结构、运行时环境以及硬件体系结构的建模概念。通过行为附件 (Behavior
Annex)扩展了对功能行为的表达能力，故障模型附件(Error Model Annex)增强了对系统安全性、可靠性分析的描述能力等。通过构建和连接来描述系统的架构。当定义新的属性不能满足用户需要时，AADL引入了附件的概念。**它拥有独立的语法和语义，但必须与AADL核心标准保持语义一致。**如故障模型附件(error model annex)，支持构件、连接的故障事件、故障概率等属性建模；行为附件(behavior annex)增强了AADL对构件实际功能行为的详细描述能力，以更好地支持功能行为验证和自动代码生成。国内外对AADL模型研究主要集中在下面几个方面：利用模型进行嵌入式系统的可调度性分析；利用模型进行安全性的检测；利用AADL错误模型对异常分析，还有利用行为附件对系统的行为进行建模等。

模型转换是 AADL 语义描述的关键.某作者采用 B 语言和高阶逻辑 HOL(higher-order logic)形式刻画
AADL 元模型,以支持 AADL 模型转换的正确性.我们认为,可以采用定理证明的方式来保证模型转换的语义一
致性.对部分 AADL 形式语义描述语言进行比较,见表 1

三、Sysml

SysML是使用最广泛的建模语言之一，它的发展历史和背景可以追溯到2003年，当时对象管理组（OMG）和系统工程国际委员会（INCOSE）开始联合开发一种用于系统建模的标准化语言。他们发现，尽管存在许多不同的系统工程方法学，但它们都有一个共同的需求，即需要一种通用的、可扩展的建模语言，以帮助他们在整个系统开发生命周期中进行有效的沟通和协作。

在 SysML 之前，存在多种不同的建模语言和方法，每种都有其独特的优点和局限性。然而，这些语言和方法之间的互操作性和兼容性是一个重要的问题。为了解决这个问题，OMG 和 INCOSE 决定开发一种统一的、标准化的建模语言，这就是 SysML。

SysML 的设计灵感来自于 UML（Unified Modeling Language），一种最初为软件系统工程开发的建模语言。然而，SysML 更加注重在各种类型的系统中进行建模，而不仅仅是软件系统。因此，SysML 在 UML 的基础上添加了一些新的视图和图表，以支持更广泛的应用领域。

自 2003 年以来，SysML 已经经历了多个版本的更新和改进。随着时间的推移，SysML 已经逐渐被业界广泛接受，并成为许多系统和软件开发生命周期（SDLC）项目的首选建模语言。

四、Lustre

Lustre是一种用于同步数据流编程的编程语言，它的开发可以追溯到20世纪80年代初。Lustre最初是作为一项研究项目而开发的，旨在为反应式系统编程提供一种更简洁、更直观的编程语言。

在1991年，Lustre的正式介绍出现在IEEE会议记录中，这标志着它作为一种独立的编程语言被正式认可。Lustre的早期版本主要被用于学术研究，以探索反应式系统编程的新的方法和模型。

随着时间的推移，Lustre逐渐得到了更广泛的应用。在1993年，Lustre成为了Esterel技术公司开发的工业环境SCADE[4]的核心语言。这个环境被广泛用于飞机、直升机和核电站的关键控制软件中。

进入21世纪后，Lustre得到了更多的商业应用。一些大型科技公司开始使用Lustre来开发他们的关键系统，这进一步推动了Lustre的发展和技术进步。

Lustre是一种基于数据流模型的同步语言，用于描述和验证实时系统，其主要应用领域有自动化控制以及信号处理系统等。Lustre程序由若干节点(node)组成，执行时会明确一个主节点。每个节点相当于普通语言中的子程序。不同于普通语言，Lustre语言的所有数据对象(变量、常量以及表达式)的取值都是流(stream)。每个流都有各自的时钟(clock);每个节点有一个基本时钟，是该节点中所有数据对象的时钟里面最快的一个。程序的执行是无限循环的过程，每次循环均在一个时钟。

五、MARTE

MARTE（Modeling and Analysis of Real-Time Embedded Systems）是OMG制定的基于UML的嵌入式实时系统建模与分析的建模语言。支持嵌入式实时系统基于模型的需求、设计、验证和确认。在显式语义描述方面,文献采用 UML Marte对同步执行模型中周期性线程之间基于数据端口的即时与延迟通信(immediate and delayed communication)机制进行了语义描述,UML Marte 具有显式的时间模型,能够同时描述逻辑时间和物理时间,方便定义线程的时间属性和通信协议.同时,AADL 的通信语义本质上就是实时任务的时钟约束关系,对系统调度和可调度分析有直接的影响.但 UML Marte 难以支持形式化验证和分析.

使用MARTE可以获得以下好处：

提供一种统一的嵌入式实时系统软硬件建模方式，以改善开发人员之间的沟通；
支持需求定义、设计、验证和代码生成等开发工具之间的互操作性；
支持兼顾软件和硬件特性的模型以支持嵌入式实时特性进行量化预测。

标准架构

MARTE定义了多个扩展单元，这些扩展单元分成四个主要部分。

1. List item

基础部分包括

核心元素
非功能属性NFP
时间模型Time
通用资源模型GRM
分配Alloc

2. List item

设计模型包括

通用组件模型GCM
高层应用模型HLAM
软件资源模型SRM
硬件资源模型HRM

3. List item

分析模型包括

通用定量分析模型GQAM
调度分析模型SAM
性能分析模型PAM

4. 附录包括

数值规范语言VSL
复用结构模型RSM
MARTE库

MARTE标准的每个扩展单元提供Base和Full两个级别。MARTE是一个综合的标准，有多种应用，不同的应用使用到MARTE不同的扩展单元的不同级别。

软件建模：主要涉及嵌入式实时应用建模相关的扩展单元和非功能属性。
硬件建模：主要涉及嵌入式实时高层硬件建模相关的扩展单元和非功能属性。
系统架构：包括软件建模和硬件建模，加上分配。
性能分析：涉及嵌入式实时系统性能分析相关的扩展单元。
调度分析：涉及嵌入式实时系统调度分析相关的扩展单元。

典型用例

• 构建模型用例：由模型设计人员执行，在系统不同的生命周期阶段根据特定方法论使用合适的UML扩展建立描述嵌入式实时系统特征的模型。这个用例的输出是嵌入式实时系统模型。

• 标注模型用例：由模型分析人员执行，使用合适的MARTE扩展对系统模型进行标注以便进行特定的分析。这个用例的输出是已标注的可进行特定分析的系统模型。

• 分析模型用例：由模型分析人员执行，使用特定的分析技术对已标注的系统模型进行分析。这个用例的输出是分析结果。

• 适配标准用例：由方法论提供商和执行平台共同执行。基于MARTE对特定领域进行适配，形成特定领域的子Profile。这个用例的输出是基于MARTE的特定领域的子Profile。

• 定义方法认用例：由方法论提供商执行。定义如果使用MARTE实现特定的目标。这个用例的输出是一个基于模型的方法论。方法论有时会包括Profile的定义。例如MARTE的EAST-ADL附录是针对车载电子系统设计的方法论，而其AADL附录是针对航空电子的方法论。

• 构建执行平台模型用例：由执行平台提供商执行。建立支持基于MARTE的嵌入式实时系统研发的执行平台模型。这个用例的输出是一个兼容MARTE标准的执行平台模型。

• 提供执行平台用例：由执行平台提供商执行。提供一个兼容平台模型的执行平台。这个用例的输出是一个执行平台。