Пост будет лонгрид и поэтому решил попробовать формат статьи. В конце будет размещено некоторое количество ссылок.
По замечанию одного из авторов статьи, которую мы опубликовали в нашей группе, в нашем посте отсутствуют ссылки на источники, поэтому стремлюсь исправиться, а заодно существенно дополнить своё предыдущее повествование этой славной истории.
Хочу ещё раз обратить внимание подписчиков группы, что проект Малахита (по идее шёпотом шла речь о проекте Ясень-М, но утверждать не буду) был одним из первых и по сей день остаётся наиболее продвинутым с точки зрения разработки системы управления атомной подводной лодки.
Участники проекта по разному продолжили использовать SimInTech. Например, ОКБМ (один из ключевых участников проекта Малахит) перенёс свой опыт использования SimInTech для транспортных установок на свои стационарные проекты в гражданской энергетике. Совсем недавно мы опубликовали пост специалистов Калужского турбинного завода от 2012 года, которые описывают паротурбинную установку для проекта ПАТЭС, а между прочим, КТЗ тоже участник проекта Малахит. А если в эту компанию добавить ещё и концерн «Аврора», который отвечает за финальную разработку непосредственно аппаратуры и её монтаж на борту, то приблизительно можно представить себе весь масштаб цикла разработки комплексной модели и системы управления АПЛ, от формирования концептуальных требований Генерального Проектанта, до сборки и тестирования аппаратуры перед отгрузкой на борт.
В авиации вот уже который год, пытаясь подражать своим импортным коллегами, заявляют о своих планах по реализации комплексного модели летательного аппарата. Для этого приобретается большое количество импортного софта, т.к. заявлять о кроссдициплинарности, мультифизичности и т.д. это одно, а реализовать комплексную модель это чуть-чуть другое. Один из чиновников ОАКа мне сказал, что наш софт до этого ещё не дорос. Ха-ха. В SimInTech комплексная модель была собрана 10 лет назад, боль в том, что демонстрировать её вряд кто позволит. Мы можем довольствоваться лишь редкими публикациями и по ним пытаться восстановить масштаб всей выполненной работы. Поэтому я попробую здесь впервые собрать несколько ссылок на статьи, которые на мой взгляд, являются отголосками большого проекта под грифом.
Прежде чем перейти к перечню, отмечу вот что: важным преимуществом нашего решения является наличие «базы данных сигналов». Это своего рода «унифицированный язык», который позволяет каждому участнику проекта, будь то разработчик какой-то подсистемы реактора или проектировщик турбины, или производитель управляющей аппаратуры, понять о чём идёт речь. Уникальный код сигнала несёт в себе значительный объем информации, достаточный инженеру для того чтобы определить к какому оборудованию этот сигнал относится, к какой подсистеме и т.д. Этот код позволяет легко определить место возникновения этого сигнала в сколь угодно большом проекте и проследить его динамические значения и их влияние на систему в целом. Этот подход также очень позитивно оценивают разработчики аппаратуры, когда им приходится разбираться уже с кодом бортового ПО, заливающимся на контроллер.
Для создания «унифицированного языка» необходимо наличие соответствующего функционала в софте, и очень много организационной работы, когда над созданием комплексной модели трудятся несколько различных предприятий со своей культурой, со своими организационными правилами. Это я к чему? Мне кажется, что даже выполнив такой проект, это не гарантирует успеха в другом подобном проекте, в другой отрасли. Но безусловно, такой опыт и отработанный функционал в софте - огромное преимущество перед конкурентами.
Ещё одно преимущество базы данных сигналов - автоматизация работы с типовыми алгоритмами. В качестве примера можно привести «блок управления задвижкой». В подводной лодке задвижек очень-очень много. У разработчика системы управления есть большой соблазн скопировать блок управления задвижкой, ранее им (или другим инженером) разработанного и отлаженного, благо что они практически все одинаковые с точки зрения алгоритма работы. Традиционный Copy&Paste самый «продвинутый» автоматизатор и присутствует во всех САПРах. Но этот подход может принести массу хлопот, если инженер будет невнимательный, что-то забудет исправить и его копия унаследует часть значений и параметров оригинала. Чем сложнее проект, тем выше стоимость такой ошибки, её сложно найти, т.к. схема может правдоподобно работать с неверными значениями. Наша база данных сигналов исключает бездумное копирование и в тоже время, предоставляет разработчику возможность сколь угодно многократно использовать один и тот же ранее отлаженный «блок управления задвижкой» с определением новых характеристик и значений. В идеальных проектах мы доходили даже до того, что при размещении новой задвижки на схеме в базе данных сигналов автоматически формировались записи и присваивались идентификаторы в соответствии с системой кодирования принятой в отрасли.
Отдельная тема - автоматическая генерация кода для целевой аппаратуры. Не то чтобы это было нашим ноухау, конечно нет. Но традиционно моделирование объектов в исследовательских целях и разработка системы управления с последующей разработкой бортового ПО выполняется с привлечением разных программных продуктов. Например, моделирование в Matlab/Simulink, кодогенерация в ANSYS Esterel, формирование требований в ещё какой-то системе. Часто это выполняют различные организации, которым нужно договориться между собой как передавать матмодель, в каком объеме, в каком формате и т.д. И часто договориться не получается, каждый варится в своём соку.
Более же перспективным направлением для решения задач является применение современного программного обеспечения для моделирования сложных объектов с возможностью разработки и последующей отладки алгоритмов управления на них. Сквозной цикл разработки АСУТП/САУ с использованием единой среды SimInTech и автоматическая генерация кода просто рушит отдельные требования существующих стандартов, среди которых есть требование к анализу покрытия программного кода. Этот рудимент международных стандартов вполне закономерен, если бортовое ПО разрабатывается вручную, в разном ПО, без комплексного моделирования объекта, без предварительной отработки алгоритмов управления на модели. SimInTech же позволяет автоматически генерировать код для целевой системы и уровень покрытия кода будет стопроцентный, машина не создаст неиспользуемые фрагменты, это невозможно. Опять же, если требования к системе управления сформировать в SimInTech, то и автоматизировать процесс анализа покрытия требований не сложно. В этом случае, реализация реального сквозного цикла разработки позволить получить максимальный эффект от использования нашей технологии.
Подитожим: существенным преимуществами отечественной программной среды SimInTech для комплексных проектов являются наличие базы данных сигналов и автоматической генерации кода в контексте сквозного цикла разработки АСУ, где присутствует и комплексная динамическая модель объекта, и схемы алгоритмов управления связанные с требованиями, и целевая аппаратура.
Ну вот теперь можно пробежаться по публикациям.
2012-й год.
- Нучно-технический и производственный Журнал «Судостроение» №2. ОАО СПМБМ «Малахит», Статья «Внедрение сквозной технологии разработки алгоритмов управления сложными техническими системами объектов ВМФ» В.В.Замуков, И.И.Курдюков, Е.Н.Разуваев ---Статья
- ОАО «Калужский Турбинный Завод», "Известия высших учебных заведений. Машиностроение". Статья «Анализ некоторых результатов стендовых испытаний и проработка методики моделирования ПТУ ПЭБ АТЭС ММ» Сизов А.Н., Мусатов Е.А., Рогоза А.А. ---Статья
2013-й год.
- Научно-практический журнал «Биржа интеллектуальной собственности» №11. ОАО СПМБМ «Малахит», «Технологии разработки алгоритмов и регуляторов для систем управления корабельных энергетических установок.» Ю.С.Некрылова, И.И.Курдюков ---Статья
2017-й год.
- Конференция «Взгляд в будущее – 2017». АО «ОКБМ Африкантова», АО СПМБМ «Малахит». Доклад «Опыт проведения МВИ КСУ ТС с применением ММ ЯЭУ». ---Статья
- Конференция «Взгляд в будущее – 2017». АО «Концерн «НПО «Аврора». Доклад «Концепция компьютерного моделирования интегрированных автоматизированных систем управления техническими средствами.» Строкин К.О., Федоров С.В. ---Статья
- Научно-технический сборник ФГУП «НИТИ им.А.П.Александрова» - «Технология обеспечения жизненного цикла ЯЭУ» №1. «Технология проектирования и отладки программного обеспечения системы управления стендовой ЯЭУ с использованием инструментально-программных комплексов моделирования» С.В.Батраков, Е.И.Дербуков, В.А.Ефимов, Т.В.Романова, В.А.Чернего, В.П.Черных, А.А.Шаленинов. ---Статья
Вероятно это не всё, и если проявится что-то интересное, обязательно запостим.
Спасибо.