В устройстве выделяется 3 уровня программного обеспечения:

• верхний (пользовательский интерфейс оператора «прибора»);
• основной (программное обеспечение основного вычислительного модуля);
• аппаратный (программное обеспечение модуля обладающего своим MCU);

Данный уровень программного обеспечения предназначен для взаимодействия оператора с прибором. Он обеспечивает:

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

С точки зрения физического уровня пользовательский интерфейс (далее GUI) взаимодействует с основным вычислительным модулем (далее материнская плата) посредством USB, RS-232/485, Ethernet (LAN, Wi-Fi, GSM), Bluetooth. GUI отправляет команды управления (номера рецептов) в материнскую плату, где находится модуль исполнения рецептов, обрабатывающий команды и выполняющий рецепты последовательно из сформированной очереди.

Структура посылки верхнего уровня.

Перечень команд протокола верхнего уровня.

Под основным уровнем программного обеспечения подразумевается программа выполняемая в основном вычислительном модуле. Задачи данного программы уровня:

• Выполнение основной логике прибора (Модуль исполнения рецептов). В данном случае в приборе реализованы алгоритмы всех возможных рецептом. Каждый рецепт имей свой идентификатор доступный пользователя ПК. Так же данная программа хранит в себе все тайминги для выполнения рецептов и ключевые значения для проверки правильности его выполнения. В данном уровне кода реализованы все алгоритм сценариев отработки ошибок. Что имеется в виду — ошибка аппаратного уровня (модуля) может повлиять на работу не только самого модуля но и других узлов входящих в состав прибора. По этому основной уровень программного обеспечению все цело и полностью владеет информацией критериях ошибок от каждого из модулей и алгоритма поведения всего прибора при возникновении такой ошибки в одном из модулей.
• Возможность конфигурирования (Конфигурационный модуль). Основной код программы должен обеспечить получение от пользователя конфигурационных данных своего узла. Разбить эти данные на соответствующие конфигурационные параметры и отправить их соответствующему модулю аппаратного уровня. В случае отсутствие и аппаратного модуля (узла) своего собственного MCU (данный модуль подключен на прямую к вычислительному модулю по одному из физических интерфейсов SPI, I2C, UART и является ведомой периферией для вычислительного модуля), вычислительный модуль повторяет алгоритм хранения и применения параметров как был описано для аппаратный уровня с одним уточнение что данные параметры хранятся во FLASH памяти вычислительного модуля. Данная часть программного обеспечения знает абсолютно все о физических интерфейсах взаимодействия с периферийными модулями.
• Взаимодействие с GUI (Модуль взаимодействия с GIU) производится через отправку следующих сообщений:

a.	Применить свойство.
б.	Выполнить команду.
в.	Вычитать состояние
г.	Отправить сообщение

Для такого взаимодействия доступны следующие физические интерфейсы (USB, RS-232/485, Ethernet (LAN, Wi-Fi, GSM), Bluetooth).

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

Данный уровень относится к модулям, которые имеют свой MCU и взаимодействуют с основным вычислительный модулем. Для данного программного обеспечения характеры следующие свойства: 1. Самодостаточность: Данное ПО запускается на модуле сразу после подачи питания. Для данных устройств характерно наличие встроенной FLASH памяти хранящей базовые конфигурационные настройки модуля. После подачи питания и вычитывание базовых настроек модуль переходит в выполнению внутреннего алгоритма с мониторингом своих критических ошибок. В зависимости от физического интерфейса связи с вычислительным модулем сообщение о наличие ошибки может выполнять в виде посылки сообщения, либо выставления флага, который будет вычитан вычислительном модулем во время следующего сеанса связи с данным устройством. При этом устройство само может отрабатывать заложенные в него аварийные алгоритмы (требует обсуждения). 2. Зависимое: При всей своей самодостаточности устройство полностью зависимо от команд вычислительного модуля. По этим подразумевается следующее: после подачи питания, считывания и применения конфигурации по умолчанию устройство (модуль), переходит в бесконечный цикл ожидания команды от вычислительного модуля с мониторингом своих внутренних состояний. От вычислительного модуля доступны следующие типы команд:

