系统建模与分析

Cyber-Physical Systems

Cyber-Physical Systems 信息物理系统 CPS

什么是Cyber-Physical Systems

Cyber-计算、通信、控制并且离散、逻辑、交换的系统。
Physical-一些受物理定律的支配， 并可持续运行的自然或人工系统。
Cyber-Physical Systems-网络和物理系统紧密结合在一起的系统。是一个结合计算、网络和物理环境的多维复杂系统，通过3C技术的有机融合与深度融合，实现大型工程系统的实时感知，动态控制和信息服务

CPS系统的特点

• 由新需求和应用驱动的网络-物理耦合
  – 每个物理组件的网络能力
  – 大规模有线和无线网络
  – 在多个极端规模上联网
• 系统中的系统
• 新的时空约束
  – 在多个时间和空间尺度上的复杂性
  – 动态重组/重新配置
  – 非传统计算和物理基底
• 通信/计算/控制之间的新型交互
  – 高度自动化，控制回路必须在所有范围内闭合
  – 控制回路中大量精通非技术的用户
• 无处不在推动了前所未有的安全和隐私需求
• 操作必须可靠，在某些情况下经过认证
• 它们不是什么：
• 不是桌面计算
  – 非传统的事后嵌入式/实时系统
  – 不是今天的传感器网络
• CPS研究计划的目标
  – 未来工程和监控/控制物理系统的新科学（10-20年展望）
  – 物理和网络（计算、通信、控制）设计深度集成

CPS应用领域

保健:医疗器械、健康管理网络
运输:汽车电子、车载网络和智能高速公路、航空和空域管理、航空电子、铁路系统
过程控制:大规模基础设施、物理基础设施监控、发电和配电
防御系统
远程物理操作:远程医疗、远程操作

系统的主要趋势

• 系统复杂性
  – 增加功能
  – 增强集成和网络互操作性
  – 对软件的日益重视和依赖
  – 越来越多的非功能约束
• 未来系统的性质
  – 动态、多变、可靠、高度自信
  – 自我*（意识、适应、修复、维持）
• 网络物理系统无处不在，人人使用，无所不能
  – 期望：100%可用性，100%可靠性，100%连接，即时响应，永远记住一切。。。
  – 阶级：年轻人到老年人，有能力的和残疾人，富人和穷人，识字的和文盲。。。
  – 数字：个人、特殊群体、社交网络、文化。。。

嵌入式软件-目标

• 值得信赖：不应失败（或至少适度降级），使用安全。只有当嵌入式系统出现故障时，嵌入式软件的存在才变得明显。
• 上下文和态势感知：应能够感知人员、环境和威胁，并计划/通知/启动响应，以在有限的资源下与动态变化的物理环境进行实时交互。
• 验证和认证：应能够确保嵌入式系统在功能和非功能需求方面以高度的确定性正确工作。

CPS挑战

开发高置信度CPS需要

• 系统组成
  – 建筑系统体系
  – CPS的“大主题”
  – 需要确保组成的系统是安全的
  – 两种方法：系统级组合，协同设计
• 理论建模与分析
  – CPS的复杂性足够高，基于数学模型的工程至关重要
  – 例如：混合系统——同时考虑CPS底层组件的离散和连续时间动态
• 抽象编程
• CPS的功能行为应与及时性、QoS、可靠性等要求相分离。
  – 基于模型的开发：应使用模型（状态机、数据流图）说明功能，并自动生成系统代码
  – 优点：（1）易于共享设计，（2）不需要目标平台的详细知识
• 验证和认证
  – 鉴于CPS的复杂性，基于科学基础对其进行认证至关重要
• 两步流程：
  – 设计具有正确的属性
  – 实施符合设计
• 所需工具：
  – 从需求中引出模型
  – 正在验证符合正确属性的模型
  – 验证实施w.r.t.要求的指标
• 对量化此类系统的可靠性、责任和风险至关重要
• 使他们是可信的

Model-Drive Development

Model-Drive Development 模型驱动开发 MDA
某个系统的简化/抽象表示，从给定的角度突出感兴趣的属性。
该观点定义了模型的关注点和范围。

Model Driven Architecture

模型架构驱动MDA定义了三种模型：

