标签：需要 一个 系统 分区 RTOS 应用程序 硬件 实时操作系统 软件
您需要一个实时操作系统吗？
Topics:Multicore Systems Architecture Rtos Embedded Systems Development Real-Time
原文链接
https://www.lynx.com/embedded-systems-learning-center/do-you-need-an-rtos-real-time-operating-system
以下中文来自谷歌翻译
主题：多核系统架构Rtos嵌入式系统开发
实时操作系统（RTOS）是否始终为提供实现嵌入式软件系统设计的最有效平台？大多数RTOS供应商似乎是这么认为的，经常引用RTOS的优点，而很少讨论缺点。 “您是否需要RTOS？”这个问题经常出现。解释为“您需要哪个RTOS？”
自1988年以来，Lynx Software Technologies就为安全性和安全性至关重要的应用程序构建并支持了实时操作系统。然而，年复一年，我们发现客户从RTOS寻求的大多数好处并不只是RTOS的好处。毕竟，并非所有的应用程序都需要实时功能，系统设计中的所有元素也不需要使用相同的工具来构建。
更重要的是，RTOS本身通常无法提供广泛的系统级好处，包括简单性。更大的开放度；更强的分区；以及更具可扩展性的确定性。因此，尽管RTOS有好处，但最简单的答案是“您是否始终需要RTOS？”没有。”实际上，当客户来到Lynx并说要购买我们的RTOS之一时，我们要问他们的第一个问题是：“您确定吗？”
硬件开发已更改嵌入式景观
硬件虚拟化（包括英特尔的虚拟化技术（VT-x和VT-d），Arv8-A虚拟化支持以及PowerPC的E.HV功能）已从高端服务器级处理器降到了低功耗，低成本芯片带来的细粒度分区和时序控制优势非常适合嵌入式应用。了解这些进步非常重要，因为它们使某些操作系统（OS）功能变得多余。
本质上，硬件虚拟化支持CPU资源的并行仲裁，从而系统中的多个软件参与者可以直接控制CPU的各个部分。在进行虚拟化之前，RTOS内核有责任专门仲裁CPU资源以维护平台完整性，但是现在情况不再如此。如果RTOS的基本职责对本机硬件辅助功能来说是多余的，则希望RTOS供应商完成与硬件一起适应和发展的艰巨工作，而不是维护旧的RTOS设计。因此，如果供应商采用硬件虚拟化来支持嵌入式实时设计目标（我们强烈建议这样做），将平台软件称为RTOS是否合适？我们不这么认为。
与硬件一起发展
新的硬件功能为平台软件提供了新的方法，以最大程度地减少堆栈复杂性，克服性能阈值并提供更好的应用程序可移植性。必须了解以下体系结构属性，以发现您是否错过了RTOS所没有的大量平台优势：
分布式设计与集中式设计的好处
异构组成
最小特权原则
开放系统
系统可理解性与专有API
分布式VS的好处。集中式设计
在虚拟化之前，操作系统（OS）强制采用集中式的Client-Server行为模型，其中每个用户应用程序都是OS服务器的客户端，该服务器可仲裁物理资源的使用（请参见下面的图1）。
异质成分
为重复使用而设计是对未来项目的投资。一旦成功将系统划分为自主的分布式组件，您便有了更多选择，可以使用不同的工具链来构建这些组件。尽管这可能会导致开发工具集变得更加复杂，但在重用成熟的经过测试的软件组件时，可以节省大量资金。
考虑需要增加传统功能的设计。最有效的方法是重新使用已证明的功能，并将该功能连接到所需的增强组件，而不是改装旧的组件以包括所需的功能。
最小原则
最低特权体系结构是互连系统的必需。没有它就像开车时没有系安全带。本质上，最低特权意味着设计中运行的每个软件都应仅以执行其功能所需的特权运行。与依靠软件内核控制应用程序特权相比，硬件虚拟化使最低特权体系结构成为要简单得多的目标。
在微内核架构的早期，应用程序，驱动程序和内核被微妙地划分为不同的上下文，从而迫使需要仔细互连并安排良好性能的复杂结构。使用硬件虚拟化，不需要将应用程序，驱动程序和操作系统内核分开来限制CPU特权的提升。
例如，如果一个应用程序仅与网络通信有关，则它不应访问GPU，USB，串行端口等。在分布式模型（上述）中，您可以确保每个自治软件组件仅具有以下可见性：与集中式操作系统模型相反，您可以在启动时在硬件中强制执行此访问控制，从而防止任何组件在运行时授予新的访问权限。
这种方法有两个主要好处：
如果不了解给定的资源，操作系统将不会动态加载用例不需要的驱动程序，从而最大程度地减少了系统上运行的代码消除任何软件在运行时修改访问权限的能力是消除攻击者获得特权升级并为其授予新访问权限的可能性的关键
为了遵循最低特权原则，必须信任平台工具不会授予对任何资源的任何访问权限；除非您（开发人员）明确启用它们。 （有关在汽车设计中实现的最低特权架构的示例，请浏览在Arm TechCon 2019上展示的Lynx汽车演示。）
开放系统
“开放”系统的本质是低成本的可移植性和组件的重用性。从集中式系统设计到分布式系统设计消除了实现这些目标的不太明显的技术障碍。在集中式Client-Server OS模型中，应用程序严重依赖于操作系统内“幕后”所发生的一切。这些基本的行为语义在OS API实现的版本之间可能会有所不同。即使API描述版本与其他平台兼容，语义兼容性，许可成本以及在新平台上组装应用程序所需的工作的解决方案也很可能会抑制成本。
当应用程序与它们的依赖关系作为完整的映像对齐时，在平台之间进行移植就不再是技术难题了，这一挑战可以极大地使供应商受益。分布式体系结构可以为客户提供更大的自由度和灵活性，以请求和利用针对第三方编译组件的集成工具。此外，为应用程序开发人员提供可视性和控制权，以便他们自己构建和管理其整个应用程序依赖关系，从而为开发人员提供了更大的自由度，可以过滤掉不必要的复杂性，并提高了定义精确系统执行行为的能力。
系统可比性VS。专有API
遵循软件代码并在硬件级别理解其功能所需的工作被称为可理解性。 RTOS的集中式“客户端-服务器”模型的主要问题是，每个任务或应用程序都必须处于相同的抽象级别（系统API）。该API隐藏了操作系统的底层复杂性，这些复杂性可能是对库的简单函数调用（最佳情况），或者许多系统调用和上下文切换（最坏情况）。
图3-基于POSIX®的RTOS中的典型系统调用（显示了应用程序函数调用及其在内核空间中的实现之间的抽象）
从表面上看，这种增加的复杂性可以看作是简化API和附加功能的一个有价值的折衷。但是，为了调试软件并了解“幕后”情况，开发人员通常需要了解（并维护）复杂的系统调用和上下文切换网络。
例如，当写入设备时，开发人员可能看不到任何输出。用示波器调查输出引脚上的内容只会显示一条平线。然后，开发人员必须打开调试器，并开始一次单步执行代码。初始“写入”函数调用与硬件寄存器中设置的相应位之间的抽象层和间接层越多，查找问题的根本原因就越困难。难以理解且难以维护。 （请参阅我们的相关文章，以了解有关POSIX®好处的更多信息）。
分区-SIMPLER（甚至更多）更强大
分区是维护平台完整性的最重要功能。安全RTOS吹捧了时间和空间分区的好处已有数十年之久，但仔细研究实现情况，可以发现在降低复杂性和分区功能方面仍有改进的空间。
更简单的分区意味着更强的分区。从OS内核（同时使用软件和硬件）完全消除分区的责任，而仅使用硬件，则可以提供更大的功能强度，并且是验证证书的简单得多的机制。
更多的分区意味着更强的分区。仔细观察，RTOS通常仅分区任务地址空间，并为任务或任务组创建执行时间的循环窗口。 RTOS经常忽略硬件虚拟化中内置的大量分区功能，例如直接内存访问（DMA）通道分区，使用高速缓存分配技术（CAT）的高速缓存分区，中断屏蔽，指令集保留等。
可确定的确定性
RTOS的主要技术目标是管理确定性，这主要是通过调度程序实现的。确定性调度程序通常实现优先级优先或周期性的任务分配模型。在协调所有CPU内核之间的竞争条件，一致性，资源争用以及计时器和异步中断时，这两种方法都面临着现代多核微处理器面临的重大技术挑战。
随着CPU内核和外围设备数量的增加，中断和软件复杂性也会增加。控制多核系统上确定性的最明显方法是通过隔离硬件干扰来简化需要确定性行为的环境。使用基于硬件的分区功能允许简单的传统调度技术按预期执行。
使用RTOS的传统原因
构建和支持RTOS已有30多年了，我们看到嵌入式系统构建者考虑购买商业RTOS的几个常见原因。以下是我们对收到的有关RTOS建议的一些最常见问题的答复：
图3-基于POSIX®的RTOS中的典型系统调用（显示了应用程序函数调用及其在内核空间中的实现之间的抽象）
但是，为了调试软件并了解“幕后”情况，开发人员通常需要了解（并维护）复杂的系统调用和某些切换网络。
例如，当写入设备时，开发人员可能看不到任何输出。用扫描调查输出切换上的内容只会显示一条平线。然后，开发人员必须打开调试器，并开始一次单步执行代码。初始“写入”函数调用与硬件寄存器中设置的相应位置之间的抽象层和间接层越多，发现问题的根本原因就越困难。难以理解且难以维护。（请参阅我们的相关文章，以了解有关POSIX®好处的更多信息）。
分区-SIMPLER（甚至更多）更强大
安全RTOS吹捧了时间和空间分区的好处已有几十年之久，但仔细研究实现情况，可以发现在降低复杂性和分区功能方面有所改善的空间。
从OS内核（同时使用软件和硬件）完全消除分区的责任，而仅使用硬件，则可以提供相应的功能强度，并且是验证证书的简单的一部分。机制。
仔细观察，RTOS通常仅分区任务地址空间，并为任务或任务组创建执行时间的循环窗口。RTOS经常忽略硬件虚拟化中内置的大量分区功能，例如直接内存访问（DMA）通道分区，使用高速缓存分配技术（CAT）的高速缓存分区，中断屏蔽，指令集保留等。
可确定的确定性
RTOS的主要技术目标是管理确定性，这主要是通过调度程序实现的。确定性调度程序通常实现优先级优先或逐步的任务分配模型。在协调所有CPU内核之间的竞争条件，一致性，资源争用以及计时器和逐步中断时，这两种方法都面临着现代多核克服面临的重大技术挑战。
随着CPU内核和外围设备数量的增加，中断和软件复杂性也会增加。控制多核系统上确定性的最明显方法是通过隔离硬件干扰来简化需要确定性行为的环境。使用基于硬件的分区功能允许简单的传统调度技术按预期执行。
使用RTOS的传统原因
内置和支持RTOS已有30年了，我们看到嵌入式系统整合者考虑购买商业RTOS的几个常见原因。以下是我们对收到的有关RTOS建议的一些最常见问题的答复：
“我需要实时响应...”
那么，您是否始终需要RTOS？不需要。有一些优雅的方法可以满足您的要求，而这可能并不需要RTOS的复杂性。
“我正在开发认证系统...”
那么，您是否始终需要RTOS？不能。混合设计可以通过异构的多核安全和安全划分框架进行认证和支持。
“我需要多次尝试...”
那么，您是否始终需要RTOS？否。如果灵活性和对任务调度的控制很重要，那么RTOS可能是一个不错的选择，但它也可能会过大-超级循环，中断，简单的调度程序或Linux可能更合适。
“我希望我的软件将来可以移植到其他平台上……”
那么，您是否始终需要RTOS？不会。虽然支持标准应用程序编程接口（API）的商用RTOS（例如POSIX®，ARINC 653和FACE™）肯定会有所帮助，但是如果您只是在寻找POSIX®支持的好处而又不需要实时的话保证，那么使用Linux可能会更好。
“工具供应商提供与其解决方案捆绑在一起的大量软件...”
那么，您是否始终需要RTOS？不会。捆绑软件的好处实际上取决于您要利用的软件的复杂性。诸如网络堆栈之类的复杂对象（可能会做大量后台工作）可能会在无法运行Linux的设备上保证使用RTOS，但最好还是先确定RTOS是您项目的最佳选择，然后再选择一个捆绑您所需软件的软件。
“我不想写硬件自举代码...”
那么，您是否始终需要RTOS？否。还有其他方法可以减少获得BSP所需的成本和精力。
“我拥有可通过新功能进行扩展的传统设计...”
那么，您是否始终需要RTOS？不能。如果您有基于专有API构建的旧代码，那么为了将来的验证，将其移植到具有标准API的RTOS上可能不值得。该设计通常可以与具有异构，多核安全和安全分区框架的裸机二进制文件集成在一起。
“我希望可以对我的申请进行调试...”
那么，您是否始终需要RTOS？否。切勿使用工具支持作为使用RTOS的理由。通常会包含这些工具，因为RTOS的复杂性需要复杂的跟踪和调试工具。删除RTOS可以简化了解软件行为所需的工具。
不要假设您需要RTOS
并非每个嵌入式软件系统设计都需要实时操作系统，我们发现开发人员犯的最大错误之一就是错误地假设需要RTOS。在选择了商用RTOS之后，嵌入式系统的制造商常常发现自己已锁定在供应商专有的API中，同时发现其设计选项受到一组有限工具的限制。鉴于我们的客户从RTOS中获得的许多好处并不完全是RTOS的好处，我们始终首先与他们协商，以最大程度地降低开发成本，复杂性和设计风险。通常，最佳的解决方案最终是混合设计（要比较航空电子系统的两种不同设计，请参阅航空电子页面的系统A与系统B部分）。
在没有RTOS的情况下满足设计目标与依赖于单片服务器的客户端应用程序集合相反，现代软件系统可以建模为分布式功能的更简单组合。这使您可以通过一组功能而不是假设不透明功能超集的单一平台来构建和描述平台软件。
我们与客户的对话通常不是将我们的产品与其他RTOS进行比较，而是解决常见的设计挑战，例如：
您有一个非常好的操作系统，可以在要重用的RTOS上运行，但是要添加RTOS不支持的新安全功能。
您需要对一些在通用操作系统上构建的任务进行实时调度
您拥有想要从微控制器移植到微处理器的专有调度程序
您的应用程序设计是如此简单，以至于迁移到RTOS会带来复杂性
您的应用程序是如此前沿，以至于转移到RTOS将需要大量的返工才能达到Linux上可比的吞吐量目标
在所有这些情况下，我们的建议是：
尽可能多地重复使用
尽可能简化设计
选择最具成本效益的组件和工具链来弥补功能设计上的空白
您的下一个项目
要了解有关如何有效实现模块化的分布式软件体系结构的更多信息，请参阅LYNX MOSA.ic™集成框架或“立即入门”，并向我们介绍您的项目。 我们很乐意与您安排白板会议，以发现应对挑战的最佳解决方案。
标签：需要,一个,系统,分区,RTOS,应用程序,硬件,实时操作系统,软件 来源： https://blog.csdn.net/weixin_40137252/article/details/110089928
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。