挑战部分
-
背景问题:
- 现代工业系统和产品(如汽车、智能手机、医疗设备)越来越依赖于软件,尤其是嵌入式实时系统。这些系统的可靠性对于社会至关重要,比如特斯拉自动驾驶系统的软件问题曾引发一些事故。
- 目前,许多嵌入式系统是封闭和单一功能的,但未来它们将演变为开放的平台,能够根据用户需求进行功能更新和扩展。为确保安全性,系统需要支持动态更新,且在更新过程中保证系统安全。重要的是,更新必须以组件化的方式进行,不需要重新设计或全面验证整个系统。
-
更新的现实应用:
- 汽车是一个典型的例子,汽车的计算平台可以让多个智能传感器和电子控制单元运行新的应用程序,如更高效的发动机控制、车道跟随、行人检测等。根据不同的地理位置和需求,还可以安装专门的应用,如在北欧可以检测黑冰和麋鹿,而在南欧则可以优化电池再生制动。
- 另一个例子是心脏起搏器。患者随着年龄增长,可能会出现新的心脏问题,医生可以通过安装新应用来治疗,而不是更换设备,从而避免手术。
-
目前设计方法的局限性:
- 当前的实时系统设计方法在系统运行时对软件更新支持有限。例如,汽车这样的系统在更新后无法确保系统的安全性。这意味着系统在更新时,必须确保新组件不会干扰已有系统的运行,且新旧组件的输入输出应该兼容,避免资源冲突。
- 系统的非功能性正确性也必须保证,即计算平台需要有足够的资源来执行新的组件,避免资源超载或违反时序要求。
-
阻碍:
- 目前很多嵌入式系统架构并没有为更新做好准备,因此在部署后很难修改或扩展。例如,智能手机可以简单卸载新组件,但对于汽车这样的安全关键系统,即便是一次安全时序要求的违规也可能导致严重事故或人员伤亡。
-
现有测试方法的不足:
- 对于现代复杂的嵌入式系统,重新设计整个系统并不可行,而现有方法通过在实验室中对整个系统进行广泛的重新测试并不能满足未来系统的需求,因为系统状态和配置的数量太多,无法全面测试。
-
未来愿景和挑战:
- 文章的愿景是改变现有的实时系统开发方式,通过新的设计范式和技术来构建基于可组合架构的实时系统,使这些系统在未来可以进行组件化的增量更新,动态、安全且可靠地运行。
- 实现这一愿景需要解决三个关键挑战:
- 设计挑战:开发一种新的可组合架构和执行模型,能够支持未来的增量更新,确保新旧组件之间的输入输出和时序行为是确定的,尤其是对于安全关键系统。
- 验证挑战:开发可扩展的自动化验证方法,确保更新后的系统在功能和非功能要求上是正确的,并构建一代新的软件工具,能够在现场快速验证更新。
- 运行时挑战:开发高效的调度算法和可调度性分析技术,既能保证时序和资源要求,又能优化运行时资源的利用,特别是在异构多处理器和分布式平台上。
方法和视角
-
实时系统设计的技术挑战:
- 设计实时系统时,确保系统具有确定性输入输出和时序行为(通常是确定性的输入到输出延迟)是一个关键挑战,特别是当多个系统功能被集成并在资源有限的平台上同时执行时。确定性的语义允许使用像Simulink/Stateflow这样的工具进行模型在环仿真,以模拟和验证整个系统行为。
-
过去的解决方案:
- 过去几十年,硬件、软件、控制和通信领域的研究人员开发了许多应对这一挑战的解决方案。例如,同步编程语言(如Esterel、Lustre和Signal)和由Kopetz推广的时间触发(time-triggered)范式,通过在预定的时间点调度组件的计算和通信,确保了系统的确定性行为。这些系统具有高度可靠性和可预测性,但这种方法严格限制了系统在部署后进行修改或更新的可能性。
- 另一些方法则通过调度一组具有已知资源需求的任务来直接管理系统功能。这种方法适用于简单的周期性任务,但当任务之间存在数据依赖或平台异构时,调度问题会变得极为复杂,尤其是系统更新时。
-
提出的新方法:
- 作者提出了一种新方法,通过引入一个软件层来将系统功能的实现问题分解到平台上。这个软件层通过多任务运行时系统来实现,其中系统功能通过实时任务执行。这些任务是独立执行且异步通信的,从而避免了现有功能与新功能之间的干扰。
- 这种任务解耦解决了之前方法的两个主要缺陷:
- 避免了静态或过度确定的时间调度,因为组件间的交互是异步的。
- 任务组的调度变得更加可控,因为任务是独立的,不需要考虑复杂的资源和数据依赖。
-
设计架构概述:
- 文章中的设计架构如图1所示,分为三个层次:功能层、软件层和硬件层。
- 功能层:系统功能被指定为基础组件的数据流链,这些组件的资源需求映射到软件层的任务中,确保平台具有足够的资源满足非功能性要求。
- 软件层:由独立的实时任务组成,任务通过非阻塞的数据缓冲区异步通信。软件层是对计算和通信资源的抽象,提供了硬件层的统一需求形式。
- 硬件层:实际平台上的计算和通信资源,包括CPU、网络带宽、GPU、FPGA等。通过新技术将软件层映射和调度到硬件层。
- 文章中的设计架构如图1所示,分为三个层次:功能层、软件层和硬件层。
-
系统支持的更新方式:
- 系统按照这种设计架构构建后,可以通过以下方式支持新组件或更新组件的增量更新:
- 在任何更新之前,系统会验证更新后的系统是否满足规定的功能性要求,这仅使用功能层的组件契约。
- 确保平台有足够的资源满足系统的非功能性要求。如果软件层不需要更改,则只需调整任务的参数(如周期或资源预算),确保新的软件层可调度。
- 系统按照这种设计架构构建后,可以通过以下方式支持新组件或更新组件的增量更新: