忘记了wifi宽带密码:如何选择可靠的实时操作系统

如何选择可靠的实时操作系统

发布人：来自网络   发布时间：2011-2-08

　　对开发人员来说，选择一个可靠的实时操作系统（RTOS）应该是极其重要的事，嵌入式系统开发者应采用什么标准来选择实时操作系统（RTOS），对这个问题的合理的回答包括性能、功能和价格，所有这些都是RTOS供应商制作的宣传资料的中心。在产品目录，小册子，及无数的网页中，每个供应商都声称以吸引人的价格提供可靠的、功能完善的解决方案。
　　在很多RTOS供应商的文献中很少提及可靠性问题。但是，对开发人员来说，选择一个可靠RTOS应该是极其重要的事。然而一个不可靠的或仅提供部分功能的RTOS仍然可能对很多项目有用，但经常失败的软件在任何情况下都没什么价值，这种不可靠的软件可能抵消整个开发团队的努力。
　　当不能获得有效的可靠性信息时，购买软件成为一种冒险；开发人员只能期望供应商提供一个可靠的产品。不幸的是，在今天多变的RTOS前景下，新的、未经证实的不可靠的产品的供应商比比皆是。购买一个当初看起来似乎是精心设计的RTOS的开发者可能会发现他们实际上是该软件的第一个用户。
　　尽管不可否认可靠性的重要，但RTOS供应商很少关注它，或许原因之一是它比较难量化。虽然可以通过任务切换时间和中断延迟时间来描述一个RTOS的速度，但软件可靠性并不容易以数值表达。换言之，一个RTOS供应商不能简单的说：“以1到10作为一个量度我们的软件可靠性级别为7。4“。
　　尽管供应商趋向于避免明确的讨论可靠性，但关于它的资料并非不能找到。通过RTOS源码以及代码相关的文档，可以获取产品可靠性的宝贵见解。事实上，很多开发人员选择从熟悉某个RTOS的同事中寻求建议来代替检查文档及源代码。对关心可靠性的开发人员来说，一个更好的做法是选择一个经过认证的RTOS，这意味着在安全关键领域，它经过了严格的软件测试。尽管这些选择不能保证RTOS将完全按预期执行，但他们肯定比选择没有可靠性认识的RTOS获取改善。
RTOS 评价
　　对RTOS可靠性做出判断的一个明显的途径是实际使用该软件。通过评估这个RTOS，开发人员可以开始对产品的各个方面，包括可靠性，形成判断。在评估中获取的任何资料都可以作为软件供应商提供的资料的有益补充。
　　尽管直接得来的经验有这样明显的好处，但很多开发人员在决定购买RTOS之前并没有测试过他们选择的软件。通常情况下，安排RTOS评估有很多麻烦。可以理解，RTOS供应商非常强烈的保护自己的知识产权。因此，他们一般限制了软件的试用。试图评估一个流行的RTOS的工程师可能只能获取受到严格限制的软件版本。
　　受严格保护的软件的规则也有一些值得注意的例外，显然，开源的RTOS，想评估它的任何人都可以下载。然而，即便是一些商业软件也可以很容易的进行评估。Micrium非常受欢迎的实时内核，µC/OS-II及µC/OS-III就是这样的两个产品。
　　通过书《MicroC/OS-II， The Real-Time Kernel 》（中文版图书：嵌入式实时操作系统Uc/OS-II），被介绍给数以千计开发人员的µC/OS-II，在Micriμm的网站提供源代码。对更愿意使用Micrium的新内核－µC/OS-III的开发者，网站上同样提供了这个产品的目标代码。µC/OS-III的下载里面包含几个例程，它们在µC/OS-II书的承接，《µC/OS-III，The Real-Time Kernel》中做了描述。方便的是，新书的读者可以获取评估µC/OS-III所需的硬件及软件。这本书带有基于Micrium合作伙伴ST公司的高性能的 Cortex-M3微控制器的一块评估板。
　　无论是通过Micrium或其它地方，获取了RTOS评估版的开发者，应该首先通过审查产品的文档评估可靠性。当然，文档不能直接影响代码的功能，但一个易理解的、写得好的用户手册通常意味着一个精心设计的RTOS。开发人员应该警惕提供草率编写的手册或完全缺乏文档的产品。
　　作为预测可靠性的基础，RTOS源代码可能比任何文档更有用。因此，可以使用源代码的开发人员不要低估了源代码的价值。当评估一个RTOS代码时，开发人员需要确认的基本的特性总结如下。没有这些特性的RTOS很可能在写的时候没有考虑可靠性：
缩进－应该有足够的缩进，代码应该缩进一致
命名－函数和变量应采用统一的命名风格
注释－代码应该有明确的注释，注释使编程员的目的清楚
数据类型－应定义可移植的数据类型。标准C数据类型（char，short等）是不可移植的
简单表达式－代码应该减少不必要的复杂度。尽可能的采用简单、直观的表达式
　　源代码和文档可使用不同的审查程度。然而，在审查了一些源代码文件或用户手册的几页内容后，开发人员可以开始对RTOS的可靠性形成假设，但是，确认这些假设并不容易。
　　获取一个RTOS可靠性的正确方法只能是详细的软件测试。很多开发人员做这类测试，第一步是运行一个简单的仅执行少数任务的应用，然而，即使一个仅闪烁LED的应用也会产生问题。运行一个简单的、基于RTOS的应用的一个潜在的障碍是硬件可用性。若开发人员不能深入了解评估套件相应的硬件，将会在运行代码时遇到问题。
　　为了消除硬件对开发人员的影响，很多厂商提供了基于PC的软件评估版本。然而，伴随这些产品又有一个的问题：RTOS评估版和实际产品可能存在显著差异。如果移植到嵌入式微控制器上，以前在PC上运行很好的软件可能失败。由于这个原因，当通过使用基于PC的评估软件进行任何这类测试时，对其结果必须持怀疑态度。
　　即使开发人员能够在合适的硬件平台上运行评估软件，还是有很多障碍阻止对获取的RTOS准确的评估。在这些障碍中，时间可能是最难克服的。在通常分配给开发人员的很短时间内，评估软件、获取所有有效的数据是完全不可能的。
　　对开发者来说，只为了确认一个简单的、基于RTOS的应用可以正确的闪烁开发板的LED而找时间可能不是问题。然而，这样的测试对在更大的应用中，这个RTOS运行良好仅提供了很小的保证。因此，真正的开发者除了可闪烁LED之外，应该更加深入。对这样的开发者，下一步是整合RTOS和相对复杂的应用。
　　用于测试RTOS的应用必须仔细选择，由RTOS供应商提供的标准的测试套件是一个可行的选择。这些应用通常运行RTOS的各种服务，然后报告结果。
　　由于运行供应商提供的软件，RTOS不可能测试失败，使用自定义的测试套件更为可取。理想的测试套件应该是全面的，几乎使用RTOS的每个部分。然而，写这样一个套件将是一项艰巨的任务。因此，一些开发者不用正式的测试套件，而选择用以前的项目应用代码来测试RTOS。尽管这样开发者可以从编写测试代码的工作中解放出来，但他们可能要花几个月的时间来整合他们的应用和RTOS。特别是对计划尝试多个RTOS的工程师来说，这样冗长的评估周期是非常不理想的。
　　考虑到测试通常需要的时间，其结果可能令人失望。开发人员通常运行的测试仅说明一个RTOS的基本服务功能是否正确，他们很少测量可靠性。即使成功的完成了这样测试的RTOS可能仍有隐含的缺陷，这些缺陷可能几年都不会被发现。
历史和声誉
　　曾在一个或多个以前的项目中成功使用过某个RTOS的开发人员，可能相对确信这个RTOS没有隐藏的缺陷。不同于仅在RTOS上做过一些简单测试的开发人员，他们其实有可靠性的证据。然而，不选择一个新的而重用以前的RTOS并不是每个项目的选择。一个新的项目可能需要以前使用的RTOS缺乏的功能，或项目的预算不能负担旧的RTOS的授权费用。
　　对需要使用不熟悉的RTOS的项目，开发人员有时可能求助于他们的同事来获取产品可靠性的信息。咨询同事是获取信息的一种快捷手段，否则可能需要数年时间去收集。有了这些信息，开发人员可以避免选择过去性能较差的RTOS。
　　与同事讨论还可以帮助开发者确定某个的RTOS已经使用的时间。找一个历史悠久的RTOS是很重要的，因为，即使是充满缺陷的产品也可以随着时间的推移获得改善。当唯一可行的选择是一个相对较新的产品。开发人员不应该迅速看轻有曲折历史的RTOS。
　　一个RTOS历史的证据通常可以在软件的文档中找到。任何认真维护和文档化的RTOS应该有相应的版本手册，来说明随着时间的推移，软件的发展过程。典型的RTOS版本手册包括软件中所有已发现的软件缺陷列表，在手册中也提供了如何解决这些缺陷的说明，以及对软件其它更新的概述。

