Проект встраивается в осенний тренировочный турнир, когда в чемпионат вливаются много начинающих изучать программирование. Именно поэтому в проекте так много задач, не требующих программирования циклов. Это задачи 1, 6, 7, 9 и 10. Несмотря на такое упрощение, проект учит довольно многому.
Во-первых, задачи проекта показывают, каким образом с помощью весьма простого устройства – таймера программного управления, можно организовать достаточно сложный процесс. У таймера всего две команды: включить и выключить указанный канал в заданный момент времени. А посмотрите, как много действий удается запрограммировать:
Естественно, что для всех этих операций нужны соответствующие исполнительные устройства: двигатели, пневмозахваты, толкатели, фиксаторы, приспособление для термосварки. В проектах автоматизации обычно участвуют различные специалисты: технологи, инженеры по электроприводу и автоматизации производства, программисты. Программист отвечает за то, чтобы программы управления обеспечивали функционирование исполнительных устройств в соответствие с технологическим процессом.
Прочувствовать способность примитивных команд таймера выполнять реальную работу легче всего, решая задачу 7. Именно с этой задачи лучше всего начинать решать задачи проекта. Решив эту задачу, будет много проще понимать связь между камандами таймера и операциями автоматизируемого процесса.
Во-вторых, содержание задач учит параметризации. Параметризация в любых задачах цифрового управления является одной из самых важных работ. Зачастую от качества выполнения этой работы зависит успех всего проекта. Параметризация – это осмысление автоматизируемого процесса и выделение в нем всех значимых параметров.
В проекте "Таймер" в качестве главного параметра выступает время. Сначала это абстрактное время включения и выключения сигналов каналов таймера, а затем – конкретные моменты времени включения и выключения двигателей системы управления. Значения этих моментов времени рассчитывается в зависимости от расстояния и скорости перемещения исполнительных механизмов – толкателей, фиксатора, пневмозахватчика, разрезного ножа. Получается, что знание только уравнения равномерного движения позволяет полностью справится с программированием таймера.
В-третьих, задачи учат понимать циклограммы. Циклограмма – это универсальное средство представление процессов во времени. Универсальность можно проиллюстрировать следующими примерами:
В-четвертых, проект является простым примером реальной системы автоматизации проектирования (САПР). В большей части задач формируется спецификация циклограммы. Иначе говоря, программы участников тренировочного турнира "Осень-2018" занимаются генерацией программы для таймера – так называемой "прошивки". А это как раз есть автоматизация проектирования управляющих программ.
Можно убрать эти программы, рассчитать параметры циклограмм с помощью калькулятора или электронных таблиц, а затем загрузить полученные команды в таймер. Но тогда процесс проектирования и отладки станет слишком затратным по времени, энергии и материалам. При обнаружении ошибок и/или изменении скоростей движения исполнительных механизмов и расстояний между узлами производственной линии придется снова перепроектировать программу таймера. А про то, чтобы автоматически переносить данные из интернет-заказа в программу управления процессом, придется забыть. Только благодаря наличию программ проекта можно на основе таймера программного управления полностью автоматизировать исполнение индивидуальных заказов, формируемых на веб-сайте шоколадного ателье.
В-пятых, задачи проекта являются простым способом освоения школьниками широко распространенной в ИТ-сфере практики автоматической генерации программ. Любой современный сайт в интернет функционирует в среде браузера, который интерпретирует html-код веб-страниц в совокупности со спецификациями стилей из специальных файлов таблиц каскадных стилей (css-файлы). В то же время, значительная часть html-кода автоматически генерируется в среде этого же браузера с помощью программ на языке javascript, а на стороне сервера с помощью очень широкого спектра инструментов генерации и html-кода, и css-таблиц, и javascript-кода. Автоматическая генерация также активно используется при создании большинства современных программ, функционирующих не в среде интернет.
Во многих задачах проекта "Таймер" участники турнира занимаются автоматической генерацей кода управляющих программ, загружаемых в таймер. Именно это обстоятельство предопределяет непривычную для олимпиадного программирования ситуацию, когда в условиях задач фигурирует много выходных данных, не зависящих от входных. Представьте себе, что в учебной задаче нужно написать фрагмент кодогенератора, который порождает машинную программу реализации выражения языка Си "a = b = c = d = e = f = 5". При этом во входных данных фигурируют адреса переменных a..f, а в условии задачи приводится таблица кодировок машинных команд и методов адресации процессора семейства Intel x86 (Pentium, Celeron, Core Duo, Atom). В правильном решении этой учебной задачи в случае не использования приемов оптимизации кода будет 6 10-байтных машинных команд. И только байты 3..6, отвечающие за адрес переменной в команде, в разных командах будут различаться. Все остальное будет браться из условия задачи.
Аналогичная ситуация происходит при решении задач проекта "Таймер". Если в условии задачи 7 требуется сигналом канала 0 включить двигатель в момент 0 и выключить в момент, когда бруски начинки выдвинутся на L миллиметров от края участка разрезки, то выходная строка будет содержать текст "0 0 1 0 T 0", где T - время, вычисляемое через L и заданную скорость движения. В этой строке закодированы 2 команды: включить канал 0, выключить канал 0. И только параметр T второй из этих команд определяется входными данными.
В-шестых, задачи проекта тренируют способность разбираться в объемных описаниях автоматизируемого процесса и программировать в точном соответствии с этими описаниями. В наибольшей степени это относится к 10-й задаче. Эта задача меньше всего похожа не те задачи, что традиционно фигурируют в олимпиадном и спортивном программировании. В то же время, именно такие задачи доминируют в реальной практике автоматизации – хоть в управлении технологическими процессами, хоть в организационном управлении. Для реальной практики автоматизации характерны большое количество параметров и относительная простота функциональных зависимостей между ними. Сложность таких задач прежде всего в том, что легко что-то упустить или истолковать не так. Как говориться: "Тут все очень просто, но этого простого так много, что уже через пять минут чтения описания процесса голова оказывается переполненной".
В-седьмых, многие алгоритмы решения задач являются широко распространенными в профессиональном программировании не только цифровых систем управления. Прежде всего это относится к задачам 3-5.
В-восьмых, проект является достаточно наглядным примером осуществления широко распространенной технологии проектирования программ – Model-View-Control (MVC). Эта технология предполагает отделение представления (View) объектов на экране и в распечатках от модели обработки данных (Model) и управления этой обработкой (Control).
В проекте "Таймер" компоненты Model разрабатывают участники тренировочного турнира – именно они программируют всю требуемую обработку данных. Компоненты View предоставляются участникам в готовом виде – это изображение циклограмм, светодиодов и процессов на конфетной линии. Компонент Control также предоставляется в готовом виде – это кнопки Старт, Стоп, Шаг, Продолжить и другие элементы управления процессом. Правда эти элементы относятся не столько к средствам управления технологическим процессом, сколько с средствам автоматизации проектирования управляющих программ, т.е. САПР. В реальной практике САПР систем технологического управления содержат средства моделирования. Перечисленные выше элементы управляют моделированием, а не самим процессом. На этапе отладки автоматизированного технологического процесса эти средства могут управлять запуском отдельных технологических операций.
Только благодаря применению технологии MVC созданы условия для того, чтобы компоненты Model можно было создавать на различных языках программирования, как это делается в программистских турнирах.
В-девятых, решение задач проекта в турнире чемпионата дает наглядное представление о технологии инкрементного конструирования и инкрементной интеграции программ. Инкрементное конструирование в современном инженерном программировании предполагает создание и модульное тестирование отдельных компонентов создаваемого программного обеспечения (ПО). Решение каждой задачи проекта "Таймер" является компонентом, который "прирастает" к создаваемому ПО, что как раз и объясняет, почему конструирование инкрементное. Решение задачи участника турнира подвергается модульному тестированию в контестере. Вердикты проверяющих машин относятся только к решениям отдельных задач, а не в целом к проекту. Инкрементная интеграция осуществляется на веб-странице проекта "Таймер". В реальной практике каждый шаг интеграции добавляет функциональность включаемого в ПО компонента. В проекте "Таймер" в целях обучения сделано так, что функциональность, которая не реализована участником турнира, воспроизводится авторскими решениями команды ULIVT.
В-десятых, сам факт решения задач проекта переводит того, кто это сделал, в более высокую лигу. Вокруг нас много людей, говорящих про цифровую экономику и автоматизацию процессов с надеждой на светлое будущее. И вот среди этих людей появляется школьник, который умеет решать практические и зачастую прозаические для него задачи автоматизации. Для окружающих его мечтателей такой школьник становится реальным творцом этого самого светлого будущего.
Автоматизируемый процесс строился с таким расчетом, чтобы задачи оказались под силу школьникам. В этой связи он существенно упрощен, хотя стиль технического описания в постановках задач сохранен. В реальной практике программистам выдаются многие десятки страниц описаний технологического процесса и оборудования его автоматизации. Постановки задач они вынуждены разрабатывать сами.
В задачах проекта многие параметры представлены константами, не фигурирующими во входных данных. Это номера каналов таймера, некоторые задержки времени и размеры. В реальной практике такие параметры находятся в различных файлах спецификаций и базах данных.
Некоторые размерные параметры для упрощения сознательно исключены из условий задач. Очевидно, что расстояние между направляющими перемещения начинки не может равняться ширине бруска начинки. Брусок просто заклинит при движении. В реальной практике брусок должен быть хотя бы на 1 мм уже расстояния между направляющими. Очевидно, что толщину картона так же необходимо учитывать в расчетах размеров, расстояний и времени движения.
Технологичность некоторых операций для профессионального технолога может показаться весьма сомнительной. Понятно, как сделать специальную геометрию края камеры охлаждения, чтобы при задвижения коробки неотогнутый край коробки загнулся. Кроме специальной геометрии нужна также надсечка по месту изгиба. Однако для обеспечения устойчивости этой конструкции в условиях интенсивной эксплуатации придется потрудиться или даже изобрести иной способ загрузки конфет в коробку. Процесс загибания двух крайних полосок и термосварки физически осуществить еще сложнее. Там ведь нужно как-то предотвратить "замин" полосок и расплавление конфет. Да и существующие системы термосварки не впишутся ни в размеры, ни в ситуацию загруженных в коробку конфет. Здесь пришлось сформулировать задачу для программистов раньше, чем разработан эффективный процесс. Так, кстати, бывает достаточно часто. Многие операции неавтоматизированных технологических процессов подвергаются существенному изменению с целью улучшения условияй для автоматизации.
В проектах, где программные модули реализуют отдельные относительно несложные функции, принято разделять обработку данных и формирование сообщений о результатах этой обработки. В постановке задачи "Код доступа" результат формируется в виде трехбитного двоичного кода, значение которого интерпретируется средствами индикации с использованием аварийного светодиода. Если вдруг заказчик попросит вместо светодиода изобразить звуковые сигналы, то сама программа анализа кода доступа никак не изменится. Изменится только обработчик трехбитного кода, вырабатываемого этой программой.
В каждой выходной строке этой задачи фигурирует пара команд: Канал, МоментВключения, 1; Канал, МоментВыключения, 0. На первый взгляд представление пары команд в строке выкажется избыточным. Много проще задать управление включением и выключением всего тремя числами: Канал, МоментВключения, МоментВыключения. Однако отделение команд включения от команд выключения имеет простое объяснение. Множество команд таймера непосредственно перед прошивкой упорядочивается в порядке возрастания времени. Благодаря этому в самом таймере будет список из команд вида (Канал, Время, Код операции). Главная управляющая программа таймера в каждый такт своей работы проверяет, достигло ли текущее время того времени, которое фигурирует в очередной невыполненной команде. Если текущее время достигло или превзошло, то очередная команда выполняется, а указатель на очередную невыполненную команду перемещается к следующему элементу упорядоченного списка команд. Столь простой процесс позволяет организовать параллельность выполнения технологических операций, управляемых таймером, благодаря независимости команды выключения от команды включения. В выходных строках задачи 2 команды включения и выключения приводятся парами для упрощения восприятия программы таймера. Представьте себе, если бы в выходных данных команды с параллельными технологичесими операциями, как в задачах 4 и 5, были бы упорядочены по возрастанию времени. Обнаружить ошибку в задании моментов времени включения и выключения в такой программе таймера было бы очень сложно. Пришлось бы для каждой команды включения искать парную ей команду выключения. Если один и тот же канал в одной программе несколько раз включается и выключается, то поиск ошибок становится еще более сложным.
В задаче 3 осваивается техника интерпретации управляющих программ таймера. Команды таймера фигурируют во входных данных. При этом они уже объеденены в пары: включение и выключение. Это существеннно упрощает процесс трассировки и протоколирования. На практике такого может не быть, поскольку события включения и выключения в одном канале часто связаны с аналогичными событиями в других каналах. Например: "Через 1 секунду после начала подъема груза должна быть выключена блокировка заслонки", "Спустя 2 секунды после фиксации контейнера в точке загрузки должен быть открыт клапан ...". Разработчик управляющей программы часто группирует команды с учетом именно таких зависимостей. Ясно, что интерпретация команд, не сгрупированных в пары "Включить-Выключить", в процессах трассировки и протоколирования потребовала бы либо предварительной группировки, либо поиска в массиве команд для каждой команды включения парной ей команды выключения.
Первое отличие связано с тем, что спецификация циклограммы на входе программы представлена не в формате команд таймера, а в уплотненном формате "Канал, МоментВключения, МоментВыключения, МощностьВключаемойНагрузки". В реальной практике задача мониторинга скорее всего решалась бы над кодом управляющей программы. При этом пришлось бы сначала запрограммировать формирование массива данных уплотненного формата и только после этого строить цикл обхода.
Для решения этой задачи полезно запрограммировать базовые манипуляции со структурой данных, называемой кольцом. Обход массива данных в кольце на языке Си выглядит так: if(++i == length) i = 0;. Здесь length представляет собой размер кольца. Для length = 3 такой обход порождает следующую последовательность значений индекса i: 0, 1, 2, 0, 1, 2, ... . Если в кольцо постоянно записывать по индексу i новое значение мощности в такте мониторинга T, то каждый раз самое старое значение будет заменено самым новым. В результате совокупность мощностей, представленных в массиве, всегда будет той, что должна быть видимой через скользящее окно.
Выходная строка в задаче 7 содержит текст "0 0 1 0 T 0", где T – время, вычисляемое через расстояние перемещения и заданную скорость движения. В этой строке закодированы 2 команды. Первая команда включает сигнала канала 0 в момент 0, как требует условие задачи, а вторая – выключает этот канал.
В седьмой задаче есть еще одна особенность – в ее условии перечисляется назначение трех каналов, а используется всего один. Это в очень небольшой мере воспроизводит ситуацию со спецификациями задач в реальных проектах. В таких спецификациях обычно достаточно подробно описывается процесс и технические устройства его автоматизации. Из этого общего описания разработчики каждой программы управления выделяют только значимые для нее параметры и функциональные зависимости. Способность выделять такие части общего описания является важной составляющей умения разрабатывать цифровые системы управления.
Самым противным при решении 10-й задачи является совершение ошибки в первых командах. Если обнаружена ошибка, например, во второй паре команд (это опускание заготовки коробки на стол упаковки), то придется пересчитывать времена во всех остальных командах. Чтобы защититься от такой ситуации, целесообразно написать генератор управляющей программы таким образом, чтобы между строками генерации команд таймера было приращение текущего времени. Например так (показано для тех, кто еще не освоил структуры/записи, но знает массивы; хотя можно обойтись и без массивов, сразу отправляя генерируемые команды таймера на выход):
t = t + dt; // продвижение текущего времени
dt = выражение с расстоянием и скоростью; // расчет длины i-й полоски циклограммы
ontime[i] = t; // момент включения
offtime[i] = t + dt; // момент выключения
Если после выключения в (i-1)-й паре команд таймера требуется какая-то пауза P до следующей команды включения, то в рамках приведенного решения это чуть модифицирует первое выражение: t = t + dt + P. Попробуйте подставить значения входных данных из первого теста 10-й задачи в программу с приращением времени и сверить результат с выходными данными. Наверняка вы почуствуете, как увеличилась взаимная независимость фрагментов когда, генерирующих различные команды таймера.