实时系统异常处理答案

【问题标题】：Real time system exception handling实时系统异常处理
【发布时间】：2010-01-29 03:40:16
【问题描述】：

与往常一样，经过一些研究，我找不到任何真正有价值的东西。我的问题是如何在实时系统中处理异常？由于程序失败通常不是最好的情况，即核反应堆/心脏监测器。

好的，因为每个人都迷失了第二部分，这与主要问题无关。我在那里展示了我通常如何转义代码块。

【问题讨论】：

关于表单，缺少缩进和大括号并不好，但我发现早期转义方法比为 else 打开一个额外的范围并将其余函数放在那里更简单。单线的回报非常明显。
为您修复了格式。使用四个空格来缩进代码块 - 反引号仅用于内联内容。
为什么要从 void 函数返回字符串？为什么要将 null 传递给 foo？还是空字符串？为什么在实时关键程序中使用字符串？处理关键程序中的异常通常在运行之前就做好了！
foo 被声明为返回void，但您正试图返回String。因此它不会编译（以任何合理的语言）。因此，这是一种不好的形式。其次，我不知道foo 应该在做什么，但我不喜欢无声的失败。也就是说，假设foo 的工作是将string 添加到一些set。使用您当前的代码，调用者不知道添加是否成功发生。这可能会在未来导致令人不快的意外。第三，我讨厌没有支撑的条件代码。这只是一场维护噩梦。
亲爱的吉布斯。主要问题是关于实时异常处理，我添加的第二部分是我早期通常如何转义代码。

【解决方案1】：

实时/嵌入式系统中的异常处理有几个层次。不仅是语言支持的选项，还有 MMU、CPU 异常和我最喜欢的选项之一：看门狗。

语言异常 (C/C++) - 不经常使用，因为很难证明所有异常都在正确的级别处理。此外，很难确定应该对哪个威胁/过程负责。相反，首选按合同编程。

编程风格： - 即按合同编程。附加限制：Misra/C Misra/C++。可以检查这以确定是否以某种方式处理了所有可能的情况。（即 no if without else）

硬件支持： - MMU：使用相互保护的多个进程。这允许 - 看门狗 - CPU 异常 - 多核：使用多核将关键进程与其他进程分开。还允许有投票机制（你想要这个和更多的你的核反应堆）。 - 多系统

最重要的是定义策略。根据其他非功能性要求（安全性、可靠性、安全性），需要考虑策略。可以优雅降级为部分系统重新启动。

【讨论】：

【解决方案2】：

在“实时”、“核反应堆”类型的系统中，异常处理很有可能允许系统而不是失败，而是做下一个最好的事情。

假设我们有一个心脏监护仪。如果它没有收到信号，那可能会触发异常。在这种情况下，心脏监测器可能会通过等待几秒钟并重试来处理异常。

在核反应堆中，达到特定温度可能会引发异常。在这种情况下，处理可能会关闭反应堆的各个部分以开始对其进行冷却，然后在达到合理温度时重新启动它们。

异常是为了让较低级别的系统说它不知道该做什么，并让较高级别的系统处理它。就像在核反应堆中一样，测量温度的系统可能不知道如何打开反应堆的某些部分，所以它会触发一个异常，以便一些更高级别的系统可以处理它。

【讨论】：

【解决方案3】：

关键系统与任何其他系统一样，只是它的规定更明确，经过更多测试阶段，并且通常具有故障安全性。

关于你的表格，是的，这很糟糕。我非常介意缺少{}；而且经常有人说这只是一种糟糕的风格，并且在添加新代码时会导致混乱。

【讨论】：

一个关键系统具有明确定义的错误恢复策略。它必须在执行协调安全关闭时执行超出规范的方式。虽然主循环非常简单、干净和简洁，但故障服务生成了一些非常有趣的代码，您不会认为任何事情是理所当然的，通过许多级别的故障安全回退，直到您达到仍然可靠并最大限度地减少损坏的级别。此外，多个冗余组件不断地互相监视。 90% 的资源用于安全，10% 用于实际工作。