Pull to refresh
132
416.2
Вячеслав @petuhoff

Моделирование сложных технических систем

Send message

Да я и не возражаю, против коррупции тем более американской.

Где в условиях эксперимента было обязательная работа на 100% моности перед выключением? И чем это требования мотивировалось?

Очень смешное рассуждение, с головой выдает наших людей. :))))))

Чем это требование мотивировалось?

Только русские инженегры могут задать такой вопрос. :))))))) Любой настоящий "законник", или настоящий немец никогда не прикаких условиях, такого вопроса не задаст. Тебование есть, есть требования, орудунг ордунг убер алес.

Любой эксперемент это в первую очердеь график, во вторую подготовка людей, оборудования измерения и прочей лабуды, если эксперемент делают невъипенные "законники", как вы утверждаете, то никто бы от графика не отклонился. Любое отклонение от графика эксперемента недопостимо. Потому что это экспереметнт. Даже работа реактора лишние часы это нарушение эксперимента. Хотя бы по размерну выгорания условия изменились? Изменились! Все идите в жопу. Это не важно конечно для выбега, до для "законника", это законная причинатотказатся либо от эксперимента, либо от требований оператора сети. Но в то время всем было пох, акакдемики придумали какую то хренеь, начальство общало премию, мы зделаем, мы же профессионалы.

- Ребята концепция сменилась, я обосрался. Глушим реактора на 40 часов.

С какой стати то? по Регламенту - остановки нет. Идет выделение энергии всех видов, в том числе электрической. У "законника" ноль причин саботировать эксперименты, на которые, кстати, приехали с другого завода сотрудники.

С простой стати. В ргеламенте экспереманта есть процесс снижения мощьности реактора до 0? Нет! Всем спасибо! Все свободные! Идите в жопу, с вашим эксперементом. Глушим реактор на 40 часов. Приходите еще. Так бы сделал любой "законник". Но не рзсдолбай русские инженеры на АЭС, профессионалу премию в размере 3х бутолок водки терять не хотелось.

Я здесь не защищаю академиков, те точно такие же раздолбаи. Я спорю с тезисом что на Чернобыли были какието невипенные "заканоники", и только заговор академиков, которые все знали, но не дали "законникам" исправить реактор, что бы КПСС не догадался. Это смешно, не надо искать тайную ложу, где видна явная лажа.

Вылетел бы с волчьим билетом за саботаж без убедительной причины.

Да не смешите мои тапки, я лично знаю человека, который как раздолбай забыл в стойку управления ввести коэффициенты и АЭС поймала А3. И на его уровне вме пох было он еще 10 лет после этого спокойно работал дальше.

А вот директор, которуму нужно героя соцтруда или там очередную грамоту КПСС получить, тот конечно кирпичами бы наложил в шатаны и лишил бы премии в размере 3 бутылок водки. Это же 1986 водка тогда 10 рублей стоила, на волне борьбы с алкоголисзьмо, если я не ошибаюсь.

В процессе взрыва уже поздно, что то делать. А вот не доводить до взрыва, остановив реактора когда влетел в йодную яму, вполене могли бы и инженеры в поле. Если бы были "законники", то эксперимент отменили протсто по причине запроса оператора облэнерго, который попросил сдвинуть время отключения от сети. На этом месте, любой "законник" либо посла оператора на три веселыйе буквы, либо сообщил, что по просьбе оператора экспермент накрылся медным тазом. Поскольку условия эксперемента полностью поехали. Оператор "законник" просто погасил бы блок без всякого эксперимента, поскольку начальные условия нарушены, и блок работал в сети больше чем предполагалось планом эксперимента. Вот так поступают "законника", но совестские инженеры действуют не по законам, а по понятиям.

Провалили мощность, но нейтрорны и тепловыделение есть, значит реактор не остановлен.

В течение примерно двух часов мощность реактора была снижена до уровня, предусмотренного программой (около 700 МВт тепловых), а затем, по неустановленной причине, до 500 МВт. В 0:28 при переходе с системы локального автоматического регулирования на автоматический регулятор общей мощности оператор (СИУР — старший инженер управления реактором) не смог удержать мощность реактора на заданном уровне, и она провалилась (тепловая — до 30 МВт, нейтронная — до нуля)

Вот на этом месте, любой оператор "законник" встал бы и сказал:

- Ребята концепция сменилась, я обосрался. Глушим реактора на 40 часов.

