Здравствуйте,
Иосиф!
Недавно
наткнулся на
различные
ресурсы, связанные
с т.н.
автоматным
программированием
или
SWITCH-технологии
разработки и
документирования
ПО.
Например,
http://itc.ua/article.phtml?ID=19921
http://www.softcraft.ru/auto.shtml
http://is.ifmo.ru/
и т.д.
Подобные
технологии в
применении к
встроенным
системам
должны
давать
достаточно "вкусные"
результаты.
Как опытный
человек, имевший
отношение к
серьезным, в
том числе и оборонного
значения
проектам, Вы
наверняка
имеете свое
мнение по
данному
вопросу.
Очень
хотелось бы
услышать его!
С
уважением,
Алексей
Бирюков
mailto:myfido@rambler.ru
Добрый
день,
Алексей!
Я сегодня
посмотрел
ссылки,
которые Вы
мне прислали.
Вы
спрашивали
мое мнение.
Для начала я
скажу Вам,
что я не
системный
программист,
я -
аппаратчик, который
много
занимался
системами
управления.
Поэтому все
то, что я
здесь напишу,
надо
рассматривать
именно с этой
точки зрения.
Теперь
надо
определиться
с классом
задач.
1. Есть
микропроцессоры,
обрабатывающие
видео или
звук. У них
много
вычислений,
но при этом
мало состояний
в которых эта
обработка
выполняется.
2.
Микроконтроллеры,
обрабатывающие
задачи
управления.
Идеальный
представитель
- тот у
которого на
входе и
выходе есть
только цифровые
переменные.
Это релейное
управление
двигателями,
насосами, теплонагревателями.
Перевод
аналога в
цифру и
сравнение
цифры с уставкой
может
выполняться
в отдельном
контуре регулирования.
Например, в
тех системах
управления,
которые мы делали для
заправки
дело
обстояло
именно так.
Преимущество
же релейного
регулирования
в том, что при
этом
регулировании
самый
быстрый
переходный
процесс.
Недостаток - гистерезис.
При таком
подходе,
именно для управляющего
микроконтроллера,
и выгодно применять
стратегию
"воздействие-(запрос)-ответ".
Соответственно,
все
программное
ядро вырождается
в простейший
автомат.
3. Привод
для станка,
который
делает ПИД-регулирование.
Есть
вычисления,
но есть и
задачи
управления.
Если задачу
вычисления
рассматривать
как "черный
ящик", то
пункт 3 можно
привести к
пункту 2.
Теперь
далее, про
автомат
управления. Беда
такого
автомата в
том, что может
быть
реализовано
только
ограниченное
число ветвей
и переходов.
Процессор
должен быть
гораздо
быстрее, чем
период
возникновения
воздействий.
В противном
случае к КАЖДОМУ
событию надо
добавить
возможные
"прерывания
события", как
новые
состояния автомата.
И, следовательно
дополнительные
ветви, когда
процесс не был
завершен, но
уже
поступило
новое
воздействие.
Если есть
ядро-автомат.
У меня на
сайте в записках
инженера есть
фрагмент об
"алгоритме,
который не знал куда
ему идти". Это
как раз
пример того,
когда
автомат
попал в
какое-то
состояние, но
не может
отработать
"прерывание
процесса" при
запросе от
хоста, а
такое
воздействие
не было
заложено в
алгоритм. А
это именно то,
что должна
делать
многозадачная
операционка
- отработать
воздействие
с более
высоким приоритетом.
Разница,
как Вы теперь
понимаете в
том, что при
АВТОМАТНОМ
проектировании
Вы должны заложить
все мыслимые
состояния и
их комбинации!!!
А для проектировании
на базе ОС - вы
просто
подключаете
сервисы, которые
умеет
выполнять ОС.
И не надо
заботиться
об их
комбинациях.
Есть запрос
от хоста с
более
высоким
приоритетом -
он будет всегда
обслужен, и
об этом
заботиться
ОС.
Вот
теперь Вы
сами сможете
определить возможные
ограничения
и области
применения
для таких
программ.
А по
поводу
автоматизации
проектирования
- этот
процесс идет
непрерывно.
Фирмы предлагали
и будут
предлагать
новые и новые
программные
продукты.
Только надо
четко определять
для каких
областей они
пригодны.
Ведь тоже
было и с РС.
Сначала "все
на РС", потому
что это
просто. Потом
выяснилось,
что появились
Винды и
РС слегка не
успевает.
Потом, уже
при 2000 - началась
морока с "а
как бы
вывести
данные через
СОМ... и
почему при
этом
теряются
байты..."
Посмотрите
на сайте
ЛИТМО (пишу
по-старому) -
там описание
контроллеров
Сименс. Вот
для них
примерно вся
эта
технология и
придумана.
С
уважением,
Иосиф
Каршенбойм
Еще раз
здравствуйте,
Иосиф!
Это Вам Спасибо
за статьи!
За
неимением
достаточного
представления
о том как
проектируются
и
реализуются
серьезные
системы (мне 25
лет, и пока из
проектов я
успел
сделать
только по
мелочи), мне
приходится собирать
эту особо
ценную
информацию
буквально
по крупицам.
Поэтому то,
чем Вы делитесь
с Вашими
читателями,
чрезвычайно
интересно и
нужно!
--
С
уважением,
Алексей
Бирюков
mailto:myfido@rambler.ru
Здравствуйте,
Иосиф!
Огромное
спасибо Вам
за понятный и
исчерпывающий
ответ!
Теперь
для меня
проясняется
картина, когда
автор одной из
статей
пишет "как же
я мог раньше
обходиться
без автоматного
программирования",
и четко видны
разграничения
по применимости
этого
подхода. Иногда
против
рекламы
трудно
устоять ;) Конечно,
"серебрянной
пули не
существует".
Еще хочу
особенно Вас
поблагодарить
за статью
"Гайка М3 и ТЗ на
разработку"!
Прочитал
и думать о
документации
к
разработкам
стал немного
"в
другую
сторону", как
к части
проектирования,
а не как к
формальной
кипе
бумаг для
сдачи. Вот в
этом
направлении
хотелось бы
почитать и
узнать побольше!
Ну и
конечно с
огромным
удовольствием
читаю про
"Буран" и
наконец
начинаю
понимать то,
что творится
в родном НИИ
"Пульсар" и почему то
что есть
именно такое.
--
С
уважением,
Алексей
Бирюков
mailto:myfido@rambler.ru
Здравствуйте,
Алексей!
И еще хочу
добавить про
"автоматное
программирование"
(АП). Есть
класс
устройств,
называемых
Программируемые
Логические
Контроллеры
(ПЛК). Вот для
ПЛК как раз и
придумана
куча языков
программирования,
аналогичных
АП.
Дело еще в
том, что
структура
ПЛК
отличается
от
стандартных
микроконтроллеров.
Представим,
что у нас
есть
30-канальный HDLC.
На этапе
установления
соединений
надо миеть
7 таймерных
ячеек на
каждое
соединение.
Т.е.
зарезервировать
210 бит под
таймеры. Да
под сотню
байт, где
было бы прописано,
для какой
ячейки какой
интервал
нужен. И
зарядить
контроллер
прерываний от
таймера, а по
прерываниям
формировать
биты ячеек.
Что остается
от
производительности
микроконтроллера?
Это, первое.
А второе
вот в чем.
Представим,
что находимся
на каком-то
состоянии
автомата. На
вход
действуют несколько
переменных, и
выход
"завязан" тоже
на несколько
переменных.
Если
действовать
строго в духе
АП, то надо
для каждого
состояния
просчитывать
все входы и
выходы, задействованные
для данного
состояния, да
еще выключить,
скажем,
переменные
от предыдущего
состояния.
Поэтому, на
мой взгляд
проще
просчитать
поголовно
все переменные.
А таймерные
ячейки
формируются
либо при
записи как в
переменные
один раз за
цикл, либо
реже. По формулам,
как и все
остальные
выходы.
И вот
именно так в
предыдущем
моем проекте работал
битовый
сопроцессор,
выполненный
в FPGA, который
через
сдвиговый
регистр управлял
полусотней
реле на
плате. 64
записи в битовый
порт - вот
эквивалент
сдвигового
регистра. А
обработка
битов в
битовом
процессоре
делается
гораздо
быстрее, чам
в любом
другом
процессоре.
Упрощенная
версия этого
проекта
описана в
статье
"битовый
процессор".
Этот тип
процессора я
воспроизвел
по подобию
машины,
которая вела
технологический
процесс на
системах
заправки.
Программируется
такая машина
на булевой
адгебре.
Ну и когда я
сделал
софт-симулятор,
то работать
стало
довольно
просто. Да и
рисовать граф
переходов
для такой
машины не
обязательно.
Т.к. для
каждой
выходной
переменной
пишется
формула - Y = X1 & !X3 | !T ^ Z8
| Y7, те X-входы,
T-таймеры,
Z-внутренние
переменные
из ячеек
памяти,
Y-выходы.
Набор
внутренних
переменных -
это и есть
тот самый
автомат или если
говорить
точнее, его
текущее
состояние.
Время
работы - при
частоте,
например
50МГц, на 100
выходов и 200
входов, и если
в каждой
формуле по 5
членов, требуется
100 х 5 = 500
тактов. 500 х
20нсек = 10 мксек.
умножаем
примерно на 3,
чтобы эту
информацию
из буферной
памяти
разнести по
выходам, получим
30 мксек. На
самом деле
для входов и
выходов требуется
гальв.
развязка,
которая
работает на
порядок медленне.
Итог-
такой
контроллер
очень прост и
невероятно
надежен, но
годится
только для
задач управления,
в которых нет
математики
или DSP.
Опять
получилось
длинно...
Наверное
эти письма
надо
повесить на
сайт, может
это еще кому-то
будет
интересно.
Конечно, если
Вы не против!
С
уважением,
Иосиф
Каршенбойм
Здравствуйте,
Иосиф!
Конечно я
не против
публикаций,
наоборот, я абсолютно
уверен,
что Ваш
опыт будет
полезен
очень многим!
Насчет
специфического
применения
автоматного
программирования
в
основном
для ПЛК
действительно
никаких
сомнений у меня
нет.
Другое дело что
той рекламе,
которую
делают
авторы статей
по данному
методу
программирования
можно
противопоставить
только
большой опыт.
Ведь что
они пишут?
Революция!
Новый метод в
проектировании,
отладке и
документировании!
ИК> процессоре.
Упрощенная
версия этого
проекта
описана в
статье
ИК>
"битовый
процессор".
Этот тип
процессора я
воспроизвел
по подобию
ИК>
машины,
которая вела
технологический
процесс на
системах
заправки.
Интересна
такая деталь,
а как
выглядела документация
на такой
ПЛК для
заправки?
Это было
текстовое
описание или же
нечто
подобное
описанию
на
конечный
автомат в
виде
диаграмм
переходов
или таблиц
состояний?
И велся ли
лог работы
этого
контроллера?
Если да, то
как это было?
Может
быть, как
раз запись
реакций на
входные воздействия
и запись
состояний
автомата? Тогда это
1-в-1 то о чем
пишут А.А.Шалыто
и др. ;)
ИК> Программируется
такая машина
на булевой адгебре. Ну
и когда я
ИК>
сделал
софт-симулятор,
то работать
стало
довольно
просто. Да и
ИК>
рисовать
граф
переходов
для такой машины
не
обязательно.
Т.к. для
В виде
графов
интересно
мне кажется
было бы _задокументировать_
такой
автомат!
ИК>
каждой
выходной
переменной
пишется формула
- Y = X1 & !X3 | !T ^
ИК> Z8 | Y7, те
X-входы,
T-таймеры,
Z-внутренние
переменные
из ячеек
ИК>
памяти,
Y-выходы.
Набор
внутренних
переменных -
это и есть
тот
ИК> самый
автомат или
если
говорить
точнее, его
текущее
состояние.
ИК> Время
работы - при
частоте,
например
50МГц, на 100
выходов и
ИК> 200
входов, и
если в каждой
формуле по 5
членов,
требуется 100 х
ИК> 5 = 500
тактов. 500 х
20нсек = 10 мксек.
умножаем
примерно на 3,
ИК> чтобы
эту
информацию
из буферной
памяти
разнести по
выходам,
ИК>
получим 30 мксек. На
самом деле
для входов и
выходов требуется
ИК> гальв.
развязка,
которая
работает на
порядок медленне.
Ну вот,
можно сказать
что Вы
сделали _процессор_,
"заточенный"
под
работу в
виде КА! Еще
раз перечитаю
Вашу статью
про него.
ИК> Итог-
такой
контроллер
очень прост и
невероятно
надежен, но
ИК>
годится
только для
задач
управления, в
которых нет
математики
или
ИК> DSP.
Не знаю,
авторы хвалились
что умеют
математику
КА делать!
Для меня это
конечно
очень необычно
;)
--
С
уважением,
Алексей
Бирюков
mailto:myfido@rambler.ru
Здравствуйте,
Алексей!
То, как
выглядело
программирование
Устройства
Логической Обработки
Информации -
описано в
"записках
инженера", в
эпизоде о
черной Волге.
Программы
были
написаны на
булевой
алгебре и был
транслятор,
который
переводил
Х и Y в
машинные
коды. Потом
эти коды
прошивались в
ультрафиолетовое
ПЗУ.
С
уважением,
Иосиф Каршенбойм