• изменить параметр конфигурации периферии модуля или все конфигурацию целиком
• вычитать текущую конфигурацию периферии устройства или всего устройства целиком.
• выполнить команду (для каждого устройства набор команд и их структура будет индивидуальным). Так как набор параметров у каждого устройства фиксированное число то будет реализован следующий алгоритм хранения этих параметров во FLASH памяти: в определенную область при производстве будет зашиваться базовая конфигурация которая будет защищена от записи (золотая конфигурация). Оставшаяся память будет разделена на равные сегменты в которых будет храниться конфигурация которую будет применять вычислительный модуль (пользователь). При подачи питания модуль будет проверять наличие пользовательской конфигурации в случае ее отсутствия будет производится вычитка (золотой конфигурации).

3. уникальность. Каждый модуль будет иметь свой уникальный идентификатор (расширение на будущее). (отработка данного подхода на модуле управления шаговыми двигателями)

Целью моделирования является описание и отладка полного алгоритма работы анализатора в связке с пользовательским интерфейсом. Модель должна описывать все физические взаимосвязи работы устройства с целью моделирования реальных перемещений при отработке алгоритмов управления, а также моделировании нештатных ситуаций и отработка пользовательского интерфейса. В результате этой работы, на основании модели появляется возможность сгенерировать: 1.Набор и количество плат драйверов периферийных устройств и необходимые конфигурации драйверов для управления конкретным анализатором 2.Набор рецептов и настроек системы автоматизации, корректно работающей с ПО управления и реализующих полный функционал устройства 3.Схему подключения гидравлики и электроники внутри прибора. 4.В перспективе также появляется возможность генерирования модели микрофлуидного блока на основании гидравлической схемы, заложенной в модели, с учетом технологических особенностей используемых элементов (по аналогии с алгоритмами трассировки печатных плат по принципиальной схеме) Система моделирования должна иметь вложенную систему, основанную на описании элементарных (неделимых) элементов и сборок, описывающих взаимосвязи между составными частями. Деление на части должно быть разбито на модули функционально повторяющиеся в различных анализаторах. Такой подход позволит унифицировать разработку и дальнейшую автоматизацию новых устройств. Общая структура модели приведена ниже: Пользовательский интерфейс отправляет команды управления в материнскую плату контроллера, где находится модуль исполнения рецептов, обрабатывающий команды и выполняющий рецепты последовательно из сформированной очереди. Во время исполнения рецепта генерируются команды переключения между состояниями виртуальных модулей, соответствующих функциональным подсистемам. Состояния каждой из подсистем описаны в виде элементарных перемещений конкретных исполнительных механизмов, хранящиеся в модулях драйверов и реализующих управляющие сигналы на элементарные исполнительные устройства. Эти сигналы в виде циклограмм импульсов на конкретных разъемах драйверов поступают в модель аналиазтора, которая принимает их на входе и моделирует движение всего устройства. Контроль правильности отработки системы производится при помощи контрольных виртуальных датчиков, определяющих положения и состояния конкретных элементов, модели анализатора (положение кареток, наличие и правильный тип жидкости в трубках и т.п.) и по ответным сигналам в пользовательском интерфейсе. После составления модели ее части (рецепты, конфигурация устройств, схема подключения контроллера и прочее) должны иметь возможность либо непосредственного исполнения в ПО реального контроллера или транслироваться в исполняемый промежуточный код (согласовывается на этапе разработки). Это позволит использовать результаты моделирования в реальных устройствах и существенно ускорить и упростить отладку.

Система моделирования подразделяется на следующие составляющие: Модель таблицы рецептов Задача модели разложить рецепт согласно таблицы рецептов на выполняемые шаги и перечень устройств задействованных в данном шаге. По сути модель таблицы рецептов представляет из себя TCP сервер который слушает заданный порт. Получив команду выполнения рецепта от GUI

Девайсом является конечное простое устройство имеющее набор конечных входных и выходных состояний изменяющихся по заложенному алгоритму.

