本书的原著为：《Design Patterns for Embedded Systems in C ——An Embedded Software Engineering Toolkit 》，讲解的是嵌入式系统设计模式，是一本不可多得的好书。
本系列描述我对书中内容的理解。本文章描述嵌入式安全性和可靠性模式之六：受保护的单通道模式。
受保护单通道模式 (Protected Single Channel Pattern) 是对通道模式的一种简化扩展，在该模式中，在一个或多个 具体的数据转换 阶段添加了数据检查机制。它提供了轻量级的冗余保护，但通常情况下，一旦检测到故障，就不能继续提供服务。
摘要
受保护单通道模式 通过单一通道处理一系列操作，包括从传感获器取数据、数据转换以及执行器驱动等。该模式通过在通道的关键点增加检查机制来增强系统的安全性和可靠性，而这可能需要额外的硬件支持。由于只有一个通道，当出现持续性故障时，该模式将无法继续正常运行，但它可以检测到瞬态故障并有可能对其进行处理。
问题
冗余设计的成本不仅体现在开发工作的复杂度上，同时也涉及硬件冗余带来的额外支出。在某些情况下，完全冗余的通道可能并非必需。例如，如果系统有一个已知的故障安全状态 (在这个状态下能保证系统必然是安全的)，那么系统只需要有能力检测到故障并转入该状态即可。这样做虽然降低了系统的可靠性级别，但可能仍能满足用户的实际需求。
模式结构
模式结构图如下所示：
与上文 通道模式 的模式结构图相比，这里所做的只是在某些转换步骤中添加了一些检查。实际上，这些检查不必在单独的类中实现，也可以直接在 具体转换类 内部实现。这些检查可以是任何形式的检查，例如：
- 范围检查（数据是否在所需的范围内？）
- 合理性检查（数据是否处于当前情境下的预期范围内？）
- 一致性检查（数据值是否与其他同时计算的数据值保持一致？）
- 反向转换检查（能否从输出值重新计算得到输入值？）
- 数据有效性检查，就像我们在之前的 反码模式 和 循环冗余校验模式 中看到的那样。
模式详情
传感器驱动
从一个或多个传感器获取物理数据，并将其放入通道进行处理。
抽象的数据转换
这是一个概念性示意图。在面向对象的语言或实现中，可以使用真正的泛化（即继承）机制，但在 C 语言中，更多的是作为一个概念性想法来表述意图，而非直接指导实现细节。此类有两个可选 关联：
- 自身关联：即列表中的下一个转换步骤。这表示有一系列数据转换步骤，前一个转换的输出是下一个转换的输入。
- 输出执行器驱动关联：直接指向输出设备驱动。
此外，抽象的数据转换类 还有一个可选的关联类：抽象的转换检查类。在数据转换链中有必要进行检查的地方，会使用这个类。这意味着在数据处理过程中，可在特定转换点插入检查机制，确保数据的正确性和合理性。
抽象的转换检查
与 抽象的数据转换 类似，这是一个概念性示意图，是一个泛化机制。代表一种能够检查当前状态中处理过程或数据有效性的元素。
具体的数据转换
此类负责对输入的数据值（来自传感器或前一个 具体的数据转换类 ）执行数学变换，并生成输出结果（发送给序列中的下一个 具体的数据转换类或者 执行器驱动）。在简单情况下，可能只需要单一的 具体的数据转换类，但在更为复杂的应用场景中，可能存在多个不同的具体数据转换类。每一个具体的数据转换类都会对数据进行特定的处理和转换，从而构成整个数据处理通道的核心部分，确保数据在传输过程中逐步转化成适合执行器驱动设备所需的形式，最终驱动物理动作或控制设备行为。
在数据转换链中，某些特定的 具体的数据转换类 构成了检查点，即会在这些点检查数据转换的有效性。对于这些情况，会与特定 具体的转换检查类 进行关联。
关联：UML 中的 关联 表示类与类之间的连接，关联关系使一个类知道另外一个类的属性和方法。这里
具体的数据转换类知道具体的转换检查类的函数(即：check() 函数)，转换类对象调用检查类提供的方法来检查数据的合法性。
具体的转换检查
这是一个特定的数据 转换检查类，其作用是在转换链中的某一特定节点上核查数据转换是否有效。
执行器驱动
这个类利用计算出的输出值来驱动一个或多个执行器，例如电动机、灯光或加热装置等。
效果
一般来说，使用 受保护的单通道模式 具体有以下优点：
- 故障识别：提供了清晰的方法来检测和定位数据处理过程中的故障。通过在转换链中设置检查点，能够及时发现并隔离问题。
- 容错：可以在检测到故障后转至安全状态，在发生错误时能够维持系统的健壮性。
采用这种模式也有其固有的缺点：
- 资源消耗增加：额外的内存（包括代码空间和数据存储）、计算时间以及硬件需求，这些都取决于对通道的具体利用程度。
- 复杂性上升：随着数据通道内元素数量和类型的增长，管理及协调各个转换步骤、转换检查的复杂性也随之提高。
实现策略
该模式可以通过真正的泛化实现，但在 C 语言等编程环境中，通常会将 抽象的数据转换 视为某种 具体的数据转换 类的占位符；
数据流经通道的方式主要有两种主要策略：
- 串行处理：最简单的方法是对获取的一个数据元进行一系列的转换，并在获取下一个数据元之前将其输出到执行器（actuator）。在这种情况下，数据按照顺序逐个经过各个转换阶段。
- 并行处理：而在更高带宽的应用场景中，同一时间可能有多个数据实例存在于通道内，对于每一个转换阶段都有一个对应的数据实例。这样，数据从一个转换传递到下一个转换的同时，所有其他的数据实例也都在同步进行传递。这意味着多个数据可以同时在不同的转换环节被处理，提高了系统的吞吐量和实时性。
此外，数据检查也可以直接嵌入到某些转换步骤中，而不是作为一个独立的类来实现。
相关模式
这个模式提供了一种中等到大规模的冗余机制，它是基于之前章节讨论过的 通道模式 发展而来的众多模式之一。在作者的另一部著作《Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems》中，深入探讨了多种此类设计模式。
该模式中的 数据转换检查 可以通过其他基础模式来实现，例如早先提及的 反码模式 和 循环冗余校验模式 。
实例
见原书。
读后有收获，资助博主养娃 - 千金难买知识，但可以买好多奶粉 (〃‘▽’〃)
