2、实时Ada应用的架构视角

实时Ada应用的架构视角

1. 实时架构分类概述

在实际的实时系统中，基本的软件架构从高层次上可分为四大类，尽管每一类中存在许多变体，但每一类都能从系统资源（如CPU、内存、I/O和通信）管理的角度进行较为具体的描述，这决定了应用程序满足时间约束的能力。这四大架构类型分别为：
1. 时间线（Timeline）
2. 事件驱动（Event - Driven）
3. 管道（Pipeline）
4. 客户端 - 服务器（Client - Server）

下面我们将分别对这四类架构进行详细讨论。

2. 时间线架构（Timeline）

时间线架构是最古老且概念上最简单的实时架构。它有时被称为基于帧的架构，因为它使用固定的时间帧，在这些帧内，所有应用程序过程按预定顺序执行。它也被称为循环执行架构，因为它使用一个简单的时间驱动执行器，通过帧序列表来管理所有应用程序过程的调用。

时间线架构的工作原理是将应用程序划分为一组固定的过程，由一个相对简单的执行器按顺序调用，该执行器由一个设置为固定间隔触发的定时器驱动。每次定时器触发时，执行器使用帧序列表调用适当的过程来处理该间隔内准备好的任务。这些单个的时间间隔称为帧或小周期，帧被分组为一个固定的序列，在系统执行过程中不断重复，这样的一组帧称为大周期。

例如，有一个简单的应用程序由四个周期性过程组成，执行速率分别为40 Hz、20 Hz、5 Hz和1 Hz。架构师选择帧（小周期）长度为25 ms，这与最快过程的40 Hz速率相等。为满足所有应用程序速率要求，过程按以下方式分组执行：
| 过程 | 执行频率 | 执行时机 |
| ---- | ---- | ---- |
| 过程1 | 每帧 | 每帧都执行 |
| 过程2 | 20 Hz | 在每个大周期的第一帧中，在过程1之后立即执行，此后每隔一帧执行 |
| 过程3 | 5 Hz | 在第二帧和此后每八帧中，在过程1之后立即执行 |
| 过程4 | 1 Hz | 在第四帧和此后每40帧中，在过程1之后立即执行 |

时间线架构具有以下特点：
- 无需两个过程同时执行，因此不需要显式同步，也没有应用程序级别的上下文切换开销，乍一看似乎效率很高，且系统具有确定性。
- 然而，这些优点在实际中往往是虚幻的。效率和确定性并非实时系统的首要要求，更重要的是创建具有可预测响应行为的架构。而且，消除并发会带来高昂的代价，长任务必须手动拆分为小过程以适应帧，这需要程序员手动创建抢占点并确保任务状态的一致性，而现代实时操作系统可以更自动、可预测地完成这些工作。

下面是时间线架构工作流程的mermaid流程图：

graph TD
    A[定时器触发] --> B[执行器获取帧序列表]
    B --> C{根据帧序列表选择过程}
    C --> D[执行所选过程]
    D --> E{是否完成大周期}
    E -- 否 --> A
    E -- 是 --> A

3. 事件驱动架构（Event - Driven）

事件驱动架构是实时系统中第二常见的架构风格。它等待消息到达、I/O操作完成、定时器到期或外部操作（如按钮按下）等事件的指示。在Ada语言中，这通常表现为会合接受或受保护过程调用。

事件驱动架构由一组任务组成，每个任务等待一个事件，并被赋予一个优先级。任务优先级通常根据时间约束或任务的语义重要性来确定。例如，当事件到达处理器时，中断处理程序首先以中断优先级处理，然后触发一个二级任务以用户定义的优先级运行。

事件驱动架构在应用程序级别引入了并发，这意味着以正确优先级运行的单个操作可能会相互抢占，因此需要使用POSIX互斥锁、信号量或Ada受保护对象等进行同步。同步增加了应用程序架构的复杂性，但并发提高了系统在满足时间约束的情况下的资源利用率。

然而，事件驱动架构存在一个显著问题，即事件（除定时器到期事件外）的突发到达模式导致系统负载在特定时间间隔内无法预测，从而导致不可预测的响应时间。这通常会导致实时系统中最常见的故障类型：间歇性“故障”，这种故障没有痕迹、不可重复，且每次观察到的症状可能不同。为解决这个问题，设计师通常会尝试在足够长的时间间隔内对随机到达事件的总利用率进行分组，但这仍然难以预测单个事件的响应时间。可以使用一些带宽保留算法（如零星服务器）来改善可预测性问题。

