eng
Выпуск #5/2023
С. Белов
ГЕНЕРАТОР ТЕСТОВОЙ ТЕЛЕМЕТРИИ: УСКОРЕНИЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ИЗДЕЛИЙ СИСТЕМ УПРАВЛЕНИЯ ПРИ ОТСУТСТВИИ ИЗДЕЛИЯ И ЕГО КОНТРОЛЬНО-ПРОВЕРОЧНОЙ АППАРАТУРЫ
ГЕНЕРАТОР ТЕСТОВОЙ ТЕЛЕМЕТРИИ: УСКОРЕНИЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ИЗДЕЛИЙ СИСТЕМ УПРАВЛЕНИЯ ПРИ ОТСУТСТВИИ ИЗДЕЛИЯ И ЕГО КОНТРОЛЬНО-ПРОВЕРОЧНОЙ АППАРАТУРЫ
Просмотры: 711
DOI: 10.22184/1992-4178.2023.226.5.118.125
В статье приведена технология создания заготовок программного обеспечения для контрольно-проверочной аппаратуры (КПА) еще до того, как будет изготовлена не только КПА, но и изделие, для которого она предназначена. Такой подход позволяет сократить общий срок выполнения заказа (изделие плюс КПА), оптимизировать требования к ресурсам КПА и режимам получения телеметрии, избежать некоторых трудоемких, а иногда – неисправимых ошибок разработки.
В статье приведена технология создания заготовок программного обеспечения для контрольно-проверочной аппаратуры (КПА) еще до того, как будет изготовлена не только КПА, но и изделие, для которого она предназначена. Такой подход позволяет сократить общий срок выполнения заказа (изделие плюс КПА), оптимизировать требования к ресурсам КПА и режимам получения телеметрии, избежать некоторых трудоемких, а иногда – неисправимых ошибок разработки.
Теги: development speed software development telemetry test and verification equipment test and verification equipment self-diagnosis контрольно-проверочная аппаратура разработка по самоконтроль кпа скорость разработки телеметрия
Генератор тестовой телеметрии: ускорение разработки программного обеспечения для изделий систем управления при отсутствии изделия
и его контрольно-проверочной аппаратуры
С. Белов1
Между утверждением документации на разработку изделия систем управления (далее – ИСУ) и фактическим его изготовлением на заводе существует значительный промежуток времени. В это время можно создавать заготовки программного обеспечения (далее – ПО) контроля ИСУ, просмотра / получения / архивирования телеметрии ИСУ и т. д., используя утвержденные технические условия (далее – ТУ) на изделие. Скорость и качество разработки данных заготовок можно повысить, создав ПО генерации тестовой телеметрии ИСУ, – для отладки ПО, работающего с телеметрией ИСУ. В результате сокращается время разработки ПО работы с телеметрией ИСУ до состояния «релиз» – еще до фактического изготовления ИСУ.
Введение
Отсутствие технического оснащения и человеческий фактор приводят к увеличению срока разных этапов разработки ПО. В бизнес-процессах выделяют критический путь [1] – совокупность этапов, которые невозможно обойти и без выполнения которых продолжение работ в целом невозможно. В случае с ПО, имеющим отношение к телеметрии ИСУ, возникают периоды ожидания:
получения макетного ИСУ как физического объекта получения телеметрии;
создания контрольно-проверочной аппаратуры (далее – КПА) как физического источника телеметрии;
разработки ПО контроля ИСУ как программного инструмента приема телеметрии;
взаимодействия с разработчиком ПО контроля ИСУ как программного механизма согласования выходных файлов телеметрии ИСУ и их формата данных;
тестирования критического пути, возможного только после завершения его разработки, как наиболее востребованного и взаимосвязанного функционала [2].
В соответствии с этапами реального процесса разработки ИСУ, КПА и ПО самоконтроля КПА могут возникать следующие периоды ожидания:
КПА из-за отсутствия макетного изделия;
ПО контроля ИСУ и ПО самоконтроля КПА из-за отсутствия КПА;
ПО просмотра / анализа / архивирования телеметрии из-за отсутствия файлов телеметрии КПА / ИСУ;
уникальных алгоритмов диагностики неисправностей КПА / ИСУ из-за отсутствия ПО просмотра / анализа телеметрии КПА / ИСУ.
В итоге, самым уязвимым звеном становится разработчик ПО, работающий с телеметрией ИСУ, из-за наибольших вынужденных задержек в разработке:
нельзя подключать ИСУ к КПА, пока не будет получен положительный результат от ПО самоконтроля КПА. Это может порождать самый длительный период ожидания;
неизвестен фактический размер файлов телеметрии – невозможно рассчитать объем архивируемой телеметрии за период времени, время загрузки телеметрии в ПО при ее открытии, время прорисовки графиков при ее анализе и т. д. Это, в свою очередь, порождает именно отсроченные ошибки: недостаток места в архивном хранилище телеметрии или самом КПА. Следствием станут преждевременная модернизация КПА, долгая загрузка телеметрии и открытие графиков из-за неверного создания структур данных или механизма импорта, неверного выбора компонента по отображению графиков и т. д. Часть этих ошибок, при условии частичной готовности ПО, может быть уже неисправимой: весь функционал сосредоточен вокруг определенных объектов ПО, и переписывать ПО с нуля, как правило, не представляется возможным;
неизвестен формат файлов телеметрии – возможно предварительное создание только внешнего вида пользовательского интерфейса ПО просмотра телеметрии ИСУ;
на момент, когда сроки разработки ПО уже истекли, создается иллюзия, что именно разработчик ПО просмотра / анализа телеметрии ИСУ виновен в задержке поставки всего комплекса. Сроки разработки именно для этого разработчика становятся самыми сжатыми, вероятно внешнее психологическое давление. Данный вопрос может решиться написанием облегченной версии ПО просмотра телеметрии, что приведет к понижению его функционала, то есть к понижению качества продукции при неизменной стоимости для заказчика;
последующая спешка разработчика ПО контроля ИСУ приводит к неоптимальному размеру файлов телеметрии и формата данных в них (для некоторых изделий достигает 400 МБ за 1 тест), а также к вероятности возникновения в телеметрических массивах избыточности данных, не имеющей практического смысла.
Создание ПО,
генерирующего телеметрию
при отсутствии ИСУ / КПА
Для защиты разработчика ПО работы с телеметрией ИСУ / КПА, ускорения сроков разработки данного ПО и повышения его качества – предлагается искусственная генерация телеметрии еще физически не существующего ИСУ / КПА.
Для этого имеются базовые исходные данные: ТУ на ИСУ / КПА уже утверждено, а значит, точно известно количество и названия параметров, их длительность, верхний и нижний пределы и т. д. Остается в самом начале разработки комплекса и ПО работы с телеметрией поставить вопросы о формате файлов телеметрии и их количестве, алгоритмах расположения на диске, количестве сохраняемых параметров, частоте сохранения данных. При этом необходимо учитывать, что во время практической разработки как самих файлов, так и механизма импорта формат файлов, как и их размер, может значительно изменяться. Имея эту информацию, можно использовать ПО «Генератор телеметрии» [3] (рис. 1) для создания файлов телеметрии по уже согласованному формату.
Приведенное на рис. 1 ПО было написано самостоятельно, поскольку анализ HEX-редакторов и генераторов данных (приложение А) показал, что они не подходят для задачи создания телеметрии ИСУ / КПА. В процессе разработки появились уточнения по типам данных (приложение Б).
Концепция генерации телеметрии:
пошаговое создание блоков алгоритма, по которому будет строиться файл телеметрии;
выбор максимально возможного количества типов данных в целях унификации генератора – возможности его использования не только для ИСУ;
создание цикличности выполнения блоков – как генерации данных внутри блока, так и генерации множества блоков. Проверка корректности цикличности алгоритма перед его запуском;
добавление контрольной суммы в начале или конце файла. Не все разработчики придерживаются мнения о целесообразности внедрения контрольных сумм в файлы, как и использования Венгерской нотации [4, 5], хотя их роль в безопасности файла и удобочитаемости исходного кода значительна и включена в рабочие программы учебных дисциплин Минобрнауки [6, 7, 8, etc].
Преимущества
Генератор избавляет от ошибки человеческого фактора, когда файлы тестовой телеметрии программист составляет вручную, изготовляя отдельный исходный код для данной задачи (то есть дополнительное ПО). Если же программист сторонний, ситуация усложняется: при обнаружении ошибки возникнет спор, у кого из разработчиков она допущена – при создании телеметрии или при ее импорте. Это приводит к изнурительному анализу файлов телеметрии в HEX-редакторе, что опять добавляет возможность ошибки человеческого фактора. Необходимость использования HEX-редактора, в свою очередь, приводит к увеличению файла телеметрии. Например, приходится хранить данные «время1, значение1, ... , время1 значение67» вместо «время1, значение1, …, значение67», так как анализ последнего в содержимом файла значительно сложнее.
Сгенерированная телеметрия, в отличие от реальной телеметрии ИСУ, может содержать намеренно сильно отличающиеся друг от друга данные, что исключает ошибки смещения при импорте как по названию параметра, так и по времени. Например, параметры гиромоторов в оригинальной телеметрии ИСУ содержат практически идентичные значения тока и названия – при импорте данных они могут оказаться перепутаны, и это не видно глазу даже при визуальной отладке. Если же файлы телеметрии ИСУ создает генератор, можно задать условия, когда значения графиков будут отличаться значительно и предсказуемо, и каждый из параметров попадет именно в свою ячейку массива данных ПО просмотра / анализа телеметрии. Кроме того, намеренно искаженные данные могут использоваться для тестирования различных механизмов, вроде автоматического поиска ошибок, изменения цвета графика, пределов возможностей компонентов разработки и т. д.
Еще одним достоинством предлагаемого подхода является то, что сразу виден фактический размер выходного файла одного теста. Фактический размер может отличаться от теоретического десятикратно и выше. Например, разработчик ПО контроля ИСУ принял решение сохранять в файл телеметрии аналоговые параметры с избыточным периодом 1 мс вместо 12 мс. Использование генератора телеметрии дает время для его переубеждения, демонстрируя факт чрезмерно большого размера выходного файла, и данная ошибка не войдет в релизную версию ПО для заказчика.
Пример создания генератором
телеметрии файла, схожего
с телеметрией макетного ИСУ
Пример утвержденного разработчиком контроля ИСУ формата телеметрии, созданного по формату файла генератором телеметрии, бинарного представления файла в HEX-редакторе (рис. 2, 3, 4).
Заключение
Разработан генератор телеметрии, позволяющий ускорить разработку ПО, работающего с телеметрией ИСУ, а также улучшить качество разработки такого ПО. Данный генератор может быть применен, по аналогии, при разработке ПО самоконтроля КПА без физического наличия КПА.
Стоит сделать акцент на наполнении файлов телеметрии. Утверждение «телеметрия должна содержать только полученные данные», нацеленное на уменьшение размера файлов за счет упрощения их формата, выглядит логичным лишь поверхностно. Должны сохраняться и пределы, и триггеры выхода значения за пределы, и каждое полученное значение:
ТУ может быть изменено – пределы станут иными, программа контроля ИСУ будет изменена;
триггер ошибки значения, сохраняемый в файл программой контроля ИСУ, а не рассчитываемый в ПО просмотра / анализа телеметрии, порождает сохранность состояния ошибочности телеметрии именно в момент ее получения и независимость от последующих изменений в ТУ;
аппроксимация телеметрии на определенных ее участках должна рассматриваться как целенаправленное искажение информации: в результате могут быть упущены единичные значения параметров, вышедшие за пределы минимального или максимального значений.
ЛИТЕРАТУРА
Фридлянов М. А. Методы и приемы управления проектами в сфере промышленного производства // Проблемы рыночной экономики. 2017. № 3.
Куликов С. С. Тестирование программного обеспечения. Базовый курс / 2‑е изд. Минск: Четыре четверти, 2017. С. 81.
Белов С. П. Генератор телеметрии v.1.1.1.1. Москва: личный сайт, 2021. [Электронный ресурс] URL: https://bad-good.ru/programs.html#generator_telemetry.
Кондраков С. А., Кудинов Н. А. Алгоритмы стандартизации исходного кода // Труды МАИ. 2003. № 14.
Павловская Т. А. C / C++. Программирование на языке высокого уровня. СПб: Питер, 2003. С. 18.
Институт экономики и управления АПК. Рабочая программа дисциплины Б1.О.13 «Оперативные системы» для подготовки бакалавров. М.: МСХА, 2020. [Электронный ресурс] URL: https://www.timacad.ru/sveden/files/B1.O.13_OPERACIONNYE_SISTEMY_RPD.pdf.
Факультет компьютерных технологий и прикладной математики. Рабочая программа дисциплины Б1.В.04 «Объектно-ориентированные языки и системы программирования» для подготовки магистров. Кубань: ФГБОУ ВПО КубГУ, 2018. [Электронный ресурс] URL: https://infoneeds.kubsu.ru/infoneeds/file_export.do?fid=3687032.
Владивостокский государственный университет экономики и сервиса. Рабочая программа учебной дисциплины ОП.02 «Операционные системы» для подготовки специалистов среднего звена. Владивосток: ФГБОУ ВО ВГУЭС, 2020. [Электронный ресурс] URL: https://www.vvsu.ru/files/904E34A0-616D‑4992-AA8F‑8E3DB96AB709.pdf.
и его контрольно-проверочной аппаратуры
С. Белов1
Между утверждением документации на разработку изделия систем управления (далее – ИСУ) и фактическим его изготовлением на заводе существует значительный промежуток времени. В это время можно создавать заготовки программного обеспечения (далее – ПО) контроля ИСУ, просмотра / получения / архивирования телеметрии ИСУ и т. д., используя утвержденные технические условия (далее – ТУ) на изделие. Скорость и качество разработки данных заготовок можно повысить, создав ПО генерации тестовой телеметрии ИСУ, – для отладки ПО, работающего с телеметрией ИСУ. В результате сокращается время разработки ПО работы с телеметрией ИСУ до состояния «релиз» – еще до фактического изготовления ИСУ.
Введение
Отсутствие технического оснащения и человеческий фактор приводят к увеличению срока разных этапов разработки ПО. В бизнес-процессах выделяют критический путь [1] – совокупность этапов, которые невозможно обойти и без выполнения которых продолжение работ в целом невозможно. В случае с ПО, имеющим отношение к телеметрии ИСУ, возникают периоды ожидания:
получения макетного ИСУ как физического объекта получения телеметрии;
создания контрольно-проверочной аппаратуры (далее – КПА) как физического источника телеметрии;
разработки ПО контроля ИСУ как программного инструмента приема телеметрии;
взаимодействия с разработчиком ПО контроля ИСУ как программного механизма согласования выходных файлов телеметрии ИСУ и их формата данных;
тестирования критического пути, возможного только после завершения его разработки, как наиболее востребованного и взаимосвязанного функционала [2].
В соответствии с этапами реального процесса разработки ИСУ, КПА и ПО самоконтроля КПА могут возникать следующие периоды ожидания:
КПА из-за отсутствия макетного изделия;
ПО контроля ИСУ и ПО самоконтроля КПА из-за отсутствия КПА;
ПО просмотра / анализа / архивирования телеметрии из-за отсутствия файлов телеметрии КПА / ИСУ;
уникальных алгоритмов диагностики неисправностей КПА / ИСУ из-за отсутствия ПО просмотра / анализа телеметрии КПА / ИСУ.
В итоге, самым уязвимым звеном становится разработчик ПО, работающий с телеметрией ИСУ, из-за наибольших вынужденных задержек в разработке:
нельзя подключать ИСУ к КПА, пока не будет получен положительный результат от ПО самоконтроля КПА. Это может порождать самый длительный период ожидания;
неизвестен фактический размер файлов телеметрии – невозможно рассчитать объем архивируемой телеметрии за период времени, время загрузки телеметрии в ПО при ее открытии, время прорисовки графиков при ее анализе и т. д. Это, в свою очередь, порождает именно отсроченные ошибки: недостаток места в архивном хранилище телеметрии или самом КПА. Следствием станут преждевременная модернизация КПА, долгая загрузка телеметрии и открытие графиков из-за неверного создания структур данных или механизма импорта, неверного выбора компонента по отображению графиков и т. д. Часть этих ошибок, при условии частичной готовности ПО, может быть уже неисправимой: весь функционал сосредоточен вокруг определенных объектов ПО, и переписывать ПО с нуля, как правило, не представляется возможным;
неизвестен формат файлов телеметрии – возможно предварительное создание только внешнего вида пользовательского интерфейса ПО просмотра телеметрии ИСУ;
на момент, когда сроки разработки ПО уже истекли, создается иллюзия, что именно разработчик ПО просмотра / анализа телеметрии ИСУ виновен в задержке поставки всего комплекса. Сроки разработки именно для этого разработчика становятся самыми сжатыми, вероятно внешнее психологическое давление. Данный вопрос может решиться написанием облегченной версии ПО просмотра телеметрии, что приведет к понижению его функционала, то есть к понижению качества продукции при неизменной стоимости для заказчика;
последующая спешка разработчика ПО контроля ИСУ приводит к неоптимальному размеру файлов телеметрии и формата данных в них (для некоторых изделий достигает 400 МБ за 1 тест), а также к вероятности возникновения в телеметрических массивах избыточности данных, не имеющей практического смысла.
Создание ПО,
генерирующего телеметрию
при отсутствии ИСУ / КПА
Для защиты разработчика ПО работы с телеметрией ИСУ / КПА, ускорения сроков разработки данного ПО и повышения его качества – предлагается искусственная генерация телеметрии еще физически не существующего ИСУ / КПА.
Для этого имеются базовые исходные данные: ТУ на ИСУ / КПА уже утверждено, а значит, точно известно количество и названия параметров, их длительность, верхний и нижний пределы и т. д. Остается в самом начале разработки комплекса и ПО работы с телеметрией поставить вопросы о формате файлов телеметрии и их количестве, алгоритмах расположения на диске, количестве сохраняемых параметров, частоте сохранения данных. При этом необходимо учитывать, что во время практической разработки как самих файлов, так и механизма импорта формат файлов, как и их размер, может значительно изменяться. Имея эту информацию, можно использовать ПО «Генератор телеметрии» [3] (рис. 1) для создания файлов телеметрии по уже согласованному формату.
Приведенное на рис. 1 ПО было написано самостоятельно, поскольку анализ HEX-редакторов и генераторов данных (приложение А) показал, что они не подходят для задачи создания телеметрии ИСУ / КПА. В процессе разработки появились уточнения по типам данных (приложение Б).
Концепция генерации телеметрии:
пошаговое создание блоков алгоритма, по которому будет строиться файл телеметрии;
выбор максимально возможного количества типов данных в целях унификации генератора – возможности его использования не только для ИСУ;
создание цикличности выполнения блоков – как генерации данных внутри блока, так и генерации множества блоков. Проверка корректности цикличности алгоритма перед его запуском;
добавление контрольной суммы в начале или конце файла. Не все разработчики придерживаются мнения о целесообразности внедрения контрольных сумм в файлы, как и использования Венгерской нотации [4, 5], хотя их роль в безопасности файла и удобочитаемости исходного кода значительна и включена в рабочие программы учебных дисциплин Минобрнауки [6, 7, 8, etc].
Преимущества
Генератор избавляет от ошибки человеческого фактора, когда файлы тестовой телеметрии программист составляет вручную, изготовляя отдельный исходный код для данной задачи (то есть дополнительное ПО). Если же программист сторонний, ситуация усложняется: при обнаружении ошибки возникнет спор, у кого из разработчиков она допущена – при создании телеметрии или при ее импорте. Это приводит к изнурительному анализу файлов телеметрии в HEX-редакторе, что опять добавляет возможность ошибки человеческого фактора. Необходимость использования HEX-редактора, в свою очередь, приводит к увеличению файла телеметрии. Например, приходится хранить данные «время1, значение1, ... , время1 значение67» вместо «время1, значение1, …, значение67», так как анализ последнего в содержимом файла значительно сложнее.
Сгенерированная телеметрия, в отличие от реальной телеметрии ИСУ, может содержать намеренно сильно отличающиеся друг от друга данные, что исключает ошибки смещения при импорте как по названию параметра, так и по времени. Например, параметры гиромоторов в оригинальной телеметрии ИСУ содержат практически идентичные значения тока и названия – при импорте данных они могут оказаться перепутаны, и это не видно глазу даже при визуальной отладке. Если же файлы телеметрии ИСУ создает генератор, можно задать условия, когда значения графиков будут отличаться значительно и предсказуемо, и каждый из параметров попадет именно в свою ячейку массива данных ПО просмотра / анализа телеметрии. Кроме того, намеренно искаженные данные могут использоваться для тестирования различных механизмов, вроде автоматического поиска ошибок, изменения цвета графика, пределов возможностей компонентов разработки и т. д.
Еще одним достоинством предлагаемого подхода является то, что сразу виден фактический размер выходного файла одного теста. Фактический размер может отличаться от теоретического десятикратно и выше. Например, разработчик ПО контроля ИСУ принял решение сохранять в файл телеметрии аналоговые параметры с избыточным периодом 1 мс вместо 12 мс. Использование генератора телеметрии дает время для его переубеждения, демонстрируя факт чрезмерно большого размера выходного файла, и данная ошибка не войдет в релизную версию ПО для заказчика.
Пример создания генератором
телеметрии файла, схожего
с телеметрией макетного ИСУ
Пример утвержденного разработчиком контроля ИСУ формата телеметрии, созданного по формату файла генератором телеметрии, бинарного представления файла в HEX-редакторе (рис. 2, 3, 4).
Заключение
Разработан генератор телеметрии, позволяющий ускорить разработку ПО, работающего с телеметрией ИСУ, а также улучшить качество разработки такого ПО. Данный генератор может быть применен, по аналогии, при разработке ПО самоконтроля КПА без физического наличия КПА.
Стоит сделать акцент на наполнении файлов телеметрии. Утверждение «телеметрия должна содержать только полученные данные», нацеленное на уменьшение размера файлов за счет упрощения их формата, выглядит логичным лишь поверхностно. Должны сохраняться и пределы, и триггеры выхода значения за пределы, и каждое полученное значение:
ТУ может быть изменено – пределы станут иными, программа контроля ИСУ будет изменена;
триггер ошибки значения, сохраняемый в файл программой контроля ИСУ, а не рассчитываемый в ПО просмотра / анализа телеметрии, порождает сохранность состояния ошибочности телеметрии именно в момент ее получения и независимость от последующих изменений в ТУ;
аппроксимация телеметрии на определенных ее участках должна рассматриваться как целенаправленное искажение информации: в результате могут быть упущены единичные значения параметров, вышедшие за пределы минимального или максимального значений.
ЛИТЕРАТУРА
Фридлянов М. А. Методы и приемы управления проектами в сфере промышленного производства // Проблемы рыночной экономики. 2017. № 3.
Куликов С. С. Тестирование программного обеспечения. Базовый курс / 2‑е изд. Минск: Четыре четверти, 2017. С. 81.
Белов С. П. Генератор телеметрии v.1.1.1.1. Москва: личный сайт, 2021. [Электронный ресурс] URL: https://bad-good.ru/programs.html#generator_telemetry.
Кондраков С. А., Кудинов Н. А. Алгоритмы стандартизации исходного кода // Труды МАИ. 2003. № 14.
Павловская Т. А. C / C++. Программирование на языке высокого уровня. СПб: Питер, 2003. С. 18.
Институт экономики и управления АПК. Рабочая программа дисциплины Б1.О.13 «Оперативные системы» для подготовки бакалавров. М.: МСХА, 2020. [Электронный ресурс] URL: https://www.timacad.ru/sveden/files/B1.O.13_OPERACIONNYE_SISTEMY_RPD.pdf.
Факультет компьютерных технологий и прикладной математики. Рабочая программа дисциплины Б1.В.04 «Объектно-ориентированные языки и системы программирования» для подготовки магистров. Кубань: ФГБОУ ВПО КубГУ, 2018. [Электронный ресурс] URL: https://infoneeds.kubsu.ru/infoneeds/file_export.do?fid=3687032.
Владивостокский государственный университет экономики и сервиса. Рабочая программа учебной дисциплины ОП.02 «Операционные системы» для подготовки специалистов среднего звена. Владивосток: ФГБОУ ВО ВГУЭС, 2020. [Электронный ресурс] URL: https://www.vvsu.ru/files/904E34A0-616D‑4992-AA8F‑8E3DB96AB709.pdf.
Отзывы читателей
