Когда возникли проблемы с программным обеспечением, на самом деле не проблемы со программным обеспечением

Question

Извините, если это уже было покрыто или вы считаете, что оно действительно принадлежит вики.

Я разработчик программного обеспечения в компании, которая производит машины для чистки микрочипов для индустрии биологических наук. Я в первую очередь участвую в взаимодействии с различными битами аппаратного обеспечения (пневматика, гидравлика, шаговые двигатели, датчики и т. Д.) С помощью разработки графического интерфейса в C++ для аспирации и печати образцов на слайдах с микрочипами.

При входе в компанию я заметил, что всякий раз, когда возникает проблема с оборудованием, это может привести к зависанию всей установки, и никто не станет более мудрее относительно конкретной проблемы: аппаратное/программное обеспечение/неправильное использование и т. Д. Так как то я немного улучшил ситуацию, внедряя тайм-ауты программного обеспечения и обработку исключений, чтобы лучше идентифицировать и решать любые связанные с аппаратным обеспечением проблемы, возникающие, например, команды ПЛК, которые не были успешно завершены, неправильные команды ответа FPGA и различные другие условия типа взаимоблокировки и т. д. Кроме того, программное обеспечение теперь регистрирует сводку конкретной проблемы, информирует пользователя и изящно выходит из потока. Это программное обеспечение не встроено, просто сопряжение с использованием последовательных портов.

Несмотря на то, что достигнуты, не-программные ребята все еще не понимают, что в этих случаях проблема «программного обеспечения», которую они мне представляют, на самом деле не проблема программного обеспечения, скорее программное обеспечение сообщает о проблеме , но не вызывает его. Не поймите меня неправильно, я ничего не люблю больше, чем сходить с программных ошибок, таких как тонна кирпичей, и смотреть на способы повышения устойчивости. Я знаю систему достаточно хорошо, что у меня почти шестое чувство для этих вещей.

Независимо от того, сколько раз я пытаюсь объяснить это, ничего действительно не проникает. Они по-прежнему сообщают о проблемах с аппаратным обеспечением (которые в конечном итоге фиксируются) как программные.

Хотелось бы услышать от других, которые пережили похожие впечатления от пальцев и какие методы они использовали для борьбы с ними.

ОБНОВЛЕНИЕ Некоторые замечательные ответы здесь, которые в значительной степени поют на одном и том же листе гимна: будьте более наглядными. Я думаю, что идентификация команды и бомбардировка чисто, когда аппаратные сбои были на первом этапе, но все еще недостаточно. Следующий этап будет состоять в том, чтобы сопоставить то, что для непрофессионала довольно бессмысленные команды ПЛК, для чего-то более наводящего на размышления. «PLC M71 timeout» становится «Ошибка инициализации системы шприцев. Проверьте достаточный вакуум» и т. Д.

Answer 1

Возможно, когда сообщение о проблеме либо в виде сообщения пользователя или запись в лог-файл вам нужно сделать это явно видно, что это оборудование, которое это по вине:

«шаговый двигатель не отвечает» ,

К сожалению, потому что это программное обеспечение, которое люди видят и взаимодействуют с они предполагают, что программное обеспечение является все, что есть.

Answer 2

Вы можете попробовать помечать эти сообщения как "HARDWARE PROBLEM". Можете понять свою точку зрения.

Answer 3

В системе не существует проблемы с программным обеспечением. Программное обеспечение - это босс, и босс не может обвинить отказ в инструментах.

Если базовое оборудование работает неправильно, оно должно сообщать пользователю, что именно не так, с каким компонентом. Если это не так, это проблема программного обеспечения.

Например, разъединение TCP означает, что он должен повторно подключиться. Если это ответ FPGA, он должен точно указать, какие были входы и выходы пользователю, и кто виноват. Если нет, это проблема программного обеспечения.

Answer 4

Я согласен с другими плакатами, но я хотел бы добавить еще одну перспективу: это может быть хуже. Они могут пытаться решить аппаратные проблемы в течение нескольких дней или недель, а затем узнать позже, когда все находятся под пистолетом и с ума сходят с ума, что они не исправляются, что они обращаются к неправильной проблеме, и это было на самом деле , проблема программного обеспечения. Так что рассчитывайте на ваши благословения. Если они всегда классифицируют его как проблему программного обеспечения, по крайней мере, вы об этом знаете. Только после этого вы можете устранить неполадки, возможно, добавить дополнительный код для решения проблем или код, идентифицирующий проблему, и сделать систему чуть-чуть лучше.

Кроме того, это почти то же самое, что и каждый разработчик программного обеспечения повсюду когда-либо сталкивался. За исключением обычно это программное обеспечение по сравнению с пользователем, а не программное обеспечение и аппаратное обеспечение. И в этом случае, похоже, нет известного решения. Много способов решить проблему, но никак не исправить ее. Таким образом, постоянно растущий список сокращений, описывающих, как обвинять пользователя, не будучи грубым: ошибка ID-ten-T, PICNIC, PEBKAC и т. Д.