Но инженегры сука грамотные стрежни можно вытащить. Тащи все стрежни вверх разгоняем мы молодцы и лучше тупых академиков знаем как этой байдой управлять. Но увы оказалось не очень знают, как и академики на самомо деле. Это херня оказалось ипучей и ипанула!

Это всё справедливо для живого железа. А в компьютерной модели поведение такое, какие уравнения написали разработчики. И эти уравнения поддаются анализу и без картинки.

Можно кнечно решения уравнение течения жидкости и газа на фортарне записывать, что бы отладить систему управления нагревателя. Но это не лучший и не самый быстрый вариант. Быстре использовать SimInTech, где уже в математичесок ядре зашито решение систем диференциальных уравнений.

Вот здесь мы как раз и переходим к "предметно ориентированому языку программирования" потому что на самом деле на рисунке с трубами и задвижками, не картинка на которую как бараны на ворота смотрят английские ученые из статьи 92 года, а система уравнений двухфазной сжимаемой жидкости, просто упакованная в принципиальную гидравлическую схема в среде SimInTech. Именно это я и пытался объяснить уважаемаемому @mosk_on

Например для канала решатеся система уравнений описаная в справке так Теплогидравлика/Канал

И когда пользователь SimInTech технолог отлаживает алгоритм управления например в таком виде:

Отладка систему управления
Отладка систему управления

Он как раз и занимается анализом системы уравнений, а не тупо смотрит на картинку. Можно конечно для каждой трубы в системе отдельно на фортране писать систему уравнений, а можно взять уже готовый среду моделирования динамических систем SimInTech и делать все то же самое в виде принципиальной гидравлической схемы. По сути SimInTech реализует трансфер системы математических уравнений описывающих физические процессы в технологические расчетные схемы, понятные технологу процесса.

От научных формкл к инженерному решению
От научных формкл к инженерному решению

А адекватность модели реальному железу - тоже нужно отдельно доказывать.

Конечно, если вы впервый раз реализуете решение системы уравнений механики жидкости газа на фортарне, а потом это подключате к программе, надо доказывать.

Но когда у вас альтернатива отлаживать систему управления на реакторе РБМК который взорвался в Чернобыле, то лучше всетакт отладить программу управления с моделью, даеж если ее впервый раз написали. Страшно, но отлаживать на реальном РБМК еще страшней.

Зато когда вы еще 20 лет назад получили совпадение процессов в модели МВТУ-4 (Дедушка SimInTech) и измерений с реальнокак на следующей картинке, то вопросы доказательства адекватности сами собой снимаются. Не каждая программа подтвержадется эксперементом на реакторе который взорвался в чернобыле.

Сравнение модели и реактора
Сравнение модели и реактора

SimInTech адеватные модели для адекватных инженеров!

Это информация из предметной области, а не свойство среды разработки. 

Проблема в том, что эта информации не сущестует, без диниамческого расчета, в предметной области. Поскольку процесс динамический и в системе все парвметры постоянно меняются. Например в выше приведенном примере, перепад давления может опредялятся регулятором температуры в программе управления. В этом случае мы получили обратную связь. Ширина зоны нечуствительности в программе зависит от перепада давления, а перпад давления зависит от настройки регулятора температуры в той же программе. В итоге без модели объекта верифицировать это программу невозможно. И если нет среды динамического моделирования настройку делают на живоме объекте на или на стенде.

Это хорошая идея, если надо один раз посмотреть. А если нужно автоматически тестировать после внесённых изменений - нужно писать юнит-тест.

Для тестирования то же есть инструменты и методы в SimInTech

Автоматическая проверка требований ТЗ в процессе динамического моделирования

На схеме FBD диаграммы в процессе динамичесеоо моделирование отражается текущие состояния всего процесса.

Например в гидравлической диаграмме у меня отражается моргнаинем процесс закрытия Z1 на 2.47 секунде процесса. Перейдя в алгоритм управления я вижу команду закрыть, и вижу что она возникла из-за того что давлени в узле больше уставки.

Через некоторое время давление снизистя и я увижку как команда закртить на FBD диаграмме будет 0. Можно видеть цифры, как на рисунке, можно их убрать оставть тольк цвет линии больше 0 розовый черынй меньше 0. А можно вообще построить график измения давления и графики команды задвижки, что бы убедится что закрытие и открыте соответсвует давлению определнным технологом.