事件驱动架构任务处理流程如下：
1. 事件到达处理器。
2. 中断处理程序以中断优先级处理事件。
3. 中断处理程序触发二级任务。
4. 二级任务以用户定义的优先级运行。

下面是事件驱动架构任务处理的mermaid流程图：

graph TD
    A[事件到达] --> B[中断处理程序处理]
    B --> C[触发二级任务]
    C --> D[二级任务运行]
    D --> E{是否完成任务}
    E -- 否 --> D
    E -- 是 --> F[结束]

4. 管道架构（Pipeline）

管道架构与事件驱动架构类似，但它专门用于利用分布式系统。事件在一个处理器上进行初始处理，然后将额外的处理和最终响应推送给系统中同一或其他处理器上的其他任务、进程或线程。

在管道架构中，一个事件通常会引发多个可调度实体的处理，导致网络各部分之间的通信，最终在系统的不同点产生多个输出。从时间约束的角度来看，最重要的性能参数是从事件初始到达至每个响应输出的延迟，即系统的端到端时间约束。

管道架构的控制流随着事件信息从事件源移动到每个输出目的地，这意味着对管道架构的分析必须遵循控制流序列。由于控制流序列的复杂性，难以预测管道系统的响应时间。而且，在管道的每个阶段都会进行单独的调度操作，可调度实体之间会存在竞争，包括处理不同事件的实体以及处理同一事件不同组件的实体。

确定管道架构中每个可调度实体的正确优先级非常困难，因为同一部分的可调度实体可能同时处理多种类型的事件。因此，任务优先级在管道系统中通常只起次要作用，任务优先级更多地由管道流的方向决定。例如，如果任务优先级随着事件在管道中移动而增加，可以最小化每个中间阶段的事件队列。在未来的系统中，有可能根据到达消息的优先级调整管道阶段的优先级，但目前商业系统基础设施中通常不具备这种优先级处理机制。

管道架构的工作流程如下：
1. 事件到达初始处理器。
2. 进行初始处理。
3. 将剩余处理和响应推送给其他可调度实体。
4. 各可调度实体依次处理。
5. 最终输出响应。

下面是管道架构工作流程的mermaid流程图：

graph TD
    A[事件到达] --> B[初始处理器处理]
    B --> C[推送至其他实体]
    C --> D{是否还有后续实体}
    D -- 是 --> E[后续实体处理]
    E --> D
    D -- 否 --> F[输出响应]

5. 客户端 - 服务器架构（Client - Server）

客户端 - 服务器架构与管道架构类似，分布式系统中一个或多个节点上到达的事件根据事件类型在整个系统中进行处理。不同的是，客户端 - 服务器模型的控制流通常与初始事件处理程序保持在同一节点。事件到达初始可调度实体后，后续处理阶段通过从初始任务进行远程过程调用触发，而不是使用单向消息。这意味着任何给定事件的控制中心始终与初始事件处理程序在一起，所有进一步的处理（包括响应）由一个或多个服务器实体完成，这些服务器实体通常位于系统的其他节点上。

客户端 - 服务器架构的响应时间分析方法与管道架构类似，但控制每个事件涉及的实体调度的基础设施有所不同。例如，CORBA标准就使用了这种架构。目前，对象管理组正在完成CORBA的一个重要扩展，即实时CORBA 1.0，它将为实时客户端 - 服务器系统提供优先级传播和调度功能，有望使实时客户端 - 服务器系统的构建和性能分析更加可靠。

目前，即使有CORBA实时扩展，管理客户端 - 服务器系统响应时间的唯一机制仍然是使用优先级。与其他实时架构一样，优先级可以根据响应时间要求或语义重要性确定，但通常发现为消息分配优先级比为任务或线程分配优先级更有效，消息优先级可以传播到客户端。

客户端 - 服务器架构的一个额外优点是相对于管道架构更容易调试。在管道架构中，很难确定给定事件在任何时间点的控制流位置，因此调试事件处理（无论是响应时间问题还是功能问题）都非常困难。而在客户端 - 服务器架构中，由于操作序列完全由单个线程控制，需要进一步分析的故障元素的位置更容易识别。

客户端 - 服务器架构的工作流程如下：
1. 事件到达客户端节点。
2. 客户端节点的初始事件处理程序处理。
3. 通过远程过程调用触发服务器实体处理。
4. 服务器实体处理并返回响应。
5. 客户端接收响应。

下面是客户端 - 服务器架构工作流程的mermaid流程图：

graph TD
    A[事件到达客户端] --> B[客户端初始处理]
    B --> C[远程调用服务器]
    C --> D[服务器处理]
    D --> E[服务器返回响应]
    E --> F[客户端接收响应]