Девайс материнская плата представляет из себя устройство которое слушает заданный порт (при физическом исполнении к материнской плате подключены драйвера по различным интерфейсам Ethernet, RS-232, RS-485, CAN, USB и т.п.). Структура МП должна содержать интерфейс по которому к ней будут подключатся девайсы (GUI пользователя и драйвера устройств) и входные данные. В случае модели в качестве порта будет выступать TCP сокет (IP адрес и номер порта) который ждет клиентов. В качестве клиентов выступаю драйвера устройств и GUI пользователя. Структура взаимодействия МП с клиентами изображена на схеме.

Драйвер обеспечивает управление

По каналу 1 (от GUI) на материнскую плату приходит номер рецепта. Материнская плата получив рецепт раскладывает его на под рецепты согласно таблице рецептов. То есть разбивает рецепт на устройства задействованные в нем и порядок положений для каждого устройства для выполнения заданного рецепта. Так же на материнской плате хранится логика положений согласно которой происходит построение последовательности движений по положениям (пример: двигатель не может перейти из положения 1 в положение 2 пока не откроется клапан, а закрытие клапана возможно только при положении 1 двигателя). Далее по каналу 2 МП посылает на драйвер положение в которое должен перейти его девайс. В свою очередь драйвер содержит в себе таблицу положений согласно которой происходит перевод девайса из одно положения в другое. Драйвер получив номер положения отправляет по каналу 3 действия которые должен выполнить девайс что бы занят требуемое положение. В ответ девайс шлет на драйвер положение в котором он сейчас находиться при получении команды и при достижении требуемого положения. Либо ошибку, если не получилось достичь требуемого положения. Драйвер транслирует на МП положение в котором находится девайс.

входные внутренние параметры: количество шагов на оборот (например SRP = 200) входные внешние параметры: шаг (например step), направление движения (например dir 0,1,-1) выходные параметры (состояние): угол перемещения (например position) формула расчета состояния: position += direction * 360.0/SPR * step

входные внутренние параметры: позиция упора (например limitPosition) входные внешние параметры: позиция (например position) выходные параметры (состояние): достижение предела (например lockedState = false) формула расчета состояния: if (position >= limitPosition) lockedState = true

входные внутренние параметры: передаточное число (например SRP = 400) входные внешние параметры: позиция (например positionIn) выходные параметры (состояние): угол перемещения (например positionOut) формула расчета состояния: positionOut = positionIn /SPR

public class Leadscrew(

  context: Context,
  public val leverage: NumericalValue<Meters>,

) : ModelConstructor(context) {

  public fun torqueToForce(
      stateOfTorque: DeviceState<NumericalValue<NewtonsMeters>>,
  ): DeviceState<NumericalValue<Newtons>> = DeviceState.map(stateOfTorque) { torque ->
      NumericalValue(torque.value / leverage.value )
  }

  public fun degreesToMeters(
      stateOfAngle: DeviceState<NumericalValue<Degrees>>,
      offset: NumericalValue<Meters> = NumericalValue(0),
  ): DeviceState<NumericalValue<Meters>> = DeviceState.map(stateOfAngle) { degrees ->
      offset + NumericalValue(degrees.value * 2 * PI / 360 * leverage.value )
  }

}

Комбайном является устройство собранное из нескольких девайсов. На выходе комбайна формируется комбинированное состояние от состояний входящих в него девайсов.

В состав плоттера входят два двигателя, две винтовые передачи и четыре концевых ограничителя. На выходе плоттера комбинированное состояние положения обоих двигателей.

Движение поршня шприца осуществляется путем воздействия двигателя. Входными параметры поршня: объём шприца в мл (volume), длина поршня в мм (rodLength), коэффициент передачи трансмиссии в мм/об/мин (transmissionCoefficient) и скорость вращения двигателя в об/мин (rotationSpeed). Выходные параметры текущий объём в мл. Для расчёта необходимо вычислить перемещение поршня в мм (rodDisplacement = transmissionCoefficient * rotationSpeed). Текущий объём = volume * rodDisplacement / rodLength