• 计算独立模型(Computation-Independent Model，CIM)：描述系统的需求和将在 其中使用系统的业务上下文。此模型通常描述系统将用于做什么，而不描述如何实现系统。CIM通常用业务语言或领域特定语言来表示。
• 平台独立模型(Platform-Independent Model,PIM)：描述如何构造系统，而不涉及到用于实现模型的技术。此模型不描述用于为特定平台构建解决方案的机制。PIM在由特定平台实现时可能是适当的，或者可能适合于多种平台上的是实现。
• 平台特定模型(Platform-Specific Model,PSM)：从特定平台的角度描述解决方案。其中包括如何实现CIM和如何在特定平台上完成该实现的细节。
  

Model and Analysis of Real-Time Embedded system(MARTE)

MARTE(modeling and analysis of real time and embedded systems)是UML在嵌入式实时系统领域的建模规范，取代原有的UML-SPT（UML profile for Schedulability , Performance and Time），支持对嵌入式实时系统的非功能属性建模。弥补了UML在嵌入式实时领域应用的不足

Unified Modeling Language(UML)

OMG定义了一系列建模语言用于创建PIM和PSM，最通用的语言是UML。
UML（统一建模语言，Unified Modeling Language）是一种用于软件密集型系统进行可视化、详述、构造和文档化的建模语言。


领域特定语言DSL（Domain Specification Language）
UML2.0(Unified Modeling Language)提出Profile提供了一个通用的扩展机制,用于对特定领域或平台自定义相关的UML模型。

• Stereotype（构造类型）
• TaggedValue（标记值）
• Constraint（约束）
  元模型（metamodel）：元模型是关于模型的模型。
  
  构造类型（Stereotype）：
  

Architecture Analysis and Design Language(AADL)

2001年,SAE提出基于MetaH定义一个航空电子体系结构描述语言标准,即Avionics ArchitecturDescription Language(AADL),支持描述标准的航空电子控制与数据流机制及实时、容错、安全等非功能性质.
2004年11月,发布了AADL1.0版本,以文本的形式给出核心语言的语法和语义.
AADL涉及系统全生命周期的各个阶段，AADL的发展及研究与传统软件工程、软件体系结构发展类似，首先关注全生命周期的设计阶段，然后过渡到设计之后的实现、后开发阶段，最后再关注设计之前的需求分析阶段，覆盖全生命周期的整体框架。
AADL定义了3类构件:软件构件、执行平台构件以及系统构件.

• 软件构件用于软件体系结构建模,包括数据(data)、线程(thread)、线程组(thread group)、进程(process)、子程序(subprogram)构件;
• 执行平台构件用于硬件体系结构建模,包括处理器(processor)、虚拟处理器(virtual processor)、存储器(memory)、总线(bus)、虚拟总线(virtual bus)、外设(device)构件;
• 系统构件(复合组件)组合所有的构件,层次化地建立系统的体系结构.

Real-Time System

What is a Safety-critical System?

Faults are defects or situations that can lead to failures.
Failure is a situation in which a system (or part of a system) is not performing its intended function.
Hazard is a set of conditions and/or events that leads to an accident.
Accident is a loss of some kind, such as injury, death, or equipment damage
Risk is a combination of the likelihood of an accident and its severity: risk = p(a) * s(a)

什么是实时系统Real-Time System

实时系统被定义为：“系统的正确性不仅取决于计算的逻辑结果，而且还取决于结果产生的时间的那些系统”

Timeliness 实时性

行动的及时性与满足时间限制（如截止日期）的行动有关。最后期限可能是硬的，也可能是软的。错过硬性截止日期构成某种系统故障，因此必须非常小心地确保所有此类操作及时执行。时效性的重要建模关注点是对执行时间、截止日期、到达模式、同步模式和时间源进行建模。
及时性要求可以通过首先确定事件响应行动序列的端到端性能要求来解决。这些通常在用例或上下文分析期间确定。

Concurrency 并发

并发是同时执行多个连续动作链。这些操作链可以在一个处理器（伪并发）或多个处理器（真正的并发）上执行。围绕并发系统的执行的问题与以下方面有关：

• 并发线程的调度特性；
• 传入事件的到达模式；
• 线程必须同步时使用的集合模式；
• 以及控制对共享资源的访问的方法。

Predictability 可预测性

许多实时系统的一个关键方面是它们的可预测性。

correctness and robustness 正确性和稳健性

当一个系统一直在做正确的事情时，它就是正确的。当这样的系统在新的（计划外）情况下做正确的事情时，即使在系统的某些部分出现计划外故障的情况下，它也是稳健的。一个人必须警惕僵局、比赛条件和其他特殊情况。
死锁必须满足四个条件：

• 任务声明对共享资源的独占控制。
• 任务在等待其他资源释放的同时保留资源。
• 任务不能被迫放弃资源。
• 存在循环等待条件。