Пример диаграммы в процессе отладки
Пример диаграммы в процессе отладки

Кстати, даже на это простом примере, ширина зоны нечусввительность определяется скорость движения задвижки и перепадом давления между узлами. Имеяя только алгоритмы управления верефицировать корректность задания зоны нечуствительности просто не возможно.

А уважаемый @mosk_on думает что автомат мура мула или хера ему поможет верифицировать программу управления.

Вот эта сатья английских ученых от 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. Но смысла обсуждать его я не вижу, тут нужны турбинисты, а не как не специалисты по автоматам Мили Мала и прочих Хоров.

Пример алгоритма защиты
Пример алгоритма защиты

И да, еще в 90е годы прошлого века было экспериментально показано, что графические дата-флоу языки, типа Simintech, проигрывают по читаемости текстовым. 

Если вы опять пытаетесь протолкнуть окаменело дерьм динозавров от английских ученых, так я уже прочитал статью и вижу что это просто наукообразная бессмыслица, где сранвиается текст программы с диаграммой. И показано что прочитать можно быстрее текст. Это и без английских ученых ясно. И написать программу так же быстрее чем нарисовать диаграмму. Это и без английских ученых ясно. Но это вообще мимо темы. Поскольку никто диаграмму статично никогда не смотрит. Диаграмма 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. И обратно.

Автомат тестирования в FBD диаграмме
Автомат тестирования в FBD диаграмме

Пакетная оргнаизация в модели позволяет подключить и отклюичить любую тестирующую логику и делать там вообще все что душа пожелает, не меняя общую модель системы и модель алгоритмов управления.

SimInTech есть все!

Это тот Боинг, у которого сейчас Старлайнер завис у МКС? Хорошие у вас ориентиры для подражания... :)))

Боинг, это как раз ваш пример, там все просто отлично и формальной верификацией и с соблюдением стандартов, которые американцы всей авиации и навязывали. И на любой чих у Боинга, есть бумажка в строгом соотвесвии и верификацией и валиацией и прочей байдой. А все наша авиационная отрасль на эти стандарты надрачивала и нас с SimInTech посылала в Боинге внедрится сначала. Потом что Боинг на Matlab Simulink и Simieпs Amesim работает, это лучшие стандарты в мировом Авиастроении.

Если сможете требование формально записать. А потом преобразовать его, скажем, в верифицирующий автомат, если динамически верифицировать планируете... или в ltl, если статически верифицировать умеете.

В какой автомат? Время открытия зависти от давления в гидро-аккумуляторе и никак без модели процесса это требования верифицировать невозможно. Только запустив процесс в модели, можно убедится что во всех возможных режимах просадка давления в аккумуляторе обеспечивает нужный перепад давления для максимального времени открытия. И можно что угодно делать, но верифицировать это требование к алгоритмам без модели гидросистемы невозможно. Никакая темпоральная логика тут не поможет от слова совсем. Потому что алгоритмы здесь только часть гидравлической системы.

Старлайнер с орбиты снимите сначала...

В Боинге все хорошо и с формальной верификацией и автоматы верифицирующие и ltl.

Только SimInTech у них нет. Вот и сидят астронавты кукуют.

Ох, как интересно вы работаете...

Так не мы работае так все работают Боинг не даст соврать.

Есть. Если вы не можете формально верифицировать свойства, так и скажите. Если не можете формально задать требования, то тоже не надо фантазировать и наводить тень на плетень. 

Ну и как формально верифицировать требования например такое: "Время открытия задвижки должно составлять не более 5 сек". Если само время открытия завист от давления в гидроаккомуляторе, которе так же управленияетя этим же кодом?

Требования к коду управляющих систем, для сложных технических объектов являются частью требований к процессами, и отдельно от процесса достаточно бессмысленно рассматривать, а все стандарты заточены именно на это. Есть вектор входа давайте сравним его с вектором выхода и будет нам счастье. Не будет.

Счастье возможно только с SimInTech :))))

ну, и смотрите, кто ж запретит... или не смотрите... :) вам-то понятно, по барабану, если в результате ошибки возникнет авария на атомной станций... у вас фига в кармане, куча людей погибнет, а в тюрьму пойдет технолог, которого "код вообще не парит". Молодцы! Хорошо устроились.