Micrium µC/OS-II的版本说明摘录如下。版本V2.86 的改变
os_core.c OS_EventPendMulti () was added.
Optimized OS_EventTaskRdy (), and added support for multi-pend.
Optimized OS_EventTaskWait ().
Removed OS_EventTOAbort() and added OS_EventTaskWaitMulti(),
OS_EventTaskRemove(),and OS_EventTaskRemoveMulti()
Optimized OS_TaskStat ().
os_mbox.c Rearranged OSMboxPend () to support multi-pend.
os_mutex.c Rearranged OSMutexPend () for consistency.
os_q.c Rearranged OSQPend () to support multi-pend.
os_sem.c Rearranged OSSemPend () to support multi-pend.
os_task.c Made cosmetic changes to OSTaskChangePrio(),and added support for
Multi-pend

　　选择在新工程中使用的RTOS之前，打算调查一个RTOS历史的开发人员也应该研究一下RTOS供应商的历史。可靠的软件很少由声名狼藉的供应商提供。在购买RTOS之前，开发人员应试图确认软件供应商不会定期停产，该公司没有财务或法律问题的历史记录。原厂提供的技术支持的质量也应该是可能购买该公司产品的开发人员所关心的。
　　RTOS供应商过去成功和失败的证据很难获得。供应商本身也不是这些信息的最佳来源。不必惊讶，RTOS供应商极力称赞自己的成就，并忽视竞争者的成果。尽管业界出版物有时可以用于查找RTOS供应商的声誉，但依赖这些信息来源的开发人员必须非常仔细区分公正的报道和巧妙含蓄的广告。
　　了解一个RTOS供应商的最好方式是咨询该公司的客户。与某个供应商做过生意后，这些人通常可以明确的判断该公司是否值得与其的业务往来。关注已有客户需求的公司可能会同样的对待未来的客户。
　　找到某个厂家的用户可能比较困难。幸运的开发人员也许可以找到曾是其用户的同事。然而，很多公司在他们所有的项目中使用同一个RTOS实时多任务操作系统。这些公司的员工通常没有很多RTOS供应商的经验。
　　即使有同事是某个RTOS供应商的用户的开发人员要获取关于该供应商和其产品的正直的建议也会有困难，像上述的商业出版物。一个RTOS供应商的用户并不总是提供无偏颇的信息。例如，其以前项目最终失败的开发人员，可能会犹豫是否推荐曾在该项目中使用的RTOS实时多任务操作系统，即使这个软件并不是问题的根源。
认证
　　理想情况下，开发人员不需要麻烦他们的同事来获取RTOS的建议。可靠的软件只是获得一个公正的第三方的审批盖章。开发人员可以据此做出选择。这种可靠性标志是在彻底的检查软件及其写的环境后被授予。
　　这样一个清晰的识别可靠软件的系统似乎好的令人难以置信。然而，在航空电子设备和医学领域，给予精心设计的软件认可是普遍的做法。其实，对那些安全关键行业，几乎所有的软件都需要通过正式的认证过程而获得审批。在美国，飞机零部件及其它航空电子产品使用的软件必须通过美国联邦航空管理局(FAA)的认证，而用于医疗设备的软件需要有美国食品及药物管理局（EDA）的认证。
　　由于用于安全关键领域之外的软件通常不需接受航空电子和医疗产品必须的审查。很多开发人员对认证过程知之甚少。但所有软件的开发人员，都可以从用于安全关键领域的程序获益。软件认证的存在使选择一个可靠的RTOS的工作更加容易。不必试图通过执行一连串的测试来评估可靠性，开发人员可以简单地选择一个已经经过了严格的测试认证的RTOS。
　　在整个安全关键领域，认证过程不是统一的。FAA认证过程与FDA过程有细微的区别。即使在某一行业，可能存在不同类型的认证。美国民航电子设备软件开发标准DO-178B，包含了FAA软件认证的准则，该文件描述了5种不同层次的认证：A，B，C，D和E。某一产品需要那种级别的认证取决于产品失败可能导致的结果。级别A认证，是最严格的，任何可能导致飞机灾难性故障的产品需要通过A级认证。其它级别的认证用于错误不会显著影响飞机的整体功能的产品。
　　除了这些细微的差别，各个种类的认证总体目标是相同的：确保被认证的软件做它应该做的。据推测，任何评估一个RTOS的开发人员同样有这个目的。不过，与受时间限制的开发人员实际可以在RTOS的评估版上做的工作相比，认证包含更多深入的检查。
　　在一个产品被FAA或FDA认证之前，它的开发人员（或者，大多数情况下是受雇于那些开发商的顾问）必须准备大量文件。通常，第一份要准备的文件是一个总体规划，描述该软件如何被证明值得认证。在DO-178B认证中，该文件被称为“软件认证计划”。
　　为了支持认证，其它文档中必须准备很多规范说明。在这些文档中描述了被认证的产品在开发过程中遵循的编程规范和其它的规则。没有依据严格的编码规范开发的软件不可能通过认证。
　　没有详尽的需求文档的软件也被认证排除。文档的目的是描述软件特定部分预期的功能。在认证的软件中每行代码都可以追溯到需求，没有多余的代码。
　　确定一系列需求是否成功的实现需要广泛的测试。专注于认证一个航空电子设备或医疗产品的团队可能需要写成千上万行的测试代码。此代码不能随便写，它必须完整的测试要认证的软件。通常，为组成软件的每个函数写测试代码。
　　能够验证一个软件是否满足其所有需求的测试代码可以说达到了需求覆盖。除了要求这种覆盖之外，在DO-178B规范中介绍的高级认证还要求结构覆盖。这种附加的规定有助于保证测试代码是详尽的。有几种不同程度的结构覆盖，但实现它们的关键是编写使程序每一个部分都被执行的测试代码。不同类型结构覆盖比较如下。