Modeling Actions and Concurrency

通常使用的两种类型的时间约束有硬约束和软约束：
硬约束：不能满足约束是致命的错误。验证系统始终满足时间限制。

• 确定性约束
• 概率约束
• 一些有用函数方面的约束。

软约束：延迟完成是不可取的，但通常不会致命。没有验证或只有演示工作满足某些统计约束。偶尔错过最后期限或中止执行通常被认为是可以容忍的。通常以概率术语指定

在实时配置文件中，动作可能具有中所示的与时间相关的属性：Priority,Blocking Time,Ready Time,Delay Time,Release Time,Preempted Time(抢占时间),Worst-Case Completion Time,Laxity,Absolute Time,Relative Deadline,start,end,duration,isAtomic

Modeling Schedulability

使用了许多不同种类的调度策略。调度策略可以分为两类：公平策略和优先级策略。
两个相互竞争的概念是重要性和紧迫性。重要性是指完成特定操作以纠正系统性能的价值。一项行动的紧迫性是指该行动的最后期限临近，而不考虑其重要性。
Cyclic Executive 循环执行器:调度器在一个无休止的循环中运行一组任务（每个任务都要完成）。任务集在启动时已修复。
Time-Triggered Cyclic Executive 时间触发的循环执行器:与循环执行相同，只是循环的开始是响应时间事件而开始的，因此系统在循环之间暂停。
Round Robin 循环播放:任务一旦启动，就会运行，直到它自愿将控制权交给调度程序。任务可能在运行过程中产生或终止。
Time-Division Round Robin 时分循环:一种循环，如果每个任务没有自愿放弃控制，就会在指定的时间段内中断，称为时间片。
Rate Monotonic Scheduling 速率单调调度（RMS）:假设所有任务都是周期性的，其截止日期为周期结束时。优先级被指定为设计时间，因此周期最短的任务具有最高优先级。
Deadline Monotonic Scheduling 最后期限单调调度（DMS）:与RMS相同，只是没有假设截止日期在周期结束时，并且在设计时根据任务截止日期的短时间分配优先级。
Deadline Monotonic Scheduling 最大紧急程度优先（MUF）:优先级是在任务准备运行时根据任务截止日期的接近程度分配的——截止日期越近，优先级越高。
Earliest Deadline Scheduling 最早截止时间安排（EDS）:延迟定义为截止时间减去剩余任务执行时间。LL调度将较高的优先级分配给较低的松弛值。
Least Laxity 最小松弛度（LL）:MUF是LL和RMS的混合体。关键任务集使用RMS调度下的最高优先级集运行，其余（不太关键）任务使用LL调度，以较低优先级运行。

三个关键要求

1.可预测的操作系统时序行为
操作系统服务执行时间的上限
中断被禁用的短时间，
2.操作系统必须快速
3.操作系统必须管理时间和调度
操作系统可能必须知道任务的最后期限；（除非计划是离线完成的）。
操作系统必须提供高分辨率的精确时间服务。

Real-Time schedule algorithms

Real-time Task

任务：它从读取输入数据及其内部状态开始，以生成结果和更新内部状态结束。
调用时没有内部状态的任务称为无状态任务，否则称为有状态任务。
任务：一系列类似的工作
周期性任务（p，e）
它的工作定期重复
周期p=内部释放时间（0<p）
执行时间e=最大执行时间（0<e<p）
利用率U=e/p

Real-Time Scheduling

指示实时系统（一组实时任务）是否能在截止日期前完成的属性
确定实时任务执行的顺序
静态优先级调度
动态优先级调度

Fixed-priority algorithm-Rate-Monotonic (RM)

最优静态优先级调度
它根据期间分配优先级
周期较短的任务具有较高的优先级
以最短的周期执行作业

最初的速率单调方法有几个限制：
所有任务都是相互独立的（例如，它们不相互作用）
所有任务都是周期性的
没有任务可以阻止等待外部事件。
所有任务共享一个共同的发布时间（按关键时刻计算）
所有任务都有一个与其周期相等的截止日期。

Dynamic-priority algorithm-Earliest Deadline First (EDF)

最优动态优先级调度
期限较短的任务具有较高的优先级
在最早的截止日期执行作业

UML 相关知识

Rapid Object-Oriented Process Embedded System(ROPES)

开发过程被划分为大型活动或阶段，以简化和澄清需要做什么以及何时做。这些阶段如下：
分析：包括识别所有可能的正确解决方案的基本特征。

	需求分析
	系统分析
	对象分析。

设计：在优化某些标准的基础上，将定义特定解决方案的元素添加到分析中。