Answer 5

Тестовая разработка (необязательные средства «test-driven») хотите, чтобы вы были обеспечены ресурсами.

В принципе, каждая подсистема должна иметь достаточно тщательный набор модульных тестов для идентификации проблемы перед интеграцией. Каждый раз, когда возникает проблема, протестируйте оборудование, чтобы вы могли точно знать (или почти уверен), что это проблема аппаратного обеспечения. Это означает, что оборудование должно быть спроектировано таким образом, чтобы его можно было тщательно протестировать.

Я был интеграционным руководителем моей коллеги-робота, и эта тактика помогает.

Надеюсь, что это поможет.

Answer 6

«Если то, что вы делаете, не работает, прекратить это делать и попробовать что-то еще»

Как отмечалось в других комментариях, это communcation и в меньшей степени, проблема восприятия. Люди будут обвинять то, что они больше не понимают, чем FAR, чтобы заставить себя чувствовать себя жертвой. Мотор может искриться, бросать огонь и взрываться от кого-то, сильно перегружающего фидер (с КАЖДОМ предупреждением о том, чтобы не оштукатурить его), но если это программное обеспечение перестает отвечать, угадайте, что вызвало проблему?

С учетом того, что каждый из ваших пользователей класс EE и CS или 10 полностью исключается, откиньтесь на хорошую связь ole. Основой которого является 4 вещи (в основном мое мнение) в определенном порядке - то, что вы наблюдаете, что чувствуете, что думаете и что нужно делать. Таким образом, с этой идеей, я буду реализовывать на практике, давая этот ответ.

Кажется, что ваши пользователи любят обвинять программное обеспечение, когда некоторые из основных аппаратных средств являются ключевой проблемой (наблюдайте). Попытка объяснить это с помощью пользователей об этом непрактична и пустая трата времени, это не их работа, и большинство из них не будут заботиться (чувствовать). То, что вы, возможно, захотите попробовать, говорит с инженерной командой о тех частях, которые они используют, и изучает вещи, которые лучше работают с программным обеспечением в целом. Может быть, есть некоторые ограничения, которые никогда не рассматривались?(думаю) Изменение аппаратного обеспечения или просто лучшее понимание этого может быть реальным ответом, а также более целенаправленными ошибками и обратной связью с этими пользователями (сделано).

Answer 7

Кто это, кто сообщает о проблемах?

Если это конечные пользователи, я думаю, что это не проблема. Они просто знают, что то, что они пытаются сделать, не работает. Ответственность за диагностику проблемы не несет пользователь. Все, что они знают, это: «Я пытался сделать X, я должен был это сделать, но вместо этого произошло Z». Все, что вам нужно, это ваша проблема.

Если люди аппаратного обеспечения настаивают на том, что проблема в программном обеспечении, и люди программного обеспечения настаивают на том, что проблема в аппаратном обеспечении, вам необходимо улучшить программное обеспечение, чтобы более точно диагностировать ошибки, поскольку ChrisF и другие отметили ,

Если высшие руководители обвиняют группу программного обеспечения в проблемах, связанных с аппаратной группой, и вам больно брать на себя ответственность за ошибки других людей, хорошо, я это понимаю. Опять же, как разработчик программного обеспечения, у вас есть возможность создавать более точные сообщения об ошибках. Если вы можете прямо сказать, что «шаговый двигатель не отвечает» или что-то еще, тогда у вас есть «моральный авторитет», который настаивает на том, чтобы кто-то запускал диагностику на шаговом двигателе. Просто говорю: «Я почти уверен, что это аппаратная проблема» не собирается выигрывать аргумент.

Answer 8

Прежде всего, убедитесь, что ваши пользователи с большей вероятностью узнают и ваши сообщения об ошибках. Отображение «Команда FPGA GS_WIDGIT_FROB вернула недействительный ответ 0xFF45001C. Выключение контроллера id 576D. (Error 1Xf)« может быть для вас отличным. Но пользователь, скорее всего, ударит «Ok», не прочитав его. Даже если они читают его, он не сообщает им никакой полезной информации. В любом случае, вы получаете телефонный звонок. Дисплей «Widgit Frobber требует обслуживания», но все же записывайте все тяжелые детали где-то, и вы, вероятно, получите меньше звонков.

Во-вторых, вы знаете, что это проблема с оборудованием, поэтому что-то с этим делать! У вас есть поддержка программного обеспечения электронной почты или что-то еще, чтобы устранить проблему. Если пользователь вынужден решить, какие действия предпринять для его исправления, вы можете поспорить, что они поймут это неправильно, по крайней мере, некоторое время. Если пользователь видит, что «Widgit Frobber требует обслуживания», уведомление об оборудовании было сообщено (билет № 234) «они знают, что им ничего не нужно делать.