Как раз у нас с SimInTech проверка более правильная и боле строгая, чем формальная проверка, связанная с инженерией требований. Поскольку формальные требования, всегда не полные, просто по опредлению и Чернобыль это легко доказал. Верификация описанная в стандартах, устаревших еще на стадии написания, совсем не панацея. Именно у нас технологи, которые боятся аварии и понимают куда нужно смотреть при моделирования процессов, что бы свести ее вероятность к минимум и повышают безопасность объектов за счет модели объекта SimInTech. И начали это делать когда было реально страшно менять аналоговую систему управления на цифровую на РБМК. Причем делали это как раз те кто в ликвидации участвовал аварии участвовал и косяки традиционной формальной верификации кода на себе ощущали.

И потом вот такие слайды для нас рисовали, когда модель в SimInTech совпадала с реальной АЭС.

Срванения модели и процессора на РБМК-1000
Срванения модели и процессора на РБМК-1000

Верификация -- это формальный процесс, связанный с инженерией требований. У вас ни требований, ни верификации... Виртуальный объект управления -- это хорошо. Но не вы это придумали, и не вы единственные это используете.

Проблема в том, что в формальном процессе нет модели объекта, просто нет. И стнадартов требований к модели тоже нет. На входе требования ТЗ (которые всегда не полные по определению). На выходе формльная проверка кода на соответствие. В итоге на объекте при пуске ставят кучу промежуточных уставок, дополнительных ограничений и отлаживают долго и мучительно, потому, что если в требованиях ошибка и давление 15 атм, не обеспечит нужную скорость срабатывания, будет больно и неприятно. Отсюда длительные пуско-наладочные работы.

В SimInTech появляется модель объекта, на которой верфицируют требования. Модель позволяет проверить требования, на их физическую выполнимость (когда 5 страница требований противоречит 105 странице, поскольку физически невозможно их реализовать) и полноту самих требований. Когда в требованиях указано время закрытия задвижки, а модель позволяет получить требуемое давления в гидросистеме. И уже эта модель используется для верификации алгоритмов управления. В итоге общее качество системы управления повышается, и технологи спит более спокойно после пуска объекта.

Но если подойти формально, мы должные еще доказать, что давление рассчитанное моделью соовтесвует заданному времени открытия, и тут мы заходим на новый цикл верификации уже математической модели. Для атестованых кодов и запроетных аварий проблема снимается атестацией кода в атоме, в паспорте пишут код, и оргнаизацию котаря это код может использовать для заданных параметров устанвоки. А у технолога работающая АЭС с реактором РБМК он атестацию не проходил, да и модель на атестацию не сдавал. И два варианта, писать по дествующим стандартам, и писаться ночью при пуске, либо взять SimInTech создать модель на ней проверить алгоримты и сгенерировать код. Ну а проверяющим можно сказать что писал руками по текстовым требованиям.

Сравнение в статье кривое, сравнивать нужно не кратинку с текстом, динамическую модель в SimInTech с текстом в дебагере. И в качестве тестового языка брали LabView в нем создается программа, которую можно записать текстом короче и понятней. Диграмму FBD собирать сложнее и дольше. Выигрыш начинается с момента отладки. Как только система становится сложной для отладки, и проверки, вот тут собака и порылась.

Вот например я уже тут это видео выкладывал, расскажите как вы это текстом изобразите?

Тут фишка не в повышении качества кода как такового. В SimInTech фишка, в том что мы верифицируем код уже с моделью объекта. Грубо говоря нас и продвинутых атомщиков код, как код вообще не интересует. Ну вот вообще. Нам наплевать на верификацию типа подали вход - проверили выход. В SimInTech мы провреяем комплекс модель + код, и смотрим на температуры, давления, обороты и наладчик на АЭС не рассматривают код, их код вообще не парит, они заливают его в стойки и подключнаю к модели и смотрят на работу в комплексе. Так же налаживают систему управлени АПЛ и ледоколов.

Не в одном стандарте до сих пор нет модели объекта при верификации кода.

Наприме те же Матлаб в своих документах пишет вектор входных воздействий (а откуда он берется, их вообще не ипет) Если говорить про АЭС где нет проблем с размером массой и электричество датчиков можно лепить миллионами и вектор входных воздействий для верификации собрать для класической процедуры верификации вообще не возможно, даже теоретически. Поэтому все с умным видом смотрят в книгу стандатов и держат фигу в кармане.

Я уже писал про это в статье Модельно-ориентированное проектирование там есть пример требований которые мы верифицируем