建筑设计
机械化设计
详细设计

翻译：创建一个可执行的、可部署的设计实现。
测试：验证翻译是否与设计等效，并验证实现是否满足分析中确定的所有正确性标准。

原型

原型是系统模型的一个实例。在软件环境中，它们在某种意义上几乎总是可执行的。

原型可能是丢弃的，也可能是迭代的。一次性原型是指最终不会出现在最终产品中的原型。例如，通常使用GUI构建工具来构建用户界面的模型，以向一组用户提供计划界面的早期暴露。
特别是，任何开发过程的主要目的都是执行以下操作：

• 提高最终产品的质量；
• 提高开发工作的可重复性和可预测性；
• 减少以所需质量水平开发最终产品所需的努力；

为了实现其主要目的，开发过程由阶段、活动和工件组成。

需求分析

需求分析的基本活动如下：

• 确定用例和相关参与者
• 使用以下关系分解用例：
  – 一般化
  – 使用（或包括）
  – 延伸
• 识别和描述影响系统的外部事件
• 定义捕获系统动态行为的行为场景。
• 确定所需的约束条件：
  – 与其他系统的所需接口
  –性能约束

第一个工具是用例。如前所述，用例是系统的端到端、外部可见的内聚行为。他们通常可以通过与客户交谈来识别。大多数系统由三种用例组成：

• 主要用例是最明显的，并捕获典型的外部可见功能。
• 次要用例不太常见，但仍然确定了重要的功能部分。
• 有时也可以识别与安全相关的用例。然而，大多数情况下，安全性和可靠性问题都是在前面提到的用例类型中解决的。除了正常功能外，当系统还充当另一个系统的安全监视器或启用程序时，就会出现这些用例。

场景是用例的实例。
与系统相关的事件及其属性的识别也在需求分析过程中完成。此分析包括参与者发送给系统的消息和事件，以及系统对这些消息的响应。此级别的每条消息的性能属性包括以下内容：

• 相关演员：
  – 消息的发件人
  – 响应接收者
• 到达模式（周期性或偶发性）
• 消息的到达时间：
  – 周期性消息的周期和抖动
  – 偶发消息的最小到达间隔或突发长度
• 消息响应属性：
  – 硬截止日期消息的截止日期
  – 软截止日期消息的平均响应时间
• 消息状态信息：
  – 消息的先决条件不变量
  – 协议（可接受的消息序列）
  – 消息数据
  – 响应的后条件不变量

在需求分析中使用了两种不同类型的建模元素：上下文和行为。
上下文元素定义如下：actors（存在于系统范围之外的对象）、“系统对象”、用例、用例关系、外部消息（包括事件）、危害
行为元素包括以下内容：约束，例如：性能要求，容错时间；状态图，包括：状态，过渡；情节；actor系统交互中的消息协议

系统设计

系统分析是大型复杂实时系统的一个重要阶段，如航空航天和汽车应用。系统分析通常阐述关键算法，并将需求划分为电子、机械和软件组件。通常，行为建模工具（如Statemate）用于构建可执行模型和探索系统动力学。

系统分析的主要活动是

• 确定复杂系统的大规模组织单位；
• 为组织单位建立和分析复杂的行为规范；
• 将系统级功能划分为的三个工程学科
  – 软件
  – 电子学
  – 机械师
• 用可执行模型测试行为；

对象分析的主要活动是

• 应用对象识别策略来揭示系统的基本对象；
• 对对象进行抽象以识别类；
• 揭示类和对象是如何相互关联的；
• 构建满足用例行为需求的对象协作机制；
• 定义反应对象的本质行为；
• 识别对象的基本操作和属性；
• 用场景测试已确定的机制；
• 将端到端性能约束分解为类运算的性能约束；

设计定义了在某种意义上“最优”的单个特定解决方案。例如，设计将识别以下内容:

• 哪些对象是活动的（并发模型）；
• 应用程序任务调度策略；
• 可部署组件内的类和对象的组织；
• 处理器间通信介质和协议；
• 将软件组件分发到节点（特别是如果跳过了系统分析步骤）；
• 关系实现策略（应该如何实现关联——指针？引用？TCP/IP套接字？）；
• 状态机的实现模式；
  – 多价值角色的管理（即1-*关联）；
  – 错误处理策略；
  – 内存管理策略；

Architectural Design-Activities

ROPES过程确定了架构的五个重要视图：子系统和组件、并发和资源、分发、安全性和可靠性以及部署。
体系结构设计中的主要活动是

