Skip to content

Latest commit

 

History

History
64 lines (54 loc) · 9.12 KB

README.md

File metadata and controls

64 lines (54 loc) · 9.12 KB

К заданию прилагается диаграмма описывающая как можно подойти к решению задачи. Некоторые моменты (в частности работы с алгоритмами шифрования) явно не отражены в диаграмме. Следование ей не является обязательным.

Задача - реализовать сервер мониторинга и управления состоянием устройств (DeviceMonitoringServer) и покрыть реализацию unit-тестами.

Общение сервера и устройства осуществляется через вспомогательные классы клиента (AbstractClientConnection) и сервера (AbstractConnectionServer).
Задача этих классов - установка клиент-серверного соединения и передача по нему сериализованных сообщений.

В проекте предоставлены реализации ClientConnectionMock и ConnectionServerMock для эмитации передачи сообщений между клиентом (AbstractClientConnection) и сервером (AbstractConnectionServer).

  1. Описание устройства (эмитируется с помощью DeviceMock):
  • Задача устройства - выполнение измерения и управление некоторым физическим параметром (например, мощностью или температурой).
  • Устройство имеет уникальный идентификатор (deviceId).
  • Устройство выполняет измерение некоторого физического параметра.
  • Область определения измеряемого физического параметра [0, 100]
  • Устройство запрашивает подключение у сервера (п.2).
  • При установлении соединения с сервером устройство начинает отправку серверу сообщений с текущим измерением (п.4).
  • Устройство принимает от сервера сообщения с командой корректировки физического параметра.
  1. Описание сервера (DeviceMonitoringServer):
  • Задача сервера - получение от устройств значений текущих измерений, сравнение измерений с планом по данному устройству и, если необходимо, отправка устройству команд на корректировку параметра.
  • Серверу назначается план значений физического параметра (п.3) по каждому устройству (п.1).
  • Сервер принимает запрос на подключение от устройства (п.1).
  • Сервер получает от устройства (п.1) сообщения с текущим измерением (п.4).
  • Сервер сравнивает полученное значение измерения с планом и отправляет устойству либо сообщение с командой корректировки физического параметра, либо сообщение с ошибкой (п.7).
  • Сервер собирает статистику работы каждого устройства (п.7) - СКО ошибки управления физическим параметром на каждом этапе плана (п.3).
  1. Описание плана работы устройств (DeviceWorkSchedule):
  • План содержит идентификатор устройства, для которого предназначен план.
  • План состоит из этапов - списка пар <Метка времени начала этапа, Требуемое значение физического параметра на этапе>
  • Метки времени начала этапов строго возрастающие.
  • Метка времени начала этапа характеризует момент времени, начиная с которого (включительно) измеряемый физический параметр должен принимать Требуемое значение.
  1. Описание пересылаемых сообщений:
  • Сообщение - структура с набором данных.
  • Сообщение сериализуется в строку с помощью модуля сериализации (п.5) и шифруется с помощью модуля шифрования (п.6)
  • Каждый тип сообщения имеет свою структуру.
  • Тип сообщения может быть некоторым числовым идентификатором, например, enum.
  • Типы сообщения: Meterage, Command, Error.
  • Сообщение с измерением содержит значение измерения и метку времени измерения.
  • Сообщение с командой управления содержит корректировку параметра.
  • Сообщение со статусом содержит тип ошибки.
  • Типы ошибки: NoSchedule, NoTimestamp, Obsolete

  1. Описание модуля сериализации/десериализации (MessageSerializator):
    Задача данного модуля - сериализация и десериализация структур сообщений для их последующей передачи через клиент-серверное соединение.
    Возможное решение - запись полей структуры в std::ostringstream и чтение полей структуры из std::istringstream.
    Для определения структуры полученного сообщения при десериализации тип сообщения помещается в строку первым.

  2. Описание модуля шифрования/дешифрования (MessageEncoder):

  • Задача модуля - шифрование и дешифрование сериализованных сообщений для последующей передачи через клиент-серверное соединение.
  • Нобходимый интерфейс класса - метод шифрования, метод дешифрования, метод выбора алгоритма шифрования, метод регистрации новых алгоритмов.
  • В метод регистрации произвольного алгоритма шифрования передается объект класса, унаследованного от BaseEncoderExecutor.
  • BaseEncoderExecutor содержит в себе виртуальные методы encode и decode, которые принимают и возвращают строку, а также name, возвращающий имя алгоритма.
  • Алгоритмы, которые должны быть доступны по умолчанию: ROT3, Mirror (58 -> 85, 29 -> 92), Multiply41 (значение при шифрации умножается на 41, 7 -> 287, 64 -> 2624).
  1. Требования к командному центру (СommandCenter):
  • Принимаемые сервером измерения поступают в коммандный центр.
  • Коммандный центр выполняет сравнение значения измерения с требуемым согласно плану.
  • Если для данного устройства и текущей метки времени есть план, отправляется команда с величиной корректировки для достижения этого плана (корректировка может быть нулевой).
  • Если для данного устройства нет плана, то отправляется ошибка NoSchedule.
  • Если для данного устройства есть план, но в него не попадает текущая метка времени, то отправляется ошибка NoTimestamp.
  • Если на сервер поступает измерение с устаревшей меткой времени (ранее от устройства было принято измерение с большей меткой времени), то отправляется ошибка Obsolete.
  • Коммандный центр собирает статистику по работе устройства, а именно, СКО ошибки управления физическим параметром на каждом этапе плана.