LINUX.ORG.RU
ФорумTalks

Реактор ITER-то, оказывается опенсурсным ПО будет управляться! RHEL + CODAC + EPICS

 , , , ,


0

2

Subj

В больших промышленных проектах наладка АСУТП зачастую определяет задержку запуска всего проекта. Во-первых она логически идет последним этапом (невозможно настраивать систему управления не установленного оборудования) а во-вторых собирает все ошибки монтажа, изготовления и т.п., которые и всплывают на отладке. ИТЭР тут рискует собирать полное бинго: мало того, что сам проект запредельно сложен, так многие компоненты еще и первые в своем роде, поставляются из разных стран и включают в себе свои локальные системы управления. Несмотря на предпринятые превентивные меры в виде открытого ПО в качестве управляющего стека (RHEL + CODAC + EPICS) и раздачи комплектов ПО и железа всем заинтересованным, запуск системы с десятками тысяч датчиков, тысячами исполнительных элементов (многие со своим ПО и железом “внутри”), часть из которых к тому же должна соответствовать критериям надежности для ядерных объектов будет очень сложной задачей.

Логично для научного проекта.

★★★

И шо, если еб@нёт из-за паники ядра, я виноват буду?

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

ну вообще да. Правда я сомневаюсь, что твое ядро в RHEL юзают. Или мы чего-то не знаем?

Kompilainenn ★★★★★ ()
Ответ на: комментарий от post-factum

Просто тебя заставят при пуске присутствовать. Так что покупай монтировку и тренируйся, хэдкрабы сами себя не замочат.

gremlin_the_red ★★ ()
Ответ на: комментарий от gremlin_the_red

Так что покупай монтировку ...

...или шапочку из фольги.

crypt ★★★★★ ()
Ответ на: комментарий от Kompilainenn

Я коммичу в даунстримное ядро RHEL’а. А всё потому, что я ядерщик в RH…

post-factum ★★★★★ ()
Ответ на: комментарий от gremlin_the_red

скорее наоборот, из-за паники ядра светлое термоядерное будущее отложится ещё на очередные 30 лет :)

Harald ★★★★★ ()
Ответ на: комментарий от post-factum

Вот так смотришь на человека, а он какой-то ядерщик в RH

Kompilainenn ★★★★★ ()

Ты так говоришь будто бы там был какой-то выбор. Де факто, если не писать свой стек, то особых альтернатив как бы и нет.

Другое дело EPICS — это система общего применения и поэтому когда всё устаканится для термоядерных реакторов IMHO самозародится своя автоматизация в количестве двух-трёх вариантов с открытым исходным кодом разной степени упоротости (и всё равно это будет лучше EPICS) и поддержки. Вот тогда для своего реактора и будет что выбрать. А пока увы и ах.

Evgueni ★★★★★ ()
Ответ на: комментарий от post-factum

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

vaddd ★★ ()
Ответ на: комментарий от vaddd

Всегда есть какая-то низкоуровневая логика, причем не одна, которая сделает все, что нужно.

Последняя фраза в жизни :)

anc ★★★★★ ()
Ответ на: комментарий от vaddd

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

Так что @post-factum, добавь лучше там парочку бекдоров пока можно.

alpha ★★★★★ ()
Ответ на: комментарий от anc

которая сделает все, что нужно.

Последняя фраза в жизни :)

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

vaddd ★★ ()
Ответ на: комментарий от post-factum

Ну я тебе ничего не говорила, если что :)

alpha ★★★★★ ()
Ответ на: комментарий от vaddd

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

Но при этом конечно невозможно запретить программеру страдать неврозом и считать, что на самом деле виноват он :)

vaddd ★★ ()
Ответ на: комментарий от vaddd

Согласен почти со всем, все верно написали, кроме:

Программер .... не должен быть ядерщиком, летчиком, гидрологом, механиком, электриком.

Поясню. Работая в той или иной области нужно знать «Зачем и как оно работает», а вот «индусо код», как раз идет по принципу «да нам пофиг, что дали то и накалякаем».

anc ★★★★★ ()
Ответ на: комментарий от anc

Поясню. Работая в той или иной области нужно знать «Зачем и как оно работает», а вот «индусо код», как раз идет по принципу «да нам пофиг, что дали то и накалякаем».

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

Человеческий мозг не беспределен, внимание и собранность не безграничны. И чем больше средний человек пытается держать в голове - тем больше вероятность опасных ошибок. Именно поэтому не имеет почти никакого значения насколько программер разбирается в баллистике или в ядерных процессах. Гораздо более глубокие специалисты должны раскладывать глобальную задачу на составляющие, ставить частные задачи, принимать работу, подвергать эскпертному изучению и натурным испытаниям. А программер должен накалякать что поручили, как это ни грустно :) Только такая организация труда позволяет создавать более-менее надежные сложные продукты. Условно говоря, с точки зрения надежности (не скорости разработки, не технического уровня, а именно надежности) десять посредственных узких специалистов лучше одного специалиста с десятикратным объемом знаний, хоть на первый взгляд это может показаться неверным или парадоксальным )

vaddd ★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)