6. 使用Ada语言构建实时架构

在构建实时架构时，可以通过多种方式使用Ada语言，下面介绍几种常见架构类型中使用Ada语言的方法及适用的应用领域。

6.1 时间线架构中的Ada使用

在时间线架构中，主要使用的Ada构造是Ada过程调用。在最简单的系统中，一个小的控制程序（循环执行器）在单个Ada任务中构建，该任务以小周期速率定期执行。在Ada 95中，这个任务使用 delay until 语句来控制每个小周期的时间。循环执行器在每次延迟到期时记录当前小周期编号，并使用帧序列表确定该周期应调用的过程。这样可以避免并发，不需要额外的Ada任务，也不需要优先级、会合、受保护对象、异步控制转移等。

这种架构常用于飞机和导弹飞行控制、许多航空电子任务处理器、工业生产控制器等相对简单的应用。由于对更复杂Ada特性的最小使用，这种方法在需要对应用程序和运行时基础设施进行安全认证的安全关键系统中非常常见。

6.2 事件驱动架构中的Ada使用

事件驱动架构通常使用一组Ada任务为每个事件源或类型构建。对于周期性事件，任务由 delay until 语句控制的循环组成；对于非周期性事件，任务通常由 accept 语句控制的循环组成，该语句由另一个任务的会合或运行时环境的直接中断触发。

设计良好的事件驱动实时应用程序应使用最少数量的任务来处理具有不同时间约束的事件。常见的Ada设计错误包括使用太少的任务（试图在单个任务中处理具有不同时间约束的多个事件）或使用太多的任务（例如，仅为封装而使用任务概念）。Ada任务会引入上下文切换和同步开销，但当它们用于处理不同的时间约束时，这种开销可以很容易地被限制，并且系统在高利用率下可预测地满足时间约束的能力会大大增强。

任务优先级应根据速率单调调度（Rate Monotonic Scheduling）或截止日期单调调度（Deadline Monotonic Scheduling）等调度方法选择，以确保系统的可预测性。正确使用Ada受保护对象进行任务同步和Ada 95实时附件来处理优先级，可以使系统非常健壮，能够满足所有时间约束。对于非周期性事件，使用零星服务器（通常使用 delay 语句与触发事件驱动任务的 accept 语句结合实现）可以限制处理器利用率，避免事件驱动架构在突发负载下出现定时异常。

事件驱动系统架构由于在高资源利用率下满足时间约束的能力大大增强，且维护成本显著降低，现在正逐渐取代时间线系统。但需要安全认证的应用是常见的例外，因为认证机构通常要求使用时间线方法。随着事件驱动方法的可预测性得到更广泛的理解，以及像Ada Ravenscar Profile这样的工具更广泛可用，这种情况预计在未来几年会发生改变。

6.3 管道架构中的Ada使用

管道系统与事件驱动系统类似，通常使用一组Ada任务构建，每个管道阶段对应一个任务。这些任务之间的同步可以使用受保护对象处理，但优先级管理更为复杂。由于管道中可调度实体可能同时处理多种类型的事件，确定每个实体的正确优先级非常困难。目前，任务优先级更多地由管道流的方向决定，未来可能会根据到达消息的优先级调整管道阶段的优先级，但目前商业系统中这种机制并不普遍。

实时Ada应用的架构视角（续）

7. 不同实时架构的对比

为了更清晰地了解各种实时架构的特点，我们可以通过以下表格进行对比：
| 架构类型 | 控制流特点 | 并发情况 | 同步需求 | 响应时间可预测性 | 资源利用率 | 调试难度 | 适用场景 |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 时间线架构 | 固定顺序，由定时器驱动 | 无 | 无 | 理论上可精确确定，但实际受任务拆分影响 | 低，任务需适应固定帧 | 低 | 飞机和导弹飞行控制、航空电子任务处理器、工业生产控制器等简单应用，安全关键系统 |
| 事件驱动架构 | 由事件触发，并发执行 | 有 | 有，如POSIX互斥锁、信号量、Ada受保护对象 | 受事件突发到达影响，较难预测 | 高，并发提高资源利用率 | 中 | 对资源利用率要求高、时间约束复杂的应用，除安全认证要求高的场景 |
| 管道架构 | 事件信息流动，多阶段处理 | 有 | 有，使用受保护对象 | 因控制流复杂，较难预测 | 高，可分布式处理 | 高 | 分布式系统，如雷达系统等 |
| 客户端 - 服务器架构 | 控制流集中在客户端，远程调用服务器 | 有 | 有，使用优先级管理 | 分析方法与管道架构类似，可通过优先级管理 | 高，可分布式处理 | 低 | 分布式系统，如CORBA标准应用 |