例程：
if ((spd != 0) || (rpm != 0))
{
ctr++;
}

覆盖类型 DO-178B定义 例程测试条件
语句覆盖 程序中的每条语句至少执行一次 (spd = 1, rpm = 0)
判断覆盖 程序的每个入口和出口至少
调用一次，每个判断所有可能
的结果至少执行一次 (spd = 1, rpm = 0),
(spd = 0, rpm = 0)
修正条件/
判断覆盖 程序的每个入口和出口至少
调用一次，每个判断条件所有可能
的结果至少执行一次，每个判断所有
可能的结果至少执行一次，且判断的每个
条件被证明可以独立影响结果，被证明可以独立
影响判断结果的条件，保持其它条件不变
而仅改变该条件 (spd = 1, rpm = 0),
(spd = 0, rpm = 1),
(spd = 0, rpm = 0)
　　如果程序的每行代码对应一个需求，那通过需求覆盖可以获取结构覆盖。提供了一些实际上经过测试的如何严格认证软件的方式的高级别的认证的DO-178B，坚持认为两种类型的覆盖必须满足。尽管没有测试方法是完美的，测试过程中缺陷幸存的可能性非常小。
　　通过使用认证作为选择RTOS的标准，开发人员可以保持自己的产品没有缺陷。开发人员需要记住的一个细节是，RTOS很少关注认证工作。相反，认证通常涉及应用代码。可是，当RTOS用于被认证的应用，它服从认证过程中所有必须的测试。
　　在众多RTOS供应商中，仅有部分在交易中提供在认证过的产品。从2000年，当µC/OS-II第一次用于FAA认证的应用中后，Micrium就开始提供这样的产品。今天，在其产品必须认证的开发人员中，µC/OS-II已成为最流行的内核。除了很好的满足航空电子和医疗产品需求，对铁路运输和工控领域的开发者也是一个可靠的选择。它甚至被用于FAA认证的最艰难的标准，DO-178B的A级的应用。
　　µC/OS-II只是产品系列的一部分，该产品系列还包括文件系统模块，图形软件以及各种协议栈。在开发这类产品时，Micrium的工程师遵循严格的编码标准，并关注各种安全关键领域的需求。因此，所有的产品都是非常可靠的。
　　这种可靠的软件适用于所有不同的应用，而不仅是需要认证的应用。然而，在安全关键领域，开发人员可以从Micrium的软件中受益。通过利用Micrium的合作伙伴Validated software的认证套件，这些开发人员可以显著的减少认证他们产品所需的工作量。认证套件是包含了认证所需大部分文件的工具包。Validated Software 已经准备了几个Micrium软件模块的认证包。对大多数模块，有多个认证包可用，每个对应一个不同安全关键领域。
结束语
　　认证必须的众多的规划文档，标准和测试结果证明消除软件缺陷是非常困难的。写可靠的软件对所有开发者，包括那些RTOS供应商的雇员，都是一个挑战。因此，购买RTOS是有风险的。
无论RTOS买家采取什么措施，都不能完全避免这种风险。但是，通过选择有信誉的供应商提供的经过良好测试的RTOS，他们可以充分地减少发生问题的机会。理想的选择是一个经受住了认证过程的RTOS，一个满足了最苛刻的应用标准的产品。对很多项目来说，在安全关键领域及之外，这种RTOS将是决定成败的关键。