Там главный косяк в том, что они сравнивают текст и картинку и измеряют время нужно для считывания информации глазами. И решают что более понятно, схема или текст.
Но это абсолютно бессмысленное занятие! Никто сейча FBD диаграммы как картинку нигде не использует FBD диаграмма это средство для проигрывания моделей, а в процессе проигрывания FBD диаграмм уже отображает результа вычислений непосредственно на схеме, и пользователь оценивает динамический по времени процесс, чего ни текст ни картинка статическая не содержат в принципе.
90% времени пользователь FBD диаграммы в SimInTech, Simulink, Esterl смотрит на процесс моделируования в диаграмме. А не на статическую картинку, как у английских ученых эксперементе прошлого века.
Если что и доказывает это статья, так только то что уважаемый @mosk_onне разу с реально сложными системами дела не имел, чистый теоретик. И его представления о реальности это модель шарового коня в вакууме, из анекдота про теоретиков.
SimInTech это среда динамического моделирования технических систем
Убеждаюсь, что вы просто не понимаете, о чем я говорю.
Согласен понять это сложно, я бы сказал даже невозможно. Когда в одном предложение, у вы говорите что алогоритм включается при отказе, (явное событие в нотации Sate Mashine) и утверждаете что отказ никак не обрабатывается. Тут проблемы с обычной логикой.
Убеждаюсь, что вы похоже вы сами не понимаете о чем говорите, просто набор букв сложенных в буквы, но смысла в них нет никакого. Вы просто не можете понятно объяснить, что вы спрашиваете. Как правило, это происходит когда человек сам толком не понимает что он срашивает и о чем говорит.
у вас, да, ваши алгоритмы управления примитивны, зажечь лампочку и пыжится... :) и ждать команд от оператора.
Примитивыны ваши представления о жизни. 3000 МВт тепловых в реакторе, с уцепной реакцией деления, с контрами охлаждения, регулирования, и управления 1000 МВТ электрических. Циркуляция первого контура что бы отвевести 3000 мегават тепловых, паргненраторы что бы тепло это тепло превартить в пар. Турбина где это тепло прверащается в обороты генератора и электросеть. И все это управляется примитивыными алгоритмами, которые зажигают лампочеку и ждук команды оператора, что бы он в ручную кажду из тысячи одновремнно работающих задвижке приведел в нужное положение.
Если для вас алгоритмы управления ядреным реактором, турбиной в составе АЭС, ядерной паротурбинной устанвокой ледокола, там где работает SimInTech примитивные, то ли бо вы занимаете космической баллистикой для расчета таректорий межзведных траекторий, либо вы просто зведун-теоретик, либо одно из двух.
В графических языках уровень вхождения ниже за счет метафоризации. Но чуть влево-вправо начинаются метафорические артефакты. Вы бы почитали что-нибудь по теме.
Я же уже почитал окаменелое говно динозавров которое вы тут вытащили. И уже объяснил почему английский ученые сравнивают жопу с пальцем. FBD диаграмма в SimInTech не является картинкой, на которую нужно тупить, как в эксперементах английский ученых из вашей статьи. FBD диаграммы в SimInTech это исполняемые модели, которые используюте при отладке комплексных моделей сложных тезнических объектов, и программы управления это только части общего объекта. И для того что бы сравнивать текст программы с FBD программы SimInTech вы сначала попробуйте в тексте описать модель с 220 объектами у которых есть по 9 состояний только отказова. Я вам это показал за 3 минуты. Вы в ответ опять что то невразмутельное мычите. И еще предлагете мне читать это дерьмо. Спасибо кушайте сами. Я вам лучше про примитивную систему управления видео покажу.
Одни читают окаменелое достижение английский ученых столетней давности, другие делают ледоклы.
И на вопрос об обработке ошибок алгоритмом управления пытаетесь показать имитацию отказов в модели объекта управления. Вы похоже, даже вопрос не понимаете. :)))
Похоже это вы не догоняете, что модель объекта управления показаная в видео, представляет собой самый настоящий набор алгоритмов созданный в виде FBD диаграмм. Вы реальное не понимаете, что схемы это не реальный трубы, моторы, задвижки? Не догоняете? Открою вам тайну это просто алгоритмы!Еще раз крупно на видео показаны АЛГОРИТМЫ :)))))
Сложность этих алгоритмов на один или два порядка превышает сложность алгоритмов систем управления, в модели видно, что вычислительная нагрузка от модели турбины (каторая тоже просто алгоритм) в 10 раз больше чем нагрузка от алгоритмов защиты.
Нагрузка процессаора от разных частей модели
И то что я показал в видео, это есть комплексаня обработка отказов, в виде перключения состояний в различных частях модели.
регулятор пыжится что-то сделать -- это глупо, у вас отказ никак не отрабатывается
У вас как в голове с приченно - следсвенныем связями? Регулятор начал работу, при возникновени отказа. Это повашему "отказ никак не отрабатвается"? Вы серьезно? Или это рлоф такой, который я не догоняю? Алгоритм включился при отказе. Событие произошо! Состояние изменилось! В этом примере, регулятор это просто еще один алгоритм который обрататывает отказ, и меняет свое состояние. Это очевидная, даже ребенку демонстрация переключения состояний алгоритмов при возникновении отказа. Это наглядный пример обработки отказа, в программе написаной на языке FBD диаграмм. В дата-флоу подходе. Все как вы просили
Расскажите-ка лучше, как вы отказы отрабатываете со своим дата-флоу подходом.
Если вы хотите конккртено обсудить защиты турбины, вот вам пример алогоритма на языке DataFlow. Но смысла обсуждать его я не вижу, тут нужны турбинисты, а не как не специалисты по автоматам Мили Мала и прочих Хоров.
Пример алгоритма защиты
И да, еще в 90е годы прошлого века было экспериментально показано, что графические дата-флоу языки, типа Simintech, проигрывают по читаемости текстовым.
Если вы опять пытаетесь протолкнуть окаменело дерьм динозавров от английских ученых, так я уже прочитал статью и вижу что это просто наукообразная бессмыслица, где сранвиается текст программы с диаграммой. И показано что прочитать можно быстрее текст. Это и без английских ученых ясно. И написать программу так же быстрее чем нарисовать диаграмму. Это и без английских ученых ясно. Но это вообще мимо темы. Поскольку никто диаграмму статично никогда не смотрит. Диаграмма FBD в SimInTech это живая модель которую можно исполнять и видять процесс исполнения на схеме. И в этом случает диаграмма дает информацию которую в тексет просто нельяз прочитать, ее там нет по определению. Поэтому SimInTech рулит.
То есть показать у вас нечего? Чистая теория из статей англиский ученых 50 летней давности. Ладно объясню теоретику, что ему только что показали.
Так где обработка-то ошибок? Вы их имитируете на уровне модели. Вещь банальная. А где обработка этих отказов в управляющей программе? :)
А ничего, что все что вы видете на экране это и есть программа? Может вам очки поменять? В видео демонстрация работы программы, SimInTech она называется. Вся программа созданана языком FBD и принципиальных схем, + скрипты SimInTech. Там нет ничего, кроме управляющией прогнраммы SimInTech. По вашим утвержедениям получается обработать отказы без автоматов мура милия и какого другого хера.
Я слышал про людей которые смотрят в книгу и видят фигу. Но фига в видео, это новое.
Расскажите-ка лучше, как вы отказы отрабатываете со своим дата-флоу подходом.
Я же вам именно это только что это и показал. Я на ваших глазах в программе перевел объект в состояние отказа нажатием кнопки. У меня в программе на ваших глаза изменилось состояние объекта.
1) В дилоговом окне изменилась индикация, начала моргать иконка.
2) На схеме гидравлической растет гидросопротивление, умееншается расход, расете перепад давления индикация закртытя.
3) В схеме локальной управляющией программы автоматики подключилась модель двигателя, отключились команды управления.
4) В схеме общих алгоритмов управления, включился в работу регулятор для компенсации снижения расхода.
И все это произошло на ваших глазах в управляющей программе SimInTech,
И я могу в этой модели обработать около 2000 таких отказов, только для одного типа оборудования, а там еще и насосы, клапана, датчики и у каждого до десятка вида отказов. И почему то у меня они все прекрасно обрабатываются в с нашим DataFlow подходом, без милей мулов и прочих херов. Хотя автоматы у нас тоже есть.
Ваша очередь, покажите что нибуть тольковое уже, интересно же.
Так что, пока "интеллектуальный анонизьм" демонстрируете вы со своей агрессивной рекламой Симинтека.
Просто в отличие от теориетиков у нас есть что демонстрировать - SimInTech почувствуй нашу 25 сантиметровость!
Конечно есть и не только сказать, но и покажем, раскажем и дадим попробовать:
Пожалуйста вот вам пример стратегии обработки отказов на простой демонстрационной модели.
Покажите что нибудь подобное в автоматах миля или мура. Мне кажется, могу ошибаться. Теория конечных автоматов это интеллектуальный анонизьм не имеющий никакого практического применения. В практике используют простейшие реализации. Кде то у меня был текст от Esterl, где они объясняли, что все эти навороченые автоматы нихрена не годятся для реальных систем.
Возможно только если у Боинга, но они поэтому вернутся не могут, стратегия отработки отказов Мили с Муром как то не сработало.
Расскажите-ка лучше, как вы отказы отрабатываете со своим дата-флоу подходом.
Да легко, отказы это вобще часть любой модели АЭС. Мы эти занимаемся постоянно, с самого рождения лет та 30 наверное.
Во первых конечные автоматы уже давно существуют как отделная библиотека блоков. Бери пользуйся на здоровье лет 5 уже как.
Экстремальный регулятор солнечной панели на конченых автоматах.
Во вторых, примеры автоматов для тестов любой грамотный программист на блоках логики собирает за 3 секунды. Причем с абсолютно любой логикой. Вот кусок боевой программы тестирования из авиации, из обычных FBD блоков с помощю тригеров собирается вполне себе конечно автоматная программа, готовя к генерации в борт на Си. Из дата флов лекго и непренужденно переходим в state machin. И обратно.
Автомат тестирования в FBD диаграмме
Пакетная оргнаизация в модели позволяет подключить и отклюичить любую тестирующую логику и делать там вообще все что душа пожелает, не меняя общую модель системы и модель алгоритмов управления.
Это тот Боинг, у которого сейчас Старлайнер завис у МКС? Хорошие у вас ориентиры для подражания... :)))
Боинг, это как раз ваш пример, там все просто отлично и формальной верификацией и с соблюдением стандартов, которые американцы всей авиации и навязывали. И на любой чих у Боинга, есть бумажка в строгом соотвесвии и верификацией и валиацией и прочей байдой. А все наша авиационная отрасль на эти стандарты надрачивала и нас с SimInTech посылала в Боинге внедрится сначала. Потом что Боинг на Matlab Simulink и Simieпs Amesim работает, это лучшие стандарты в мировом Авиастроении.
Если сможете требование формально записать. А потом преобразовать его, скажем, в верифицирующий автомат, если динамически верифицировать планируете... или в ltl, если статически верифицировать умеете.
В какой автомат? Время открытия зависти от давления в гидро-аккумуляторе и никак без модели процесса это требования верифицировать невозможно. Только запустив процесс в модели, можно убедится что во всех возможных режимах просадка давления в аккумуляторе обеспечивает нужный перепад давления для максимального времени открытия. И можно что угодно делать, но верифицировать это требование к алгоритмам без модели гидросистемы невозможно. Никакая темпоральная логика тут не поможет от слова совсем. Потому что алгоритмы здесь только часть гидравлической системы.
Старлайнер с орбиты снимите сначала...
В Боинге все хорошо и с формальной верификацией и автоматы верифицирующие и ltl.
Только SimInTech у них нет. Вот и сидят астронавты кукуют.
Так не мы работае так все работают Боинг не даст соврать.
Есть. Если вы не можете формально верифицировать свойства, так и скажите. Если не можете формально задать требования, то тоже не надо фантазировать и наводить тень на плетень.
Ну и как формально верифицировать требования например такое: "Время открытия задвижки должно составлять не более 5 сек". Если само время открытия завист от давления в гидроаккомуляторе, которе так же управленияетя этим же кодом?
Требования к коду управляющих систем, для сложных технических объектов являются частью требований к процессами, и отдельно от процесса достаточно бессмысленно рассматривать, а все стандарты заточены именно на это. Есть вектор входа давайте сравним его с вектором выхода и будет нам счастье. Не будет.
ну, и смотрите, кто ж запретит... или не смотрите... :) вам-то понятно, по барабану, если в результате ошибки возникнет авария на атомной станций... у вас фига в кармане, куча людей погибнет, а в тюрьму пойдет технолог, которого "код вообще не парит". Молодцы! Хорошо устроились.
Как раз у нас с SimInTech проверка более правильная и боле строгая, чем формальная проверка, связанная с инженерией требований. Поскольку формальные требования, всегда не полные, просто по опредлению и Чернобыль это легко доказал. Верификация описанная в стандартах, устаревших еще на стадии написания, совсем не панацея. Именно у нас технологи, которые боятся аварии и понимают куда нужно смотреть при моделирования процессов, что бы свести ее вероятность к минимум и повышают безопасность объектов за счет модели объекта SimInTech. И начали это делать когда было реально страшно менять аналоговую систему управления на цифровую на РБМК. Причем делали это как раз те кто в ликвидации участвовал аварии участвовал и косяки традиционной формальной верификации кода на себе ощущали.
И потом вот такие слайды для нас рисовали, когда модель в SimInTech совпадала с реальной АЭС.
Срванения модели и процессора на РБМК-1000
Верификация -- это формальный процесс, связанный с инженерией требований. У вас ни требований, ни верификации... Виртуальный объект управления -- это хорошо. Но не вы это придумали, и не вы единственные это используете.
Проблема в том, что в формальном процессе нет модели объекта, просто нет. И стнадартов требований к модели тоже нет. На входе требования ТЗ (которые всегда не полные по определению). На выходе формльная проверка кода на соответствие. В итоге на объекте при пуске ставят кучу промежуточных уставок, дополнительных ограничений и отлаживают долго и мучительно, потому, что если в требованиях ошибка и давление 15 атм, не обеспечит нужную скорость срабатывания, будет больно и неприятно. Отсюда длительные пуско-наладочные работы.
В SimInTech появляется модель объекта, на которой верфицируют требования. Модель позволяет проверить требования, на их физическую выполнимость (когда 5 страница требований противоречит 105 странице, поскольку физически невозможно их реализовать) и полноту самих требований. Когда в требованиях указано время закрытия задвижки, а модель позволяет получить требуемое давления в гидросистеме. И уже эта модель используется для верификации алгоритмов управления. В итоге общее качество системы управления повышается, и технологи спит более спокойно после пуска объекта.
Но если подойти формально, мы должные еще доказать, что давление рассчитанное моделью соовтесвует заданному времени открытия, и тут мы заходим на новый цикл верификации уже математической модели. Для атестованых кодов и запроетных аварий проблема снимается атестацией кода в атоме, в паспорте пишут код, и оргнаизацию котаря это код может использовать для заданных параметров устанвоки. А у технолога работающая АЭС с реактором РБМК он атестацию не проходил, да и модель на атестацию не сдавал. И два варианта, писать по дествующим стандартам, и писаться ночью при пуске, либо взять SimInTech создать модель на ней проверить алгоримты и сгенерировать код. Ну а проверяющим можно сказать что писал руками по текстовым требованиям.
Сравнение в статье кривое, сравнивать нужно не кратинку с текстом, динамическую модель в SimInTech с текстом в дебагере. И в качестве тестового языка брали LabView в нем создается программа, которую можно записать текстом короче и понятней. Диграмму FBD собирать сложнее и дольше. Выигрыш начинается с момента отладки. Как только система становится сложной для отладки, и проверки, вот тут собака и порылась.
Вот например я уже тут это видео выкладывал, расскажите как вы это текстом изобразите?
Тут фишка не в повышении качества кода как такового. В SimInTech фишка, в том что мы верифицируем код уже с моделью объекта. Грубо говоря нас и продвинутых атомщиков код, как код вообще не интересует. Ну вот вообще. Нам наплевать на верификацию типа подали вход - проверили выход. В SimInTech мы провреяем комплекс модель + код, и смотрим на температуры, давления, обороты и наладчик на АЭС не рассматривают код, их код вообще не парит, они заливают его в стойки и подключнаю к модели и смотрят на работу в комплексе. Так же налаживают систему управлени АПЛ и ледоколов.
Не в одном стандарте до сих пор нет модели объекта при верификации кода.
Наприме те же Матлаб в своих документах пишет вектор входных воздействий (а откуда он берется, их вообще не ипет) Если говорить про АЭС где нет проблем с размером массой и электричество датчиков можно лепить миллионами и вектор входных воздействий для верификации собрать для класической процедуры верификации вообще не возможно, даже теоретически. Поэтому все с умным видом смотрят в книгу стандатов и держат фигу в кармане.
«При повышении давления выше предельного значения время закрытия (открытия) предохранительного клапана должно составлять не более 5 секунд.»
И как проверить это требования, если время закрытия зависти от давления в гидрсистеме, которое само является предметом регулирования системой управления?
Главное периумущестов графического языка, для сложных и критических в плане безопасности систем, в том что, им могут пользоватся технологи. А значит из цикла разработки исчезает программист, который выучил Си но ничего не понимает в технологических процессах, для которых он програмирует.
для этого нужно комерческий дойти, условно если SimInTech заработает пару миллиардов, можно будет записать язк SimInTech как стандарт в системах безопасности. Но у нас все специалисты сейчас деалют реальные проекты
У меня сейчас сложилось впечатление, что у нас стандартами занимаются, те у кого мозгово или трудолюбие не хватает на реальную работу. Инженеров грамотных реально нигде не хватает. Мы занимаемся моделированием от косома до акеанских глубин, примерно везде видим систуации, людей просто нет. Поэтому любой грамотный специалист разрывается на реальных работах. Стандартами заниматся некогда от слова совсем, поэтому на выходе шлак. А стандрат цифровых двойников? Когда в самом определении логическая нестыковка. "Цифровой двойник это математическя модель связнаная информационно с объектом, если объек есть." Понятно цифровой двойник натягивали на модели на стадии проектирования. Потому что кому то понравилось западаное "Цифровые двойники", а мозгов и знания английского не хватило понять что двойник требует первака, иначет это не двойник а просто математическая модель.
В CCCР по многим отзывам был неофеодальный порядок и каждой министерство было "вещь в себе", мало контактируя с другими почти реализуя внутри себя идеал натурального хозяйства :-)
Это не в СССР это везде и всегда. Наример у нас был заказчик в котором один отдел занимался разработкой софта для алгоритмов управления узлов вычислеительной сети, другой разрабатывал пртокол обмен данными. Они сидели в одном здания на разных этажах. И не общались друг с другом, только на испытаниях начинали лить бочки говна друг на друга. Мы как суб подрядчики ходили от алгоримистов к сетивикам что бы узнать, как их ипучий протокол реально работает и какике версии сетевой системы друг с другом совместимы.
Другая смешная история, когда нам сдали результаты эксперимента, мы делали модель и там явно было нарушение сохранения массы. И никто не мог ответить почему. Пока мы сами не приехали к закзачику взяли за руку проектировщика станда и повели в кабинет через стенку, где сидел эксперементатор, и он нам честно сказал, что в этом момент что бы точка росы не возникла, он просто добавляет теплого воздуха, открывая клапан, без измерений, просто на глаз. И пока мы не начали делать модель, никто об это и не знал.
Это истории без всякого СССР уже в наше время. Можно сказать что это русские рабы по натуре.
Но вот вам история с читыми французами, когда мы продаем Аэнергопроекту софт, как партнеры фарнцузско вендора. Там внутри война между прямым каналом, и продажами через посредников. В итоге увеличивают стоимость контракта, и на разницу продают кучу ненужного дерьма, постокльку один отдел, не отдал другому данные о реальной потребности заказчика. Это европейская фирма, и крупнейший заказчик, но феодальные войны внутри европейской компании. Нормально.
То, что смоленский оператор, с его слов, если не хвастался, знал больше про регламент, чем официально было написано и известно ЧАЭС - таки символизирует.
Это не оператор, это начальник цеха наладки, всем было известно примерно одинаково, как оказалось не очень
...потому что я думаю по факту так и было. Был регламент, эквивалентный итальянской забастовке, за реальное выполнение которого можно было бы вылететь с волчьим билетом. И был массив "понятий", когда академики на бегу сквозь зубы поясняли, что на самом деле надо понимать вместо написанного в регламенте. И вот думаю, у "своих ребят" из МинСредМаша доступ к этой ноосфере был намного лучше, чем у нежелательных чужаков из МинЭнерго...
Я про это и гворю, и академики забивали на регламент, отправили письмо, и забили. И оперативнки забивали на письма и регламент. Все грамотные специалисты. Никаких "своих ребят" вообще нет, раздолбаи все. Не надо приплетать тайную ложу, туда где все объясняется явной лажой.
Но там в письме как раз ограничение на вывод стрежней. Но кто же на АЭС будет письма конструктора читать. Операторы сами умные, операторы после йодной ямы все стрежни веерх отправили. У них реактор не останавливался, он же нейтроны давала и тепло, занчит не останавливался.
цитат из письма.
Моя точка зрения виноваты одинаково и акдемики и операторы.
акдемики могли бы ограничеие в систему управления ввести, что бы не дать операторам вытаскивать все стержни.
С другой стороны, что мешало бы оператором и это ограничение откличить как САОР?
Угу, если бы они еще документ процитировали, конкретный, кого и как предупрежали. Потому что вообще о таких вещах полагается под роспись предупреждать.
Не остался в стороне и научный руководитель, он в отличие от гл. конструктора выразил серьёзное беспокойство по поводу обнаруженного эффекта, вот что писал Курчатника:
- " при снижении мощности реактора до 50% (например, при отключении одной турбины) запас реактивности уменьшается за счет отравления и возникают перекосы высотного поля до Kz <= 1,9. Срабатывание A3 в этом случае может привести к выделению положительной реактивности. Видимо, более тщательный анализ позволит выявить и другие опасные ситуации".
Это цитата из письма, написанного своему руководству (в МинСредмаш). Были в нем и конкретные предложения по предотвращению возможной катастрофы:
— доработать конструкцию стержней РР и A3 реакторов РБМК с тем, чтобы исключить столб воды под вытеснителем при взведенном стержне;
— провести тщательный анализ переходных и аварийных режимов реакторов РБМК с учетом реальных градуировочных характеристик существующих стержней СУЗ;
— до проведения указанных мероприятий ввести в регламенты реакторов РБМК дополнение, ограничивающее число стержней, полностью извлеченных из реактора.
В Игналине академики показали, что прекрасно знали ЧТО КОНКРЕТНО надо сделать со стержнями, чтобы предотвратить взрыв. И - запретили это делать другим АЭС, чтобы правительство не пронюхало, как всё на тоненького.
Ну это уже точно сказки про рептилоидов. Правительство могло пронюхать, потому что на какой-то АЭС слесаря при помощи напильников и какой то матери, перпиливают какитео стрежни. Правительству СССР не чем занятся было? Да в правительстве специалистов, что бы просто понять, что такое СУЗ ровно один министр Славский. Всем было абсолютно пофиг, что там слесаря пилят напильниками на этих АЭС. В то время кртические сборки и реакторы по университетам стояли.
А НИКИЭТ кому то запрещает переделывать СУЗ на работающей АЭС, что бы кто-то не догадался. Извините это скорее фантазии. Что бы подписать бумагу у НИКИЭТ надо было приехать с бутылкой коньяку и там бы разрешили, все что угодно, особенно если бы занли что может долбануть, а перепил СУЗов поможет. Но не знали.
У меня еще и кафедра Э7 Бауманки, она вообще Доллежалем основана и НИКИЭТом практически управлялась всю жизнь. Историю про стрежни, который просили переделать умницы с Чернобыля, там бы точно рассказали.
Именно, а грамотных людей не хватает на текущих стройках и разработках, поэтому ргеламенты и отстают. Если лет 10 - 15 темры строек сохранятся, то возможно опытные разработчики пойдут в эксперты писать регламенты. Но пока там сильный дефицит.
Т.е. безопасность достигается забиванием на регламенты, а не их заменой? Вы правда в атомке работаете?
Дак любой регламент, это посмертный документ который от жизни отсал в момент написания. И те кто реально пишут программы для АЭС, они давно по технологиями обогнали регламенты. Например язык FIL который для РБМК изобрели в НИКИЭТ, более безопасный, но он не регламентами, не стандартами не предусмотрен. Я не заню официально но воообще зарегестировани? Но система безопасности РБМК не нем работает, нарушили регламент. Для того что бы регламент изменить надо лет 5.
Я не в атомке, поэтому могу говорить, правду. Я рядом с атомкой. И могу говорить то, про что атомщики, не расскажут. Я же привел пример, когда 2 два блока уже управлялись кодом генерированным из SimInTech, а на просьбу сделать справку для военных, разрабы говорили:
- На это я пойти не могу! Нет SimInTech в регламентах, не имеем право мы его использовать, мы все руками писали если, нас спросят.
Однажды на совещения в министерсве обороны, где мы первый раз толкали SimInTech военным, атомщик встал и сказал про меня буквально следующее:
Мы конечно для АПЛ SimInTech внедрили, но опять не через регламенты, а снизу через инженеров, которым реально нужен результат, не следование регламентам написанным в 50-го прошлого столетия.
Вот эта сатья английских ученых от 92 года.
https://disk.yandex.ru/i/p1VxY1SplaCfEA
Там главный косяк в том, что они сравнивают текст и картинку и измеряют время нужно для считывания информации глазами. И решают что более понятно, схема или текст.
Но это абсолютно бессмысленное занятие! Никто сейча FBD диаграммы как картинку нигде не использует FBD диаграмма это средство для проигрывания моделей, а в процессе проигрывания FBD диаграмм уже отображает результа вычислений непосредственно на схеме, и пользователь оценивает динамический по времени процесс, чего ни текст ни картинка статическая не содержат в принципе.
90% времени пользователь FBD диаграммы в SimInTech, Simulink, Esterl смотрит на процесс моделируования в диаграмме. А не на статическую картинку, как у английских ученых эксперементе прошлого века.
Если что и доказывает это статья, так только то что уважаемый @mosk_onне разу с реально сложными системами дела не имел, чистый теоретик. И его представления о реальности это модель шарового коня в вакууме, из анекдота про теоретиков.
SimInTech это среда динамического моделирования технических систем
Согласен понять это сложно, я бы сказал даже невозможно. Когда в одном предложение, у вы говорите что алогоритм включается при отказе, (явное событие в нотации Sate Mashine) и утверждаете что отказ никак не обрабатывается. Тут проблемы с обычной логикой.
Убеждаюсь, что вы похоже вы сами не понимаете о чем говорите, просто набор букв сложенных в буквы, но смысла в них нет никакого. Вы просто не можете понятно объяснить, что вы спрашиваете. Как правило, это происходит когда человек сам толком не понимает что он срашивает и о чем говорит.
Примитивыны ваши представления о жизни. 3000 МВт тепловых в реакторе, с уцепной реакцией деления, с контрами охлаждения, регулирования, и управления 1000 МВТ электрических. Циркуляция первого контура что бы отвевести 3000 мегават тепловых, паргненраторы что бы тепло это тепло превартить в пар. Турбина где это тепло прверащается в обороты генератора и электросеть. И все это управляется примитивыными алгоритмами, которые зажигают лампочеку и ждук команды оператора, что бы он в ручную кажду из тысячи одновремнно работающих задвижке приведел в нужное положение.
Если для вас алгоритмы управления ядреным реактором, турбиной в составе АЭС, ядерной паротурбинной устанвокой ледокола, там где работает SimInTech примитивные, то ли бо вы занимаете космической баллистикой для расчета таректорий межзведных траекторий, либо вы просто зведун-теоретик, либо одно из двух.
Я же уже почитал окаменелое говно динозавров которое вы тут вытащили. И уже объяснил почему английский ученые сравнивают жопу с пальцем. FBD диаграмма в SimInTech не является картинкой, на которую нужно тупить, как в эксперементах английский ученых из вашей статьи. FBD диаграммы в SimInTech это исполняемые модели, которые используюте при отладке комплексных моделей сложных тезнических объектов, и программы управления это только части общего объекта. И для того что бы сравнивать текст программы с FBD программы SimInTech вы сначала попробуйте в тексте описать модель с 220 объектами у которых есть по 9 состояний только отказова. Я вам это показал за 3 минуты. Вы в ответ опять что то невразмутельное мычите. И еще предлагете мне читать это дерьмо. Спасибо кушайте сами. Я вам лучше про примитивную систему управления видео покажу.
Одни читают окаменелое достижение английский ученых столетней давности, другие делают ледоклы.
SimInTech для тех кто делает!
Похоже это вы не догоняете, что модель объекта управления показаная в видео, представляет собой самый настоящий набор алгоритмов созданный в виде FBD диаграмм. Вы реальное не понимаете, что схемы это не реальный трубы, моторы, задвижки? Не догоняете? Открою вам тайну это просто алгоритмы! Еще раз крупно на видео показаны АЛГОРИТМЫ :)))))
Сложность этих алгоритмов на один или два порядка превышает сложность алгоритмов систем управления, в модели видно, что вычислительная нагрузка от модели турбины (каторая тоже просто алгоритм) в 10 раз больше чем нагрузка от алгоритмов защиты.
И то что я показал в видео, это есть комплексаня обработка отказов, в виде перключения состояний в различных частях модели.
У вас как в голове с приченно - следсвенныем связями? Регулятор начал работу, при возникновени отказа. Это повашему "отказ никак не отрабатвается"? Вы серьезно? Или это рлоф такой, который я не догоняю? Алгоритм включился при отказе. Событие произошо! Состояние изменилось! В этом примере, регулятор это просто еще один алгоритм который обрататывает отказ, и меняет свое состояние. Это очевидная, даже ребенку демонстрация переключения состояний алгоритмов при возникновении отказа. Это наглядный пример обработки отказа, в программе написаной на языке FBD диаграмм. В дата-флоу подходе. Все как вы просили
Если вы хотите конккртено обсудить защиты турбины, вот вам пример алогоритма на языке DataFlow. Но смысла обсуждать его я не вижу, тут нужны турбинисты, а не как не специалисты по автоматам Мили Мала и прочих Хоров.
Если вы опять пытаетесь протолкнуть окаменело дерьм динозавров от английских ученых, так я уже прочитал статью и вижу что это просто наукообразная бессмыслица, где сранвиается текст программы с диаграммой. И показано что прочитать можно быстрее текст. Это и без английских ученых ясно. И написать программу так же быстрее чем нарисовать диаграмму. Это и без английских ученых ясно. Но это вообще мимо темы. Поскольку никто диаграмму статично никогда не смотрит. Диаграмма FBD в SimInTech это живая модель которую можно исполнять и видять процесс исполнения на схеме. И в этом случает диаграмма дает информацию которую в тексет просто нельяз прочитать, ее там нет по определению. Поэтому SimInTech рулит.
То есть показать у вас нечего? Чистая теория из статей англиский ученых 50 летней давности. Ладно объясню теоретику, что ему только что показали.
А ничего, что все что вы видете на экране это и есть программа? Может вам очки поменять? В видео демонстрация работы программы, SimInTech она называется. Вся программа созданана языком FBD и принципиальных схем, + скрипты SimInTech. Там нет ничего, кроме управляющией прогнраммы SimInTech. По вашим утвержедениям получается обработать отказы без автоматов мура милия и какого другого хера.
Я слышал про людей которые смотрят в книгу и видят фигу. Но фига в видео, это новое.
Я же вам именно это только что это и показал. Я на ваших глазах в программе перевел объект в состояние отказа нажатием кнопки. У меня в программе на ваших глаза изменилось состояние объекта.
1) В дилоговом окне изменилась индикация, начала моргать иконка.
2) На схеме гидравлической растет гидросопротивление, умееншается расход, расете перепад давления индикация закртытя.
3) В схеме локальной управляющией программы автоматики подключилась модель двигателя, отключились команды управления.
4) В схеме общих алгоритмов управления, включился в работу регулятор для компенсации снижения расхода.
И все это произошло на ваших глазах в управляющей программе SimInTech,
И я могу в этой модели обработать около 2000 таких отказов, только для одного типа оборудования, а там еще и насосы, клапана, датчики и у каждого до десятка вида отказов. И почему то у меня они все прекрасно обрабатываются в с нашим DataFlow подходом, без милей мулов и прочих херов. Хотя автоматы у нас тоже есть.
Ваша очередь, покажите что нибуть тольковое уже, интересно же.
Просто в отличие от теориетиков у нас есть что демонстрировать - SimInTech почувствуй нашу 25 сантиметровость!
Конечно есть и не только сказать, но и покажем, раскажем и дадим попробовать:
Пожалуйста вот вам пример стратегии обработки отказов на простой демонстрационной модели.
Покажите что нибудь подобное в автоматах миля или мура. Мне кажется, могу ошибаться. Теория конечных автоматов это интеллектуальный анонизьм не имеющий никакого практического применения. В практике используют простейшие реализации. Кде то у меня был текст от Esterl, где они объясняли, что все эти навороченые автоматы нихрена не годятся для реальных систем.
Возможно только если у Боинга, но они поэтому вернутся не могут, стратегия отработки отказов Мили с Муром как то не сработало.
А был бы у Боинга SimInTech были бы дома.
Да легко, отказы это вобще часть любой модели АЭС. Мы эти занимаемся постоянно, с самого рождения лет та 30 наверное.
Во первых конечные автоматы уже давно существуют как отделная библиотека блоков. Бери пользуйся на здоровье лет 5 уже как.
Во вторых, примеры автоматов для тестов любой грамотный программист на блоках логики собирает за 3 секунды. Причем с абсолютно любой логикой. Вот кусок боевой программы тестирования из авиации, из обычных FBD блоков с помощю тригеров собирается вполне себе конечно автоматная программа, готовя к генерации в борт на Си. Из дата флов лекго и непренужденно переходим в state machin. И обратно.
Пакетная оргнаизация в модели позволяет подключить и отклюичить любую тестирующую логику и делать там вообще все что душа пожелает, не меняя общую модель системы и модель алгоритмов управления.
SimInTech есть все!
Боинг, это как раз ваш пример, там все просто отлично и формальной верификацией и с соблюдением стандартов, которые американцы всей авиации и навязывали. И на любой чих у Боинга, есть бумажка в строгом соотвесвии и верификацией и валиацией и прочей байдой. А все наша авиационная отрасль на эти стандарты надрачивала и нас с SimInTech посылала в Боинге внедрится сначала. Потом что Боинг на Matlab Simulink и Simieпs Amesim работает, это лучшие стандарты в мировом Авиастроении.
В какой автомат? Время открытия зависти от давления в гидро-аккумуляторе и никак без модели процесса это требования верифицировать невозможно. Только запустив процесс в модели, можно убедится что во всех возможных режимах просадка давления в аккумуляторе обеспечивает нужный перепад давления для максимального времени открытия. И можно что угодно делать, но верифицировать это требование к алгоритмам без модели гидросистемы невозможно. Никакая темпоральная логика тут не поможет от слова совсем. Потому что алгоритмы здесь только часть гидравлической системы.
В Боинге все хорошо и с формальной верификацией и автоматы верифицирующие и ltl.
Только SimInTech у них нет. Вот и сидят астронавты кукуют.
Так не мы работае так все работают Боинг не даст соврать.
Ну и как формально верифицировать требования например такое: "Время открытия задвижки должно составлять не более 5 сек". Если само время открытия завист от давления в гидроаккомуляторе, которе так же управленияетя этим же кодом?
Требования к коду управляющих систем, для сложных технических объектов являются частью требований к процессами, и отдельно от процесса достаточно бессмысленно рассматривать, а все стандарты заточены именно на это. Есть вектор входа давайте сравним его с вектором выхода и будет нам счастье. Не будет.
Счастье возможно только с SimInTech :))))
Как раз у нас с SimInTech проверка более правильная и боле строгая, чем формальная проверка, связанная с инженерией требований. Поскольку формальные требования, всегда не полные, просто по опредлению и Чернобыль это легко доказал. Верификация описанная в стандартах, устаревших еще на стадии написания, совсем не панацея. Именно у нас технологи, которые боятся аварии и понимают куда нужно смотреть при моделирования процессов, что бы свести ее вероятность к минимум и повышают безопасность объектов за счет модели объекта SimInTech. И начали это делать когда было реально страшно менять аналоговую систему управления на цифровую на РБМК. Причем делали это как раз те кто в ликвидации участвовал аварии участвовал и косяки традиционной формальной верификации кода на себе ощущали.
И потом вот такие слайды для нас рисовали, когда модель в SimInTech совпадала с реальной АЭС.
Проблема в том, что в формальном процессе нет модели объекта, просто нет. И стнадартов требований к модели тоже нет. На входе требования ТЗ (которые всегда не полные по определению). На выходе формльная проверка кода на соответствие. В итоге на объекте при пуске ставят кучу промежуточных уставок, дополнительных ограничений и отлаживают долго и мучительно, потому, что если в требованиях ошибка и давление 15 атм, не обеспечит нужную скорость срабатывания, будет больно и неприятно. Отсюда длительные пуско-наладочные работы.
В SimInTech появляется модель объекта, на которой верфицируют требования. Модель позволяет проверить требования, на их физическую выполнимость (когда 5 страница требований противоречит 105 странице, поскольку физически невозможно их реализовать) и полноту самих требований. Когда в требованиях указано время закрытия задвижки, а модель позволяет получить требуемое давления в гидросистеме. И уже эта модель используется для верификации алгоритмов управления. В итоге общее качество системы управления повышается, и технологи спит более спокойно после пуска объекта.
Но если подойти формально, мы должные еще доказать, что давление рассчитанное моделью соовтесвует заданному времени открытия, и тут мы заходим на новый цикл верификации уже математической модели. Для атестованых кодов и запроетных аварий проблема снимается атестацией кода в атоме, в паспорте пишут код, и оргнаизацию котаря это код может использовать для заданных параметров устанвоки. А у технолога работающая АЭС с реактором РБМК он атестацию не проходил, да и модель на атестацию не сдавал. И два варианта, писать по дествующим стандартам, и писаться ночью при пуске, либо взять SimInTech создать модель на ней проверить алгоримты и сгенерировать код. Ну а проверяющим можно сказать что писал руками по текстовым требованиям.
Сравнение в статье кривое, сравнивать нужно не кратинку с текстом, динамическую модель в SimInTech с текстом в дебагере. И в качестве тестового языка брали LabView в нем создается программа, которую можно записать текстом короче и понятней. Диграмму FBD собирать сложнее и дольше. Выигрыш начинается с момента отладки. Как только система становится сложной для отладки, и проверки, вот тут собака и порылась.
Вот например я уже тут это видео выкладывал, расскажите как вы это текстом изобразите?
Тут фишка не в повышении качества кода как такового. В SimInTech фишка, в том что мы верифицируем код уже с моделью объекта. Грубо говоря нас и продвинутых атомщиков код, как код вообще не интересует. Ну вот вообще. Нам наплевать на верификацию типа подали вход - проверили выход. В SimInTech мы провреяем комплекс модель + код, и смотрим на температуры, давления, обороты и наладчик на АЭС не рассматривают код, их код вообще не парит, они заливают его в стойки и подключнаю к модели и смотрят на работу в комплексе. Так же налаживают систему управлени АПЛ и ледоколов.
Не в одном стандарте до сих пор нет модели объекта при верификации кода.
Наприме те же Матлаб в своих документах пишет вектор входных воздействий (а откуда он берется, их вообще не ипет) Если говорить про АЭС где нет проблем с размером массой и электричество датчиков можно лепить миллионами и вектор входных воздействий для верификации собрать для класической процедуры верификации вообще не возможно, даже теоретически. Поэтому все с умным видом смотрят в книгу стандатов и держат фигу в кармане.
Я уже писал про это в статье Модельно-ориентированное проектирование там есть пример требований которые мы верифицируем
«При повышении давления выше предельного значения время закрытия (открытия) предохранительного клапана должно составлять не более 5 секунд.»
И как проверить это требования, если время закрытия зависти от давления в гидрсистеме, которое само является предметом регулирования системой управления?
Главное периумущестов графического языка, для сложных и критических в плане безопасности систем, в том что, им могут пользоватся технологи. А значит из цикла разработки исчезает программист, который выучил Си но ничего не понимает в технологических процессах, для которых он програмирует.
для этого нужно комерческий дойти, условно если SimInTech заработает пару миллиардов, можно будет записать язк SimInTech как стандарт в системах безопасности. Но у нас все специалисты сейчас деалют реальные проекты
У меня сейчас сложилось впечатление, что у нас стандартами занимаются, те у кого мозгово или трудолюбие не хватает на реальную работу. Инженеров грамотных реально нигде не хватает. Мы занимаемся моделированием от косома до акеанских глубин, примерно везде видим систуации, людей просто нет. Поэтому любой грамотный специалист разрывается на реальных работах. Стандартами заниматся некогда от слова совсем, поэтому на выходе шлак. А стандрат цифровых двойников? Когда в самом определении логическая нестыковка. "Цифровой двойник это математическя модель связнаная информационно с объектом, если объек есть." Понятно цифровой двойник натягивали на модели на стадии проектирования. Потому что кому то понравилось западаное "Цифровые двойники", а мозгов и знания английского не хватило понять что двойник требует первака, иначет это не двойник а просто математическая модель.
Это не в СССР это везде и всегда. Наример у нас был заказчик в котором один отдел занимался разработкой софта для алгоритмов управления узлов вычислеительной сети, другой разрабатывал пртокол обмен данными. Они сидели в одном здания на разных этажах. И не общались друг с другом, только на испытаниях начинали лить бочки говна друг на друга. Мы как суб подрядчики ходили от алгоримистов к сетивикам что бы узнать, как их ипучий протокол реально работает и какике версии сетевой системы друг с другом совместимы.
Другая смешная история, когда нам сдали результаты эксперимента, мы делали модель и там явно было нарушение сохранения массы. И никто не мог ответить почему. Пока мы сами не приехали к закзачику взяли за руку проектировщика станда и повели в кабинет через стенку, где сидел эксперементатор, и он нам честно сказал, что в этом момент что бы точка росы не возникла, он просто добавляет теплого воздуха, открывая клапан, без измерений, просто на глаз. И пока мы не начали делать модель, никто об это и не знал.
Это истории без всякого СССР уже в наше время. Можно сказать что это русские рабы по натуре.
Но вот вам история с читыми французами, когда мы продаем Аэнергопроекту софт, как партнеры фарнцузско вендора. Там внутри война между прямым каналом, и продажами через посредников. В итоге увеличивают стоимость контракта, и на разницу продают кучу ненужного дерьма, постокльку один отдел, не отдал другому данные о реальной потребности заказчика. Это европейская фирма, и крупнейший заказчик, но феодальные войны внутри европейской компании. Нормально.
Это не оператор, это начальник цеха наладки, всем было известно примерно одинаково, как оказалось не очень
Я про это и гворю, и академики забивали на регламент, отправили письмо, и забили. И оперативнки забивали на письма и регламент. Все грамотные специалисты. Никаких "своих ребят" вообще нет, раздолбаи все. Не надо приплетать тайную ложу, туда где все объясняется явной лажой.
Но там в письме как раз ограничение на вывод стрежней. Но кто же на АЭС будет письма конструктора читать. Операторы сами умные, операторы после йодной ямы все стрежни веерх отправили. У них реактор не останавливался, он же нейтроны давала и тепло, занчит не останавливался.
Моя точка зрения виноваты одинаково и акдемики и операторы.
акдемики могли бы ограничеие в систему управления ввести, что бы не дать операторам вытаскивать все стержни.
С другой стороны, что мешало бы оператором и это ограничение откличить как САОР?
Не остался в стороне и научный руководитель, он в отличие от гл. конструктора выразил серьёзное беспокойство по поводу обнаруженного эффекта, вот что писал Курчатника:
- " при снижении мощности реактора до 50% (например, при отключении одной турбины) запас реактивности уменьшается за счет отравления и возникают перекосы высотного поля до Kz <= 1,9. Срабатывание A3 в этом случае может привести к выделению положительной реактивности. Видимо, более тщательный анализ позволит выявить и другие опасные ситуации".
Это цитата из письма, написанного своему руководству (в МинСредмаш). Были в нем и конкретные предложения по предотвращению возможной катастрофы:
— доработать конструкцию стержней РР и A3 реакторов РБМК с тем, чтобы исключить столб воды под вытеснителем при взведенном стержне;
— провести тщательный анализ переходных и аварийных режимов реакторов РБМК с учетом реальных градуировочных характеристик существующих стержней СУЗ;
— до проведения указанных мероприятий ввести в регламенты реакторов РБМК дополнение, ограничивающее число стержней, полностью извлеченных из реактора.
Да не должны, просто нужно читать что пишет главный конструктор. Есть письмо, в письме ограничени стрежней в врехнем положение прописано
Йодная яма вытащил 150 стрежней, все больше нельзя. Но инженер умнее, ректор не останавливался, тянем стрежни дальше.
Акдемики тоже хороши, ограничте автоматикой вывод 150 стрежней, но нет написали письмо которое, никто наверное и не читал до аварии.
Можно вытащить 170, можно а 200, а можно 300? Нельзя столько нет.
Ну это уже точно сказки про рептилоидов. Правительство могло пронюхать, потому что на какой-то АЭС слесаря при помощи напильников и какой то матери, перпиливают какитео стрежни. Правительству СССР не чем занятся было? Да в правительстве специалистов, что бы просто понять, что такое СУЗ ровно один министр Славский. Всем было абсолютно пофиг, что там слесаря пилят напильниками на этих АЭС. В то время кртические сборки и реакторы по университетам стояли.
А НИКИЭТ кому то запрещает переделывать СУЗ на работающей АЭС, что бы кто-то не догадался. Извините это скорее фантазии. Что бы подписать бумагу у НИКИЭТ надо было приехать с бутылкой коньяку и там бы разрешили, все что угодно, особенно если бы занли что может долбануть, а перепил СУЗов поможет. Но не знали.
У меня еще и кафедра Э7 Бауманки, она вообще Доллежалем основана и НИКИЭТом практически управлялась всю жизнь. Историю про стрежни, который просили переделать умницы с Чернобыля, там бы точно рассказали.
Именно, а грамотных людей не хватает на текущих стройках и разработках, поэтому ргеламенты и отстают. Если лет 10 - 15 темры строек сохранятся, то возможно опытные разработчики пойдут в эксперты писать регламенты. Но пока там сильный дефицит.
Дак любой регламент, это посмертный документ который от жизни отсал в момент написания. И те кто реально пишут программы для АЭС, они давно по технологиями обогнали регламенты. Например язык FIL который для РБМК изобрели в НИКИЭТ, более безопасный, но он не регламентами, не стандартами не предусмотрен. Я не заню официально но воообще зарегестировани? Но система безопасности РБМК не нем работает, нарушили регламент. Для того что бы регламент изменить надо лет 5.
Я не в атомке, поэтому могу говорить, правду. Я рядом с атомкой. И могу говорить то, про что атомщики, не расскажут. Я же привел пример, когда 2 два блока уже управлялись кодом генерированным из SimInTech, а на просьбу сделать справку для военных, разрабы говорили:
- На это я пойти не могу! Нет SimInTech в регламентах, не имеем право мы его использовать, мы все руками писали если, нас спросят.
Однажды на совещения в министерсве обороны, где мы первый раз толкали SimInTech военным, атомщик встал и сказал про меня буквально следующее:
Мы конечно для АПЛ SimInTech внедрили, но опять не через регламенты, а снизу через инженеров, которым реально нужен результат, не следование регламентам написанным в 50-го прошлого столетия.