8. 实时架构选择的考虑因素

在选择实时架构时，需要综合考虑多个因素，以下是一些关键的考虑点：
1. 时间约束 ：如果系统对时间的确定性要求极高，如飞机飞行控制，时间线架构可能是一个较好的选择。但如果时间约束较为灵活，且需要高资源利用率，事件驱动、管道或客户端 - 服务器架构可能更合适。
2. 资源利用率 ：对于资源有限的系统，需要选择能够高效利用资源的架构。事件驱动、管道和客户端 - 服务器架构通常在资源利用率方面表现较好，但需要处理并发和同步带来的复杂性。
3. 系统复杂度 ：简单的系统可以选择时间线架构，避免复杂的并发和同步问题。而复杂的分布式系统则需要考虑管道或客户端 - 服务器架构，以实现分布式处理和资源共享。
4. 安全认证要求 ：在安全关键系统中，如航空航天领域，时间线架构由于其简单性和可确定性，更容易通过安全认证。而事件驱动架构虽然在性能上有优势，但在安全认证方面可能面临更多挑战。
5. 调试难度 ：如果系统的调试和维护成本是一个重要考虑因素，客户端 - 服务器架构由于其控制流集中的特点，更容易进行调试和故障排查。

下面是选择实时架构的决策流程mermaid流程图：

graph TD
    A[明确系统需求] --> B{时间约束要求高吗?}
    B -- 是 --> C{系统复杂度低吗?}
    C -- 是 --> D[选择时间线架构]
    C -- 否 --> E{是否为分布式系统?}
    E -- 是 --> F{调试难度要求低吗?}
    F -- 是 --> G[选择客户端 - 服务器架构]
    F -- 否 --> H[选择管道架构]
    E -- 否 --> I[选择事件驱动架构]
    B -- 否 --> J{资源利用率要求高吗?}
    J -- 是 --> K{是否为分布式系统?}
    K -- 是 --> F
    K -- 否 --> I
    J -- 否 --> D

9. 实时架构的未来发展趋势

随着技术的不断发展，实时架构也在不断演进。以下是一些可能的未来发展趋势：
1. 智能化调度 ：未来的实时架构可能会引入更智能的调度算法，根据系统的实时负载和事件优先级动态调整任务调度，提高系统的响应时间和资源利用率。例如，管道架构中可能会实现根据到达消息的优先级自动调整管道阶段的优先级。
2. 融合架构 ：不同的实时架构可能会相互融合，以充分发挥各自的优势。例如，将事件驱动架构的灵活性与时间线架构的确定性相结合，创造出更高效、更可靠的实时系统。
3. 硬件支持 ：硬件技术的发展将为实时架构提供更好的支持。例如，新型的处理器和内存技术可能会降低上下文切换和同步的开销，使并发处理更加高效。
4. 安全增强 ：随着实时系统在关键领域的广泛应用，安全将成为一个更加重要的考虑因素。未来的实时架构可能会集成更多的安全机制，如加密、认证和访问控制，以确保系统的安全性和可靠性。

10. 总结

实时系统的架构选择对于系统的性能、可靠性和可维护性至关重要。时间线架构、事件驱动架构、管道架构和客户端 - 服务器架构各有其特点和适用场景。在实际应用中，需要根据系统的时间约束、资源利用率、复杂度、安全认证要求和调试难度等因素综合考虑，选择最合适的架构。

同时，随着技术的不断进步，实时架构也在不断发展和创新。未来的实时架构将更加智能化、融合化，并提供更好的硬件支持和安全保障。通过深入了解各种实时架构的特点和发展趋势，我们可以更好地设计和构建高效、可靠的实时系统。

希望本文对您理解实时架构和Ada语言在其中的应用有所帮助。如果您在实际应用中遇到任何问题或有进一步的探讨需求，欢迎随时交流。

以下是不同实时架构的特点总结列表：
- 时间线架构：古老简单，按固定顺序执行任务，无并发和同步需求，但资源利用率低，适用于简单和安全关键系统。
- 事件驱动架构：由事件触发，引入并发和同步，资源利用率高，但响应时间较难预测，适用于复杂时间约束和高资源利用率需求的场景。
- 管道架构：适用于分布式系统，事件多阶段处理，控制流复杂，响应时间和优先级管理困难。
- 客户端 - 服务器架构：控制流集中在客户端，便于调试，适用于分布式系统，可通过优先级管理响应时间。