测试实时操作系统的硬度
我有一个嵌入式设备 (Technologic TS-7800 ）宣传实时功能，但没有提及“硬”或“软”。 当我等待制造商的答复时，我认为自己测试一下系统不会有什么坏处。
有哪些既定程序可以确定特定设备在实时/确定性行为（延迟和抖动）方面的“硬度”？
在大学期间，我可以使用一些非常简洁的硬件（良好的示波器和信号发生器），因此我认为我不会在测试设备方面遇到任何问题，而只是在专业知识方面遇到问题。
I have an embedded device (Technologic TS-7800) that advertises real-time capabilities, but says nothing about 'hard' or 'soft'. While I wait for a response from the manufacturer, I figured it wouldn't hurt to test the system myself.
What are some established procedures to determine the 'hardness' of a particular device with respect to real time/deterministic behavior (latency and jitter)?
Being at college, I have access to some pretty neat hardware (good oscilloscopes and signal generators), so I don't think I'll run into any issues in terms of testing equipment, just expertise.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
使用这种设备，应该很容易将示波器与稳定的时钟同步，每次实时系统产生输出时产生一个尖峰，看看该尖峰与中心的变化有多大。 变化越小，硬度越大。
With that kind of equipment, it ought to be fairly easy to sync the o-scope to a steady clock, produce a spike each time the real-time system produces an output, an see how much that spike varies from center. The less the variation, the greater the hardness.
为了澄清鲍勃的答案，也许：
使用信号发生器以某种不同的频率生成脉冲。
在某个范围内随机分布是最好的。
使用信号发生器（触发信号）启动示波器。
RTOS 必须响应、执行操作并发送输出脉冲。
将 RTOS 输出馈入示波器的输入 2。
获取持久/收集模式的范围。
如果可以的话，让范围从 A 开始，在 B 停止。
在理想的情况下，让它为您测量分布。 力科就会。
从比您预期慢得多的跟踪开始。 您需要能够看到缓慢的异常值。
您将能够看到分布。
假设正态分布，响应时间变化的 SD 就是柔软度。
（这在实践中不会真正发生，但如果你没有得到异常值，它是相当有用的。）
如果存在大延迟的异常值，那么 RTOS 并不是很难。 不能很好地按时完成任务。 那么它不适合硬实时工作。
许多类似 RTOS 的东西都有一个很好的曲线左边缘，像 1/f 曲线一样向下倾斜。
这表明了综合抖动。 需要注意的是示波器右端响应缓慢的尖峰。 如果没有异常值，请继续以更快的轨迹重复实验，以获得良好的斜坡图像。 应该有利于你论文中的一些推测性结论。
如果对于您的应用来说，1uS 的增量就可以了，而您测量的是 0.5us，那就很酷了。
无论如何，您可以发布结果（可能是发布意义上的，但肯定是在网络上。）
在您写完该问题后，链接到该论文。
To clarify Bob's answer maybe:
Use the signal generator to generate a pulse at some varying frequency.
Random distribution across some range would be best.
use the signal generator (trigger signal) to start the scope.
the RTOS has to respond, do it thing and send an output pulse.
feed the RTOS output into input 2 of the scope.
get the scope to persist/collect mode.
get the scope to start on A , stop on B. if you can.
in an ideal workd, get it to measure the distribution for you. A LeCroy would.
Start with a much slower trace than you would expect. You need to be able to see slow outliers.
You'll be able to see the distribution.
Assuming a normal distribution the SD of the response time variation is the SOFTNESS.
(This won't really happen in practice, but if you don't get outliers it is reasonably useful. )
If there are outliers of large latency, then the RTOS is NOT very hard. Does not meet deadlines well. Unsuitable then it is for hard real time work.
Many RTOS-like things have a good left edge to the curve, sloping down like a 1/f curve.
Thats indicitive of combined jitters. The thing to look out for is spikes of slow response on the right end of the scope. Keep repeating the experiment with faster traces if there are no outliers to get a good image of the slope. Should be good for some speculative conclusion in your paper.
If for your application, say a delta of 1uS is okay, and you measure 0.5us, it's all cool.
Anyway, you can publish the results ( and probably in the publish sense, but certainly on the web.)
Link from this Question to the paper when you've written it.
硬实时更多地与软件的工作方式有关，而不是与硬件本身有关。 当询问某些东西是否是硬实时时，它必须应用于整个系统（硬件、RTOS 和应用程序）。 这意味着硬实时或软实时是系统设计问题。
在超过规格的负载下，即使硬实时系统也会失败（希望有适当的失败指示），而低负载的软实时系统将给出硬实时结果。 有多少处理必须及时发生以及可以执行多少前/后处理是硬/软实时的真正关键。
在某些实时应用程序中，一些数据丢失并不是故障，它应该只是低于某个水平，这也是一个系统标准。
您可以生成到电路板的输入，并让一个小型应用程序对它们进行计数，并检查数据将在什么级别丢失。 但这会为您提供特定于运行该应用程序的系统的评级。 一旦您开始进行更多处理，您的计算负载就会增加，并且现在您将面临不同的硬实时限制。
该板将运行一个简单的调度程序，将为大多数任务提供出色的可预测硬实时性能。
运行具有繁重计算负载的完整 RTOS，您可能只能获得软实时。
评论后编辑我用来测量软件性能的最有效和最简单的方法（假设您使用调度程序）是使用板上自由运行的硬件计时器，并为我的周期的开始和结束添加时间戳。 或者，如果您运行完整的 RTOS 时间戳，您将获得并转换时间戳。 保存您的最大时间并对一秒内的值进行平均值。 如果你的平均值在 50% 左右，而你的最大值在平均值的 20% 以内，那么你就可以了。 如果不是，那么是时候重构您的应用程序了。 随着您的应用程序的增长，周期时间也会增加。 您可以监控所有软件更改对周期时间的影响。
另一种方法是使用硬件定时器产生循环中断。 如果及时重置中断。 如果您错过了最后期限，中断处理程序会发出失败信号。 然而，这只会在您的应用程序花费很长时间时向您发出警告，但它依赖于硬件和中断，因此您不会错过。
这些解决方案还消除了连接示波器来监视输出的要求，因为时间信息可以通过后台任务显示在任何类型的终端中。 如果很容易监控，您将定期监控它，避免在最后解决计时问题，但一旦引入它们就立即解决。
希望这可以帮助
Hard real-time has more to do with how your software works than the hardware on its own. When asking if something is hard real-time it must be applied to the complete system (Hardware, RTOS and application). This means hard or soft real-time is system design issues.
Under loading exceeding the specification even a hard real-time system will fail (hopefully with proper failure indication) while a soft real-time system with low loading would give hard real-time results. How much processing must happen in time and how much pre/post processing can be performed is the real key to hard/soft real-time.
In some real-time applications some data loss is not a failure it should just be below a certain level, again a system criteria.
You can generate inputs to the board and have a small application count them and check at what level data is going to be lost. But that gives you a rating specific to that system running that application. As soon as you start doing more processing your computational load increases and you now have a different hard real-time limit.
This board will running a bare bones scheduler will give great predictable hard real-time performance for most tasks.
Running a full RTOS with heavy computational load you probably only get soft real-time.
Edit after commentThe most efficient and easiest way I have used to measure my software's performance (assuming you use a schedular) is by using a free running hardware timer on the board and to time stamp my start and end of my cycle. Or if you run a full RTOS time stamp you acquisition and transition. Save your Max time and run a average on the values over a second. If your average is around 50% and you max is within 20% of your average you are OK. If not it is time to refactor your application. As your application grows the cycle time will grow. You can monitor the effect of all your software changes on your cycle time.
Another way is to use a hardware timer generate a cyclical interrupt. If you are in time reset the interrupt. If you miss the deadline you have interrupt handler signal a failure. This however will only give you a warning once your application is taking to long but it rely on hardware and interrupts so you can't miss.
These solutions also eliminate the requirement to hook up a scope to monitor the output since the time information can be displayed in any kind of terminal by a background task. If it is easy to monitor you will monitor it regularly avoiding solving the timing problems at the end but as soon as they are introduced.
Hope this helps
我在这里工作也有同样的董事会。 我相信这是一个稍微修改过的 2.6 内核......而不是实时版本。
我不知道我在文档中读过任何内容，表明它适用于严格的 RTOS 工作。
I have the same board here at work. It's a slightly-modified 2.6 Kernel, I believe... not the real-time version.
I don't know that I've read anything in the docs yet that indicates that it is meant for strict RTOS work.
我认为这不是一个硬实时设备，因为它不运行 RTOS。
I think that this is not a hard real-time device, since it runs no RTOS.
我理解是极客，但使用示波器测试具有以太网/USB/其他数字端口和巨大内部状态（RAM）的计算机既无效又不可靠。
您可以将任何 PC 连接到输出端口并运行适当的统计分析，而不是观看波形。
既定程序（如果输入信号本质上是模拟信号）是针对多个特征输入（传统上是尖峰、阶跃函数和不同频率的正弦波）测试系统，并测量每种输入类型的相移和方差。 然后在系统规范中使用最坏情况。
同样，如果您使用标准端口，则可以轻松在 PC 上生成这些端口。 如果输入是真正的模拟，则需要一个单独的 DAC 或一个好的声卡。
现在，这并不能说明操作系统是实时的 - 它可以运行普通 Linux 甚至 Win CE，并且如果硬件足够快，仍然可以在这些测试中产生良好且稳定的结果。
因此，您需要模拟处理器、内存和所有端口上的沉重且变化的负载，让它加热并消耗内存几个小时，然后重复测试。 如果延迟保持恒定，则很难实现实时。 如果在任何负载和输入信号类型下它都没有增加到可接受的限度以上，那么它就是软的。 否则就是广告。
PS：这意味着即使对于关键系统，如果您有硬件，您实际上也不需要硬实时。
I understand being geek, but using oscilloscope to test a computer with ethernet/usb/other digital ports and HUGE internal state (RAM) is both ineffective and unreliable.
Instead of watching wave forms, you can connect any PC to the output port and run proper statistical analysis.
The established procedure (if the input signal is analog by nature) is to test system against several characteristic inputs - traditionally spikes, step functions and sine waves of different frequencies - and measure phase shift and variance for each input type. Worst case is then used in specifications of the system.
Again, if you are using standard ports, you can easily generate those on PC. If the input is truly analog, a separate DAC or simply a good sound card would be needed.
Now, that won't say anything about OS being real-time - it could be running vanilla Linux or even Win CE and still produce good and stable results in those tests if hardware is fast enough.
So, you need to simulate heavy and varying loads on processor, memory and all ports, let it heat and eat memory for a few hours, and then repeat tests. If latency stays constant, it's hard real-time. If it doesn't, under any load and input signal type, increase above acceptable limit, it's soft. Otherwise, it's advertisement.
P.S.: Implication is that even for critical systems you don't actually need hard real-time if you have hardware.