error-reporting - 当报告的软件问题不是真正的软件问题时

Question

抱歉，如果这已经被覆盖，或者您认为它确实属于 wiki。

我是一家为生物科学行业制造微阵列打印机的公司的软件开发人员。我主要参与通过 C++ 中的 GUI 开发与各种硬件(气动、液压、步进电机、传感器等)接口(interface)，以将样本吸出并打印到微阵列载玻片上。

加入公司后，我注意到每当出现与硬件相关的问题时，这都会导致整个设置卡住，没有人更清楚具体问题是什么 - 硬件/软件/滥用等。从那以后我已经改进了通过引入软件超时和异常处理来更好地识别和处理出现的任何与硬件相关的问题，例如 PLC 命令未成功完成、不适当的 FPGA 响应命令以及各种其他死锁类型条件等。此外，软件现在将记录总结具体问题，通知用户并优雅退出线程。该软件不是嵌入式的，只是使用串口连接。

尽管已经取得了成就，非软件人员仍然没有完全理解在这些情况下，他们向我报告的“软件”问题并不是真正的软件问题，而是软件正在报告问题，但不会导致它。不要误会我的意思，我最喜欢的莫过于像一堆砖头一样解决软件错误，并寻找以任何方式提高健壮性的方法。我现在对这个系统已经足够了解了，我几乎对这些东西有了第六感。

无论我试图解释多少次，都没有真正深入人心。他们仍然将本质上的硬件问题(最终得到修复)报告为软件问题。

我想听听其他有过类似指责经历的人，以及他们用什么方法来处理它们。

更新
这里的一些很棒的回应几乎是从同一张赞美诗中唱出来的:更具描述性。我猜想在硬件故障时识别命令并彻底轰炸是第一阶段，但仍然不够。下一阶段将把对外行相当无意义的 PLC 命令映射到更具暗示性的东西上。 “PLC 命令 M71 超时”变成“无法初始化注入(inject)器系统。检查是否达到了足够的真空度”等等……

Answer 1

也许在将问题作为消息报告给用户或日志文件中的条目时，您需要明确说明问题出在硬件上:

"Stepper motor not responding".

不幸的是，因为人们看到并与之交互的是软件，所以他们认为软件就是一切。