• 线程的识别和表征；
• 软件组件的定义及其分布；
• 设计模式的应用
  – 全局错误处理；
  – 安全处理；
  – 容错；

由于设计模型是分析模型的细化，因此它由相同的一组元素组成。基本元素是协作、类、对象及其关系。架构设计中特别关注的是节点、组件和活动类。节点和组件捕获物理部署体系结构。活动对象是线程的根对象。它们构成UML并发模型的基础。

Mechanistic Design-Activities

在机械设计中，通过添加其他对象来细化对象协作的细节。例如，如果控制器必须管理许多挂起的消息，则可以应用容器迭代器模式。这导致插入容器（例如用于保存消息的FIFO队列）和迭代器，这些迭代器允许操作该容器。容器和迭代器类充当“粘合剂”，以促进协作的执行。

Detailed Design

详细设计是设计的最低级别。它涉及单个类的内部结构和行为的定义。
典型系统中的大多数类都足够简单，不需要太详细的设计。然而，即使在那里，也必须定义关联、聚合和组合的实现。此外，必须指定操作的前置和后置条件不变量、类的异常处理模型以及属性的精确类型和有效范围。对于一些小的类集，必须澄清复杂的算法。

Translation

转换阶段将UML模型转换为源代码，并通过编译器转换为可执行系统。在翻译开发微循环中，翻译或多或少是自动进行的。在详细方法中，开发人员必须将UML模型元素映射到编程语言元素。
ROPES过程在此阶段还包括单元测试。单元测试是一组白盒测试，确保被测试的单元实际上是内部正确的，并且符合设计。这通常由单元测试计划和单元测试过程文档组成，并最终形成单元测试结果文档。单元测试计划通常围绕类的基本单元组织。文档通常在包或组件级别编写。

Testing

ROPES过程中的测试阶段包括集成和验证测试。测试将一组测试向量应用于具有可观察结果的应用程序。测试向量主要基于需求和对象分析阶段确定的场景。产生的工件是经过测试的应用程序，并显示了缺陷。
所有测试都应根据测试计划并严格按照测试程序文件执行。在集成测试中，通过一次添加一个组件来构造系统。在添加新组件的每个点上，测试通过添加该组件创建的接口。验证测试由测试团队定义，并表示在早期完成的一组需求和系统分析。验证测试基本上是黑盒。唯一的例外是安全方面的测试。这些测试是白盒测试，因为通常需要进入系统内部并破坏某些东西，以确保安全操作正确执行。

时间自动机 Timed automata

时间自动机是一种用于实时系统建模和验证的理论。具有相同目的的其他形式化的例子是定时Petri网、定时过程代数和实时逻辑。
已经开发了几种模型检查器，其中时间自动机是其输入语言的核心，例如。可以公平地说，它们一直是该理论应用和发展的推动力。

时间自动机本质上是用实值变量（时间系统）扩展的有限自动机（即包含有限个节点或位置集和有限个标记边集的图）。

• 变量对系统中的逻辑时钟进行建模，当系统启动时，逻辑时钟初始化为零，然后以相同的速率同步增加。
• 时钟约束即边缘上的保护用于限制自动机的行为。
• 当时钟值满足边缘上标记的保护时，可以采用由边缘表示的过渡。进行转换时，时钟可以重置为零。

可达性分析也许，关于定时自动机，最有用的问题是给定最终状态或一组最终状态的可达性。这样的最终状态可以用于表征系统的安全特性。

已经有许多基于时间自动机开发的工具来建模和验证实时系统，特别是Kronos和UPPAAL。
UPPAAL是一个用于建模、模拟和验证时间自动机的工具箱，基于前面章节中介绍的算法和数据结构。该工具于1995年首次发布，此后一直由乌普萨拉大学和奥尔堡大学合作开发和维护。

UML Profile

概要文件是一个定型包，其中包含通过使用定型、标记定义和约束扩展元模型而为特定领域或目的定制的模型元素。概要文件可以指定它所依赖的模型库以及它所扩展的元模型子集。

UML概要文件是用补充信息扩充UML模型的工具。此机制可通过以下两种方式之一使用：
1.它可以用来扩展UML语言。例如，UML不提供显式信号量概念，但可以通过重载现有的UML概念（如Class）来添加它。结果是一种特殊的类，除了标准的类语义外，还包含了信号量语义。
2.它可以用于为辅助目的（如模型分析或代码生成）所需的模型附加额外信息。例如，可以使用这样的注释来指定类的某些操作的最坏情况执行时间，这可能是分析应用程序的时序特性所需要的。