嵌入式控制系统设计/系统复杂性分类
本章将讨论系统复杂性问题。
什么是系统复杂性？
在处理分类问题之前，重要的是定义复杂性的含义。有人可能会认为，系统越大，越复杂。让我们来看一个例子。
一位电工要为两栋建筑物布线。一栋是小房子，另一栋是公寓楼。显然，为第二栋建筑物布线需要更多工作，并且后者的保险丝盒看起来更复杂，但关键思想是相同的：将电输送到灯泡和插座。插座的数量无关紧要。如果您能为一个插座布线，您就能为一千个插座布线。规模更大，但复杂性相同！
从这个角度来看复杂性，很明显复杂性不是由规模（在本例中是导线的数量）定义的。
在本章中，复杂性由异步子系统的数量及其不同的通信和同步需求来定义：两个并行运行的活动之间的每一次信息交换都会以某种方式干扰这两个正在运行的进程，并且以可预测的方式处理这种干扰并不容易。 （这些方面在关于异步活动的章节中进行了更详细的解释。）从这个角度来看，房子和公寓楼都属于非复杂系统，因为只有一个系统，不需要通信。
如何对复杂性进行分类？
这里给出了使用上述定义进行分类的一种可能的分类。
- 集中式硬件 - 集中式控制 (C1)：在这种系统中，所有信息都集中在一个地方。不需要操作系统。这些系统可以由一家很小的公司的一到两位工程师设计和开发，因为整个设计和开发都可以容纳在一个人的头脑中。
- 分布式硬件 - 集中式控制 (C2)：这些系统由多个较小的系统组成。每个子系统都有自己的控制单元。但每个子系统都与主计算机通信，主计算机负责系统的所有决策。这些系统需要一个团队，比如，一家大型公司中的十几个工程师。专业化通常是不可避免的。
- 分布式硬件 - 分布式控制 (C3)：这些系统也由多个子系统组成，但每个系统都可以做出自己的决策，因此不需要中央主计算机。这些是最复杂的系统群，数百名开发人员需要共同努力，可能在许多不同的公司。
这种分类的目标不是要详尽无遗或完整，而是要让技术项目经理对各种嵌入式系统的复杂性（以及成本）有一个初步的了解，以及对每种类别中系统可以预期的技术和管理挑战有一个了解。
这类系统的例子包括自动售货机、电梯控制器、传送带、交通栏杆等。控制这些系统的一个非常重要的元素是可编程逻辑控制器 (PLC)。它是简单系统接口和控制背后的传统设备。
这类嵌入式系统（更确切地说，是嵌入式设备）的特点如下
- 它有一个单一处理器，通常是嵌入式类型。
- 所有硬件外设都通过直接信号线连接到处理器板。
- 硬件接口可以通过内存映射 I/O进行。
- 软件包含一个单一线程，该线程一遍又一遍地执行相同的程序循环。
- 因此，它不需要操作系统。
- 该设备用于非常明确的任务，在非常明确的环境中，也就是说，几乎不需要适应或变化。
机器人或机床控制器是这类系统的典型代表。
这类嵌入式系统的特点如下
- 它有一个单一处理器，PC 类型，在某些硬件外设中可能还有多个嵌入式处理器。
- 某些硬件外设通过现场总线连接到处理器板。
- 这种类型硬件的接口需要一个软件堆栈来接收和发送现场总线上的消息，以及解释消息内容。
- 一些外围硬件使用中断。
- 软件包含多个线程（共享内存）或多个进程（在受保护的内存空间中运行），它们各自执行自己的程序，但需要彼此之间进行同步和数据交换。
- 因此，需要操作系统。
- 该设备具有可重新编程功能，使其能够在相当明确的环境中完成各种任务。
机器人多代理系统、空中交通管制系统或机场行李处理系统是这类系统的典型代表。
这类嵌入式系统的特点如下
- 整个系统由围绕多个子系统的软件和通信层组成，每个子系统本身都属于前面几类中的某一类。
- 每个子系统通常具有多个处理器，嵌入式和PC 类型。
- 子系统通过各种网络技术进行通信，例如有线或无线以太网、无线通信等。
- 通信通常是异步的。
- 通信软件需要广泛的协议，这些协议对控制整个系统的知识进行编码。
- 一些外围硬件使用中断。
- 软件包含多个程序，面向服务的架构类型。
- 各个子系统可以使用多个操作系统。
- 整个系统具有广泛的可重新编程功能（甚至可以动态替换子系统或其软件），使其能够在非常不同的环境中完成各种任务。
在设计这类系统时，强烈需要模型驱动的工程。您需要能够将系统划分为子系统并划分功能，因为您在不同的开发团队中工作。但是，目前还没有足够的模型可用。
处理复杂性
在设计复杂系统时，会遇到一些问题。
处理复杂性的一个关键方面是，系统的用户不应面对系统的复杂性。这似乎不是问题，因为您可以让系统像黑盒子一样工作。不幸的是，大多数系统都需要监控。事实证明，这是一个问题，因为接口需要尽可能简单，但仍然需要提供正确的信息量。
三里岛事故说明了前面的说法。三里岛反应堆的一个组件停止工作，导致许多其他系统组件也关闭。控制室的指示灯显示了这些问题，操作员突然被大量信息淹没，其中大部分信息无关或误导性。操作员错误地解释了指示灯，并感到非常困惑，以至于做出了错误的决定，导致了部分堆芯熔毁。
解决这个问题的一种可能方法是监控功能而不是组件。只有当功能出现问题时，才需要查看组件。
随着复杂性的增加，故障的风险也会增加。更多的交互会导致更高的错误风险，而更大的复杂性会让用户更难发现问题所在。对于错误，有三种可能的反应
- 找到错误以防止灾难
- 看看您首先应该做什么来修复系统组件
- 找到导致系统故障的设计错误
复杂性示例：汽车
起初，汽车只不过是一辆由发动机驱动的战车。没有涉及异步子系统，也没有计算机参与决策。很明显，当使用前面解释的概念时，这种类型的车辆属于类型 1 的非复杂系统。
多年来，汽车发生了很大的演变。从 80 年代开始，汽车中越来越多地使用计算机。有 ECU、ABS 和 ESP 单元，甚至还有一个调节空调的计算机。这些都是异步子系统，使汽车成为类型 3 的系统。（注意，您可以找到将汽车声明为类型 2 系统的论据。）
多年来，用户界面并没有真正改变。仍然有方向盘、换挡杆以及一些显示冷却液温度、燃油液位和机油压力的仪表。这很好地说明了，不向用户展示车辆的全部复杂性是可能的。
还有一种可能的第四类集中式硬件和分布式控制系统。现代汽车很难归类为上述任何一种系统，但它可能正在发展成为这种第四种系统。汽车的主计算机需要同时运行多个程序。这些程序之间没有任何交互。