Симуляторы и роботы в разработке надежного медицинского оборудования

В сфере разработки медицинского ПО, как и в любой другой области, не существует «серебряной пули» – единственного решения, применение которого всегда и в любых случаях было бы оправданно и давало бы результаты. Однако, как показывает наш опыт, существует два метода, которые в сочетании позволяют нивелировать взаимные недостатки и показать взаимные преимущества.

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

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

Плюсы и минусы цифровых двойников в разработке медицинского ПО

Имеется несколько базовых сценариев, когда принимается решение о применении в разработке «цифровых двойников»: 

• В случае разработки программно-аппаратной платформы долгий срок разработки аппаратной части («железа») не позволяет начать разработку ПО до появления действующих функциональных прототипов «в железе»; 
• Наличие цифровых двойников позволят не только начать разработку ПО раньше, но и помочь разработчикам аппаратной части: например, «в цифре» могут быть смоделированы несколько вариантов возможных решений и выбран тот вариант, который проявит себя наилучшим образом; 
• Различные варианты тестирования, когда применяется разрушение аппаратной части или входящих в ее состав компонент для проверки, каким образом ПО обнаружит подобные ситуации и как отреагирует – для финального тестирования обычно в любом случае применяется разрушение реальных компонент, но на этапе разработки ПО и методов контроля это чрезмерные затраты; 
• Нет возможности (слишком дорого или нужны специальные условия, или оборудование занимает много места и т.д.) оборудовать рабочее место каждого разработчика или инженера по тестированию своим собственным экземпляром разрабатываемого устройства и/или в разработке находится сразу множество вариантов устройств; 
• Изучение покрытия кода всеми наборами тестов – от юнит-тестов до автоматических и ручных – для достижения максимального покрытия кода;
• Автоматизация тестирования: при разработке «цифрового двойника» сразу же закладывается возможность взаимодействия с ним в автоматическом режиме, что значительно сокращает нагрузку на команду инженеров по тестированию и снижает влияние человеческого фактора. 

Все указанное выше приводит к тому, что называется в индустрии «сдвиг влево» (расписания проекта): все, что может быть сделано раньше, необходимо сделать раньше. Реализуется ежедневное регрессионное тестирование и каждое утро разработчики получают отчет о работоспособности всего комплекса. 

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

• Simulation gap (разрыв в симуляции): всегда будет существовать разница между реальным физическим устройством и симулированным «цифровым двойником», разработанным на базе математической модели этого устройства. Даже если наша математическая модель максимально точна или «достаточно хороша» для решения поставленной задачи, реальное устройство может вести себя несколько иначе. 
• Валидация симулятора: с точки зрения медицинских стандартов, любой инструмент, который делает что-то в автоматическом режиме, необходимо провалидировать, т.е. подтвердить, что он на самом деле делает то, для чего он предназначен. 

Разрыв в симуляции обычно становится заметным, когда прототип устройства уже есть «в железе» и можно детально изучить его характеристики. При этом, во-первых, модели симулятора можно доработать таким образом, чтобы они максимально точно (насколько это возможно) соответствовали реальному поведению, а во-вторых, это можно использовать и для улучшения. Например, мы знаем, что «в железе» какая-то ошибка проявляется редко и при особом стечении обстоятельств, и модифицируем модель таким образом, чтобы данная ошибка проявлялась тогда, когда нам нужно. Это позволяет точно протестировать, как логика ПО будет реагировать на эту и любые другие ошибки (или их сочетание). 

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

Как роботы помогают тестировать медицинское оборудование

У робота при тестировании медицинских устройств имеется ряд своих преимуществ:

• В тестируемом ПО нет никаких модификаций, необходимых только для тестирования;
• В тестируемом устройстве отсутствуют какие-либо модификации «железа», необходимые только для тестирования.

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

• Можно в параллельном режиме тестировать любое количество устройств;
• Всегда фиксируются временные параметры тестов (например, если ошибка проявляется только при сотне подряд нажатий одной или нескольких кнопок на устройстве с разницей в доли секунд, человек никогда не сможет в точности дважды повторить такой тест);
• Можно в широких пределах варьировать любые временные параметры тестов;
• Автоматически ведется видеозапись всех тестов и есть возможность просмотра тех тестов, к работе которых возникли какие-либо вопросы или подозрения;
• И, разумеется, роботы не устают и не уходят в отпуск. 

Если результаты работы робота пойдут «в зачет», то с точки зрения требований медицинских стандартов снова появляется требование валидации самого робота. Но и в этом случае у производителя есть пространство для выбора: 

• Обычно робот намного проще и стоимость его валидации значительно ниже, чем стоимость валидации полноценного «цифрового двойника»;  
• Формальная финальная валидиция медициского устройства проводится вручную, а робот используется для выявления регрессий, нагрузочного тестирования и т.д., что значительно сокращает затраты на ручное тестирование – его можно будет проводить только тогда, когда все автоматические тесты выполнены успешно и мы на 100% уверены, что при ручном тестировании не будет никаких сбоев и время людей-инженеров по тестированию не будет потрачено впустую.

Подведем итоги

Таким образом, совмещение всех указанных выше методов позволяет разработчикам использовать сочетание преимуществ и нивелировать недостатки всех подходов: 

1. Цифровые двойники: максимально ранний старт разработки ПО, стратегии тестирования, отладка и изучение аппаратных решений. 
2. Роботы: тестирование не «максимально похожих», а ровно тех же устройств, которые будут поставляться потребителям. 
3. Ручное тестирование (при необходимости): отсутствие затрат на валидацию при максимально эффективном использовании трудозатрат и рабочего времени.