下载掌阅APP，畅读海量书库
立即打开
如前所述，计算系统已经逐步成为现代信息社会基础设施的重要组成部分，例如，列车、核电以及汽车等计算系统为我们的日常生活和社会生产活动提供各类服务。与此同时，这些系统大都应用在安全关键领域。因此，在进行系统设计时，我们有必要确保这些系统是正确且值得信任的，特别地，当系统出现故障或遭受攻击时，我们需要保证这些故障或攻击所带来的后果不会对人类造成伤害或对财产造成损失。
正确性意味着系统设计过程及其结果符合预期的需求。确保正确性的常用方法主要有形式化验证技术和测试技术。前者以系统需求为依据，通过严格的形式化验证算法，判断系统的设计模型是否符合给定的需求；而测试技术则在特定的输入条件下，对实际系统的行为进行分析，判断给定的需求是否得到满足。通常，测试技术只能对系统的部分行为进行检测，无法实现系统行为的完整性遍历。理论上，完备的系统行为遍历只能通过形式化验证才能实现。
当然，“我们是否构建了正确的系统”与“我们是否构建了与预期需求一致的系统”这两个问题是相对的。如果我们能够正确、可靠且完备地进行需求的形式化描述，并且我们能够构建一个准确刻画系统行为及其与环境交互的系统模型，那么构建与需求一致的系统也就意味着构建了正确的系统。
学术界通常使用术语“ 可信性（trustworthiness） ”来刻画系统的正确性。可信性描述了在特定情况下系统的行为能够被信任的程度。“可信”意味着，尽管在运行过程中会出现各种非预期事件，系统仍然具备按照预期方式运行的能力；与之相反，“不可信”意味着系统无法按照预期的方式运行，或无法提供预期的功能。影响系统可信性的典型非预期事件主要包括：（a）硬件平台的故障或失效；（b）软件设计和实现错误；（c）与外部环境的不确定性交互，如环境干扰和不可预测的突发事件等；（d）与潜在攻击者的恶意交互，如入侵行为和威胁等。图2.1所示为其部分示例。其中，只有软件设计和实现错误是软件层面的事件，其他均在系统层面，发生在系统与外界环境或人的交互过程中。
对于计算系统而言，可信性是一个综合的概念，通常可以通过一组系统属性来定义，表示用户对系统按照预期运行的信心程度 [1] 。在部分文献里 [1-2] ，可信性和 可信赖性（dependability） 这两个术语可以互换使用。可信赖性通常被定义为“提供合理的可信任的服务的能力”，其目标是提供合理的可信任的服务，并避免用户无法接受的服务中断。具体来说，可信性既包括功能安全属性，也包括其他定性或定量描述系统正确性的信息安全属性和效率属性等。
图2.1 影响系统可信性的典型非预期事件
（1）功能安全属性（functional safety property） ：表示系统运行过程中不会发生导致灾难性后果的事件。这个属性刻画了系统能够正确运行，并能够应对自身故障或外界环境干扰等非预期行为的韧性。这些行为往往是非人为主观因素造成的。例如，车辆的 防抱死制动系统（Antilock Brake System，ABS） 用于防止车轮在制动时抱死，其典型的功能安全属性是，当一个车轮的旋转速度明显慢于其他车轮时，该车轮制动器的液压压力必须在几分之一秒内降低。从系统状态空间的角度来看，所有违背系统功能属性的状态都可以定义为不安全状态，那么满足功能安全属性意味着系统在运行过程中不会进入这些不安全状态。
（2）信息安全属性（information security property） ：刻画了系统能够应对外界攻击或威胁等恶意行为的韧性。这些行为往往是人为因素造成的，通常是针对数据机密性、完整性、可用性以及不可否认性等属性的攻击行为。 机密性 表示系统服务和信息不会暴露或泄露给未经授权的用户； 完整性 表示系统状态和信息不会被恶意更改； 可用性 是指授权用户能够及时访问并按要求使用系统服务，简单地说就是，保证系统服务在需要时能为授权者所用，防止由主客观因素造成的系统拒绝服务； 不可否认性 是指系统用户不能否认或抵赖其完成的操作和承诺，简单地说就是，服务请求方不能否认发送过请求，服务提供方不能否认提供过服务。例如，在银行系统中，机密性意味着只有客户或其授权人员才能进行交易并查看与该客户相关的信息；完整性意味着当客户存入500元时，他的账户应该增加500元，而不是更少或更多；可用性意味着银行系统能够给用户提供正常的业务服务，防止拒绝服务攻击；不可否认性意味着系统或用户对个人账户的任何操作都不能被否认。由于攻击者恶意行为的不可预测性，这类信息安全属性通常难以进行形式化描述和分析。
（3）效率属性（efficiency property） ：刻画了系统持续提供可靠、可用服务的能力，通常包括服务的 性能 和 可用性 。性能表示系统在满足用户需求方面的能力，通常表现在吞吐量、抖动和延迟等方面，例如，系统处理一个请求需要多长时间？一段时间内可以执行多少个请求？可用性则根据系统的处理器效率以及能耗等方面的指标，衡量系统资源的使用效率。效率属性往往可以表述为关于系统资源参数（内存、能耗、时间）的优化条件，以实现系统性能和可用性最优化。
需要注意的是，功能安全属性和信息安全属性都是关于系统状态的属性，即系统不能到达“不安全”的状态。然而，效率属性并不是关于系统状态的属性，它刻画了系统在运行过程中，可观测量之间应当满足的关系。此外，功能安全属性和信息安全属性是密切相关的，它们相互影响，在进行系统设计时需要将二者统筹考虑。例如，在车联网中，针对某一辆汽车的信息安全漏洞的攻击可能导致车辆的制动功能失效或者被禁用，从而带来功能安全问题和碰撞风险。一般情况下，一个系统可能存在多个潜在的信息安全漏洞，这些漏洞被称为系统的 攻击面（attack surface） 。对于车联网系统而言，车辆集成的WiFi、蜂窝、蓝牙、USB和其他连接点的安全漏洞都提供了进入车辆通信系统的潜在攻击路径。
总体而言，学术界在可信软件和系统设计领域做出了大量研究成果 [3] 。现有方法一方面采用形式化验证分析可信性属性，但前提是这些属性能够进行有效的形式化描述 [4] ；另一方面使用测试技术对难以形式化描述的可信性属性进行分析，以提升系统的可信程度 [5] 。
当前，可信系统设计所面临的一个关键问题在于，如何应对不确定性。系统在提供满足给定需求的服务的过程中，不可避免地会与外界环境进行交互，并且出现与预期存在差异的系统行为，因而呈现出不确定性。简单来说，不确定性主要有以下两个方面的来源。
（1）外界环境的不确定性 ：这种不确定性或来源于具有时变特性的输入，如吞吐量的变化；或来源于对外界环境的抽象。这是因为外部环境的内在复杂性，使得环境模型的构建只能在某种抽象层次上进行描述和理解。例如，在考虑对系统所面临的潜在的外部攻击威胁进行建模时，由于我们无法预知攻击者所有可能的行为，需要对攻击者的行为进行抽象，因而带来了不确定性。
（2）硬件运行平台的不确定性 ：这种不确定性一方面可能是硬件故障或老化造成的不确定性，另一方面还可能是运行时间的不确定性。这是由于硬件平台往往使用层次化内存结构和预测执行机制，因此，即使简单指令的执行时间也无法精确估计。一般情况下，根据数据的大小和位置，指令执行时间可能在 最佳情况执行时间（Best-Case Execution Time，BCET） 和最坏情况执行时间之间浮动，后者的数量级可能是前者的数十倍。
不确定性直接影响到系统行为的 可预测性（predictability） ，后者决定了哪些关键系统属性（包括定性和定量的属性）能够被严格证明。一般情况下，系统行为的可预测性很难得到保证，主要原因是，广义的系统属性具有不可计算性，我们无法对所有系统属性进行精确的形式化分析验证，往往只能得到近似值。例如，我们可以通过采用时序分析技术计算最坏情况执行时间的上近似值，但该近似值可能比真实的最坏情况执行时间高很多个数量级，因而带来了分析结果的不确定性。不确定性和由此产生的不可预测性，一方面对我们设计系统的方式有着深刻的影响；另一方面也限制了我们设计复杂关键系统的能力。例如，由于缺少精确的系统最坏情况执行时间，因此无法保证系统的实时响应属性。同样，如果不能准确估算系统的负载特性，就无法保证系统的性能和可用性。
可信系统设计所面临的另一个关键问题在于，如何在确保功能安全属性和信息安全属性得到满足的同时，不牺牲系统的效率属性。这对于单一或单核处理器的系统来说相对容易一些，对于多核或分布式系统而言，得到高效且可信的设计要困难很多。系统设计人员需要借助一套有效的理论和方法，从而在多种等效的可信设计方案中，选择出更适合目标计算平台资源的最优设计方案。
最优的设计通常也是 简约的设计（parsimonious design） ，也就是说，设计方案或参数的选择应该仅依据需求来确定。然而，在实际情况下，设计人员通常会根据种种原因，排除可能的简约设计方案，原因之一可能是方案的灵活性很难或不可能在后续的设计中得到复用 [6] 。因此，在早期的设计过程中，设计人员往往倾向于使用特定的编程模型或设计原则来提升设计效率，但是这也大大减少了有效的设计空间。例如，熟悉C语言的设计人员会倾向于使用纯C语言开发编码器，这会导致编码器难以在多处理器平台上并行加速。相反，基于数据流语言的编程则提供了一套有效的调度策略，更有助于提升并行性 [7] 。
简约设计的一个前提条件是，使用适当的编程语言和规范来揭示数据或任务中固有的 并行性（parallelism） 和 不确定性（non-determinism） 。在此基础上，通过选择适当的系统设计参数，可以优化系统实现。例如，依据任务的特征，将不同的任务映射到不同的处理器上，以提升任务处理的并行性，并通过使用调度策略来减少不确定性等。系统设计参数的选择通常可以通过 设计空间遍历技术（design space exploration technique） 来实现 [8] 。目前，该技术大多是基于经验知识的，主要在系统模型上评估不同系统设计参数对性能、能耗等优化指标的影响。这些系统设计参数决定了系统模型的资源配置，如处理器内核的数量和类型、存储器的大小和组织架构，以及调度和仲裁策略等。
根据系统提供的功能和应用场景的不同，系统在出现故障时所带来的后果是不一样的。其中，当系统出现违背功能安全或信息安全属性的故障时，可能对人的生命、环境或其他重要资产等带来灾难性的影响；而其他故障可能只是一种暂时的错误或失效而已，设计人员很容易将其纠正，系统当前的服务可以留待下一阶段，其损失也只是时间和人力问题。根据这些因素我们可以把系统划分为不同的 关键等级（criticality levels） 。关键等级确定了哪些系统属性是必须满足的，并且刻画了违背这些属性所带来影响的程度，如系统特定功能的失效概率或者指定参数的标称值与观测值之间的差异等。
安全关键系统通常分为 功能安全关键系统（functional safety critical system） 和 信息安全关键系统（information security critical system） ，对于这类系统，设计人员需要采用特定的技术来保证系统不出现故障或不遭受攻击。功能安全关键系统包括飞行控制器或核电控制器等，违背安全属性的行为可能来自系统本身，也可能来自系统与外界环境的交互过程。信息安全关键系统（如智能卡）应当具备抵抗外界攻击者的入侵或恶意交互行为的能力。在工业界的实践中，安全关键系统必须根据相关标准规定的流程进行设计开发和认证，如机载系统的DO178B标准、汽车电子系统的ISO26262标准，以及针对IT产品信息安全认证的信息技术安全评估通用标准 [9] 等。目前，由于现有技术的局限性和高昂的开发成本，安全关键系统的设计技术仅适用于小型规模系统，这阻碍了它们在复杂的物联网系统或自主系统等领域的应用。
除功能安全属性和信息安全属性的关键等级之外，其他类型的关键等级可以通过一组特性来定义，这些特性刻画了系统实现相应目标的能力。
任务关键系统（mission critical system） 必须在资源受限的情况下具有完成具体任务目标的能力，例如，航空航天系统或电信系统中的任何故障都会导致一些预期目标失败。
业务关键系统（business critical system） 中的任何故障都会导致高财务损失。通常通过评估特定事件对业务带来的影响来确定相应的关键等级，例如，对于银行数据中心系统，通过评估宕机对数据中心系统运营收入的影响来确定关键等级。
“尽力而为”系统（best effort system） 对故障或者攻击行为不敏感，并且具有快速恢复的能力。尽管会出现故障或遭受攻击，但其影响有限，不会造成灾难性后果。这类系统主要包括互联网或移动互联网上的应用程序和服务，其发展的重点是，在资源可用的前提下，实现资源的优化利用。
随着系统规模的不断增加以及 系统之系统（system of system） 的发展， 混合关键系统（mixed criticality system） 成为一个重要的发展趋势。混合关键系统，顾名思义，既包括安全关键组件，也包括非安全关键组件。通常，这类系统还具有分布式、异构等特点，并且使用不同通信介质。物联网系统是一类典型的混合关键系统。物联网系统旨在通过实现万物互联来提供不同关键等级的服务，例如，用于高效可靠能源分配和管理的智能电网；用于提高交通安全性，并且降低车辆燃料消耗和缩短运输时间的自主运输系统；用于实现生产过程全面自动化的智能无人工厂等。
如何实现具备可信性保证的混合关键系统仍然是一项极具挑战的难题。其中的重要问题在于，如何有效地处理关键组件和非关键组件之间的交互协作，以及如何实现错误控制从而避免非关键组件的故障对关键组件的行为造成影响。我们仍缺乏解决这些问题的理论方法。
出于对成本效益的考虑以及理论上的局限，系统设计人员通常会根据系统的关键等级，在设计正确性和设计效率之间进行折中。提高设计 生产力（productivity） 与确保设计的正确性往往是相互矛盾的需求。设计生产力反映了设计过程的有效性和高效性。提高设计生产力的方式主要有以下几种： ① 组件复用； ② 使用适当的方法和工具实现设计流程的自动化； ③ 提升系统设计人员的专业技能和知识。以上三个方面还应该有效地协同：系统设计人员应当具备复用组件以及使用专业工具的知识背景。否则，如果设计人员没有得到充分的专业培训，那么使用复杂的工具就会适得其反。在系统工程的实践过程中，关键系统和“尽力而为”系统（非关键系统）分别采用两种完全不同的设计范式。
（1）关键系统的设计范式 ：侧重于确保系统的功能安全属性和信息安全属性得到满足。这类设计方法一般基于对所有潜在危险状况进行的最坏情况分析，对计算和物理资源进行静态分配，以确保系统的关键操作能够得以安全实现。其缺点在于，静态分配的资源量可能比实际需要的资源量高出很多个数量级，从而导致系统过度配置，增加系统的开发成本和能耗。例如，对于安全关键的实时系统，我们必须保证系统的响应时间少于给定的时限，前者通常根据任务的 最坏情况执行时间（Worst-Case Execution Time，WCET） 近似值来估算，其估算值可能比实际最坏情况执行时间高出许多个数量级。这种情况下，若系统按照近似值进行设计，则需要额外配置大量的资源来完成计算任务，从而导致系统的效率降低。此外，关键系统还采用大量的冗余设计提升系统的可靠性。然而，常见的冗余设计技术，如 三模态冗余（Triple Modular Redundancy，TMR） ，仅适用于硬件组件，这是因为硬件组件的故障概率是相互独立的，采用多个硬件有助于提升系统的可靠性。对于软件组件的冗余设计而言，简单的冗余设计技术并不能提升系统的可靠性，还需要在不同的冗余组件里采用不同模态的软件实现。显然，这必然会增加系统的开发和维护成本。
（2）“尽力而为”系统的设计范式 ：主要关注的是如何确保非关键系统的效率需求得到满足。这种方法一般基于平均情况分析和动态资源管理等技术，对系统的运行速度、内存消耗、带宽和功率等方面的性能指标进行优化。系统的物理资源分配主要用于确保常规情况下服务的可用性。当出现关键情况时，如服务需求激增，系统可能会将服务降级甚至拒绝服务。
将关键系统与非关键系统的设计区别对待，有助于我们有针对性地关注每一类系统的核心技术需求。尽管如此，这种区分仍可能带来一些障碍，汽车制造商在过去十多年中遇到的严重技术问题证明了这一点。现代汽车使用了超过50个 电子控制单元（Electronic Control Units，ECU） ，以提供各种关键等级的服务。这些ECU基于 联合架构（federated architecture） 进行协作，并使用 控制局域网络（Controller Area Network，CAN） 或时间触发网络等共享和交换信息。尽管这种架构能够实现关键功能和非关键功能之间的物理隔离，但是其缺点也很明显，较低的互联可靠性对全局系统的整体可靠性仍有负面的影响。
部分研究人员提出了 集成架构（integrated architecture） 概念，将不同供应商开发的功能集成到单个ECU中，从而减少ECU数量和互连，使用单个集成硬件单元执行来自不同子系统的计算任务 [10] 。这一趋势也解释了业界致力于研发集成架构的决心，如航空航天领域的 集成模块化航空电子系统（Integrated Modular Avionics，IMA） [11] ，以及汽车电子领域的 AUTOSAR [12] （Automotive Open System Architecture） 等。如何在系统设计中找到正确且高效的集成方案，实现功能安全性、信息安全性和有效性的一体化设计，仍将是未来学术界和工业界共同关注的研究重点。