当报告的软件问题不是真正的软件问题

And*_*yUK 7 error-reporting

如果这已经被覆盖了,或者您认为它确实属于wiki,请道歉.

我是一家为生物科学行业生产微阵列印刷机的公司的软件开发人员.我主要通过C++中的GUI开发与各种硬件(气动,液压,步进电机,传感器等)连接,以便将样品吸移并打印到微阵列载玻片上.

在加入公司时,我注意到只要出现与硬件相关的问题,这就会导致整个设置冻结,没有人知道具体问题是什么 - 硬件/软件/误用等等.从那时起我就改进了有些事情通过引入软件超时和异常处理来更好地识别和处理任何硬件相关的问题,例如PLC命令未成功完成,不适当的FPGA响应命令,以及各种其他死锁类型条件等.此外,软件现在将记录具体问题的摘要,通知用户并正常退出线程.此软件未嵌入,只使用串行端口连接.

尽管已经取得了成就,非软件人员仍然不完全了解在这些情况下,他们向我报告的"软件"问题实际上不是软件问题,而是软件报告问题,但不会导致它.不要误会我的意思,没有什么比享受像大量积木一样的软件错误,以及以任何方式提高稳健性的方法.我现在知道这个系统已经足够了,我对这些东西几乎有第六感.

无论我试图解释多少次,都没有真正渗透.他们仍然报告软件问题本质上是硬件问题(最终得到修复).

我想听听其他任何经历过类似指点经验的人以及他们用来处理这些经验的方法.

更新 这里有一些很好的回应,几乎是从同一张赞美诗中唱出来的:更具描述性.我想在硬件出现故障时识别命令并彻底轰炸是第一阶段,但仍然不够.下一阶段将把那些对外行人毫无意义的PLC命令映射到更具启发性的东西."PLC命令M71超时"变为"未能初始化注射器系统.检查是否达到足够的真空"等等......

Chr*_*isF 2

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

“步进电机没有响应”。

不幸的是,因为人们看到并与之交互的是软件,所以他们认为软件就是全部。