Является ли пользовательский интерфейс на основе Qt достаточно надежным, чтобы его можно было использовать в медицинском устройстве?

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

После некоторых исследований мы склонны выбирать Qt для разработки пользовательского интерфейса. Кажется, что он отвечает всем нашим потребностям, а именно современный и высокочувствительный пользовательский интерфейс может быть разработан, разработка довольно быстрая (после знакомства), использование памяти как-то разумно, бесплатно для коммерческого использования (бонус для нас).

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

Стоимость столкновения с такой проблемой в производстве будет очень высокой для нас, поэтому нам крайне необходимо принять правильное решение, прежде чем мы отправимся на какой-либо конкретный пакет. Если вы знаете любую другую проблему, связанную с Qt, которая может возникнуть в нашем конкретном контексте (я признаю, что было невозможно провести очень обширное тестирование пакетов), я также очень хочу сказать об этом.

ОТВЕТЫ

Ответ 1

На мой взгляд, Qt достаточно стабильна, если вы следуете их стилю кодирования. Я также хотел бы купить поддержку от Digia и использовать стабильную версию библиотеки.

Дело сводится к:

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

В моем опыте сертификации медицинских устройств громкий крах устройства предпочтительнее бесшумной и ошибочной работы. Если вы сомневаетесь, спросите орган по сертификации, который следует за вашим делом.

Кроме того, взгляните на стандарты (например, 60601-1-4 или что-то еще, что используется сейчас).

Использование Qt в медицинских приложениях: http://qt.nokia.com/qt-in-use/qt-in-medical/

Ответ 2

Я бы рассмотрел основные принципы высоконадежной инженерии. С ними вы можете использовать Qt. Теперь, Амброз Bizjak упоминает довольно много "хлопотных" сценария. Они не имеют значения, когда вы следуете основным правилам.

Итак, что это за правила? Они не очень тяжелые. Определите биты, которые могут выйти из строя, и выполняйте те времена, когда отказ не является критическим. Например, Ambroz имеет хорошую точку зрения на удаление окна. Не делайте этого в середине экзамена. Выгрузите объекты в очереди отложенной удаления и убедитесь, что они не мешают операциям (т.е. Объекты должны иметь пассивное состояние, например, для виджетов, которые включают в себя невидимость). Аналогичным образом, перед началом экзамена создайте все объекты, которые могут вам понадобиться (включая все возможные диалоговые окна).

Вы можете смириться с этим как

  • Подготовка, которая может выйти из строя
  • Все, что может не получиться
  • Очистка, которая может выйти из строя

Я бы избегал QML по уже упомянутым причинам. В приведенной выше схеме подчеркивается, почему это так проблематично. Вы не можете переместить все подозрительные шаги QML на этап подготовки.

Ответ 3

Я предполагаю, что вы не разрабатываете критичное для безопасности устройство, потому что у вас работает Windows, и лицензионное соглашение Windows имеет несколько вещей, чтобы сказать об этом. Поэтому ваш вопрос действительно: "Мы делаем потребительский продукт, который должен быть как можно более стабильным, или мы будем выглядеть действительно, очень плохо".

Лично я мог бы предложить использовать С#, потому что у него отличные инструменты под окнами и значительно проще и безопаснее разрабатывать (сборщики мусора - ваш друг для стабильности, если не производительности) и немного удобнее для unit test. Используйте С++ или С++/CLR для любых критически важных разделов, но нет причин использовать такой сложный и потенциально опасный язык для построения вашего графического интерфейса.

Ответ 4

Из моего опыта с Qt это плохой выбор, когда важна надежность. Например, многие сбои вызваны, казалось бы, правильным кодом, но который сделал что-то в определенном контексте, что некоторая часть Qt не ожидала. Здесь я перечисляю некоторые проблемы, с которыми я столкнулся с Qt относительно написания правильного кода:

  • Удаление QObjects (чтение: все) - очень болезненная процедура. Если вы удалите его из сигнала, испускаемого этим объектом (прочитайте: половина времени), ваша программа, скорее всего, потерпит крах, потому что код, излучающий сигнал, не будет проверять, сохраняется ли объект после того, как вы передадите обработчик сигнала, и может продолжайте использовать его.

  • Если вы посмотрите более внимательно, предлагаемое решение - использовать QObject:: deleteLater(), который заставит цикл события удалять объект когда-нибудь, когда он будет безопасным. Хотя это может показаться приемлемым, считайте, что за это время объект все еще существует и может излучать сигналы. Это вводит ненужные промежуточные состояния, с которыми вам приходится обращаться, и это приведет к ошибкам; вероятные, которые случаются редко и в очень специфических обстоятельствах (читайте: не пока вы его проверяете). В любом случае эта страница обсуждает некоторые проблемы с удалением QObject.

  • Другие классы в Qt имеют похожие проблемы, связанные с удалением. Например, QGraphicsScene:: removeItem() может привести к сбою, если вы удалите элемент из своей сцены (не удаляете его) в своем обработчике mousePressEvent. И это нигде не документируется.

  • Qt-классы полны удобных функций, смешанных с основным набором функций, что затрудняет определение того, как класс действительно работает и как его правильно использовать. Например, QProcess, помимо сигнала stateChanged(), который является единственным необходимым, имеет такие сигналы, как error(), finished() и start(), чья семантика и правильная обработка не совсем понятны.

  • Многие абстрактные интерфейсы плохо разработаны и плохо определены. Например, класс QIODevice используется как для чтения, так и для записи, а также для блокировки и асинхронного ввода-вывода. Класс свободен, чтобы выбрать, какое подмножество этого реализовать. Это нарушает всю идею абстрактных интерфейсов, которая заключается в том, что все, что реализует интерфейс, работает определенным и последовательным образом.

  • Существует не очень хороший и единый способ обработки событий. В Qt: QEvents есть два типа событий: для которых обратные вызовы устанавливаются путем переопределения виртуальных функций и сигналов. Зачем? В любом случае, оба вида событий в конечном итоге касаются вызовов функций (прямо, забудьте о поставленных в очередь сигналах здесь). Это означает, что различные модули могут общаться только посредством вызова друг друга. Как было замечено, это проблематично, потому что, когда модуль вызывает другой модуль, этот другой модуль действительно мог бы что-либо сделать, и может быть сложно рассмотреть все возможные сценарии на каждом сайте обратного вызова (как мы видели, Qt не, и вместо этого сбой).

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

Подводя итог, если вы нацелены на максимальную надежность, вам не нужны такие проблемы дизайна в рамках, на которых вы основываете программу, и вы не хотите обходиться с ней практически на каждом шагу. Даже если вы правильно обойдете все проблемы, о которых можете подумать, откуда вы знаете, что их больше нет? Я думаю, вам стоит просто попробовать написать совершенно правильный код в Qt (то есть прочитать всю документацию и подумать на каждом шаге, что вы делаете и как будет реагировать инфраструктура). Через некоторое время спросите себя: доверяете ли вы фреймворку или чувствуете, что пытаетесь обмануть вас?