«При повышении давления выше предельного значения время закрытия (открытия) предохранительного клапана должно составлять не более 5 секунд

И как проверить это требования, если время закрытия зависти от давления в гидрсистеме, которое само является предметом регулирования системой управления?

Главное периумущестов графического языка, для сложных и критических в плане безопасности систем, в том что, им могут пользоватся технологи. А значит из цикла разработки исчезает программист, который выучил Си но ничего не понимает в технологических процессах, для которых он програмирует.

для этого нужно комерческий дойти, условно если SimInTech заработает пару миллиардов, можно будет записать язк SimInTech как стандарт в системах безопасности. Но у нас все специалисты сейчас деалют реальные проекты

У меня сейчас сложилось впечатление, что у нас стандартами занимаются, те у кого мозгово или трудолюбие не хватает на реальную работу. Инженеров грамотных реально нигде не хватает. Мы занимаемся моделированием от косома до акеанских глубин, примерно везде видим систуации, людей просто нет. Поэтому любой грамотный специалист разрывается на реальных работах. Стандартами заниматся некогда от слова совсем, поэтому на выходе шлак. А стандрат цифровых двойников? Когда в самом определении логическая нестыковка. "Цифровой двойник это математическя модель связнаная информационно с объектом, если объек есть." Понятно цифровой двойник натягивали на модели на стадии проектирования. Потому что кому то понравилось западаное "Цифровые двойники", а мозгов и знания английского не хватило понять что двойник требует первака, иначет это не двойник а просто математическая модель.

В CCCР по многим отзывам был неофеодальный порядок и каждой министерство было "вещь в себе", мало контактируя с другими почти реализуя внутри себя идеал натурального хозяйства :-)

Это не в СССР это везде и всегда. Наример у нас был заказчик в котором один отдел занимался разработкой софта для алгоритмов управления узлов вычислеительной сети, другой разрабатывал пртокол обмен данными. Они сидели в одном здания на разных этажах. И не общались друг с другом, только на испытаниях начинали лить бочки говна друг на друга. Мы как суб подрядчики ходили от алгоримистов к сетивикам что бы узнать, как их ипучий протокол реально работает и какике версии сетевой системы друг с другом совместимы.

Другая смешная история, когда нам сдали результаты эксперимента, мы делали модель и там явно было нарушение сохранения массы. И никто не мог ответить почему. Пока мы сами не приехали к закзачику взяли за руку проектировщика станда и повели в кабинет через стенку, где сидел эксперементатор, и он нам честно сказал, что в этом момент что бы точка росы не возникла, он просто добавляет теплого воздуха, открывая клапан, без измерений, просто на глаз. И пока мы не начали делать модель, никто об это и не знал.

Это истории без всякого СССР уже в наше время. Можно сказать что это русские рабы по натуре.

Но вот вам история с читыми французами, когда мы продаем Аэнергопроекту софт, как партнеры фарнцузско вендора. Там внутри война между прямым каналом, и продажами через посредников. В итоге увеличивают стоимость контракта, и на разницу продают кучу ненужного дерьма, постокльку один отдел, не отдал другому данные о реальной потребности заказчика. Это европейская фирма, и крупнейший заказчик, но феодальные войны внутри европейской компании. Нормально.

То, что смоленский оператор, с его слов, если не хвастался, знал больше про регламент, чем официально было написано и известно ЧАЭС - таки символизирует.

Это не оператор, это начальник цеха наладки, всем было известно примерно одинаково, как оказалось не очень

...потому что я думаю по факту так и было. Был регламент, эквивалентный итальянской забастовке, за реальное выполнение которого можно было бы вылететь с волчьим билетом. И был массив "понятий", когда академики на бегу сквозь зубы поясняли, что на самом деле надо понимать вместо написанного в регламенте. И вот думаю, у "своих ребят" из МинСредМаша доступ к этой ноосфере был намного лучше, чем у нежелательных чужаков из МинЭнерго...

Я про это и гворю, и академики забивали на регламент, отправили письмо, и забили. И оперативнки забивали на письма и регламент. Все грамотные специалисты. Никаких "своих ребят" вообще нет, раздолбаи все. Не надо приплетать тайную ложу, туда где все объясняется явной лажой.

1
23 ...

Information

Rating
2-nd
Location
Москва, Москва и Московская обл., Россия
Registered
Activity