Программа без ошибок - такая же абстракция, как -273 градуса

[bsivko]

незваный гость писал(а):

Давно меня так не веселили! Razz Razz Razz
И как это доказательство протекает? По высоте стопки бумаги с формальным доказательством правильности? Очень формальный процесс! Laughing Laughing

Теперь моя очередь рычать

Здесь вынужден остановится и спросить, насколько вам знакомы следующие понятия:
- критерий опасного отказа;
- требования к интенсивности опасных отказов;
- концепция и стратегия обеспечения безопаcности;
- резервирование/избыточность/дублирование;
- диверситет;
- безопасное поведение;

Если знакомы только на уровне гугла/термина, то мне будет достаточно сложно что либо объяснить.

незваный гость писал(а):

Любое управление впрыском влияет на безопасность. Потому, что неожиданно вставшая на шоссе машина на скорость 100 км/ч или больше (на автобане) — это ДТП, возможно со смертями.

Недавно промелькнувший пример — ошибка в срабатывании воздушных мешков. К сожалению, производители не любят говорить, что именно виной — ПО, детали, … Результат — произвольный выброс. Т.е,, вы ведёте себе машину и …

Сейчас очень много муссируется вопросов типа Drive-by-Wire. Steer-by-Wire (управление газом и тормозом, управление рулем через процессор). Вроде уже такие машины появились. Нисан (лет 10 или больше назад) ставил на машину 9 процессорных плат. В частности, в водительскую дверь и в багажник (для управления лампочками тормоза и т.п.) Смысл прост — экономия на проводах. Результат тоже прост: откажет процессор/программа — не показан поворот/торможение — ДТП.

Опять же, по поводу автотранспорта ничего утверждать не могу.
У нас светофор на перекрестке может не показывать красный в течении недели, не то что в какой-то момент движения. На ж.д. такое невозможно.

незваный гость писал(а):

Другой пример — управление светофорами. Комментарии, думаю, не нужны.

Пока что в сети ж.д. дорог России и Беларуси не пущено ни одного микропроцессорного устройства, которое влезло бы в схему управления светофором или заменило её. Я сам 3 года назад участвовал в анализе "новейшей и современной" схемы управления лампой светофора, что проводилось у нас в лаборатории. И док-во правильности нашло ряд дефектов, которые тестами/экспертно/... найти было практически нереально. (к слову сказать, было найдена куча ошибок на всех уровнях АПК и проект был благополучно отклонен).

незваный гость писал(а):

И о ЖД транспорте. Ну хорошо, сейчас есть адекватно работающая система. Через 30 (50, 150) лет реле начнут выходить из строя. Массово. И обнаружится, что такие (скажем, слаботочные) реле просто перестали выпускать. Как лампы. Как Интел перестал выпускать процессоры военной приёмки. И что Вы будете тогда делать?

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

К слову говоря, отечественные системы уже подходят к гране выработки ресурса. (Общий ресурс системы составляет порядка 20 лет, с продлением срока жизни - до 40).

незваный гость писал(а):

Но что самое интересное, Вы (опять!) не ответили по существу. Я говорю, что разработка ПО — это экономический процесс, а Вы отвечаете, что систему, не удовлетворяющую требованиям просто не примут. Ну и что? Какое отношение это имеет к экономике? Я, например, не покупаю просроченное молоко. Перестало ли животноводство быть частью экономики?!

Не примут. Делайте систему, которая будет более либо также безопасна, как существующая. Иначе - как с просроченным молоком.

P.S. Терпеть не могу аналогии. Особенно в массовом применении.

[незваный гость]

bsivko писал(а):

Теперь моя очередь рычать

Это пожалуйста. Чтоб я возражал. Чтобы было интереснее, могу сразу сказать, что ни один из терминов мне не известен. И даже гуглить не пойду, пока Вы меня не убедите, что они имеют отношение к обсуждаемому мной тезису, а именно, что производство ПО — это экономический процесс.

Но Вы абсолютно не поняли мою иронию. Как человек, «скрупулезно относящийся к любым утверждениям», Вы, я уверен, не можете не понимать, что доказать что либо можно только в рамках некоторой модели. Модели же всегда условны, и потому доказательства висят в воздухе.

Любопытным моментом (наверняка Вам известным) является то, что в отличии от физических объектов программы не стареют. Т.е., в физическом устройстве накапливаются трещины, грязь, происходит физико-химическое изменение материала со временем. А все дефекты программ закладываются их разработчиком в момент разработки, и только проявляются со временем. (Могу рассказать байку о моих взаимоотношениях с отделом тестирования, когда я говорил, что в системе есть опасный дефект, а мне отвечали — на стенде не обнаружено, значит исправлять нельзя…) Поэтому многие традиционные категории отказов плохо переносятся на ПО. Но это так, к слову…

bsivko писал(а):

Реле первого класса выпускаются везде и будут выпускаться. На реле работают и будут работать все напольные устройства ж.д.

Так и представляешь себе главного технолога кроманьонцев, который говорит: «Наши кремниевые топоры выпускались и будут выпускаться всегда!» Плохо, однако, верится.

bsivko писал(а):

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

Мне это просто интересно — как Вы себе это представляете? «на западе запрещено» «даже в плане исследований» — кем? кому? как? зачем запрещать? Это что, стволовые клетки, или Дарвиновская теория?

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

bsivko писал(а):

Не примут. Делайте систему, которая будет более либо также безопасна, как существующая. Иначе - как с просроченным молоком.

Так и я о том же. Не примут. Повторяю, не примут и не должны принимать.

Только это имеет ли это отношение к тому, что производство ПО — экономический процесс?

bsivko писал(а):

P.S. Терпеть не могу аналогии.

Доброе дело, хорошее дело. Лучший способ проявить нетерпимость, однако, — это продемонстрировать ограниченность конкретной аналогии.

[bsivko]

незваный гость писал(а):

производство ПО — это экономический процесс

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

незваный гость писал(а):

Но Вы абсолютно не поняли мою иронию.

В ваших постах я вижу не иронию, а

~600 г. до н.э.: "Всё есть вода" (Фаллес)
~570 г. до н.э.: "Всё есть огонь"(Анаксимандр)
~530 г. до н.э.: "Всё есть воздух" (Анаксимен)
...
2007 г. н.э.: "Всё есть $ " (незваный гость)

незваный гость писал(а):

Как человек, «скрупулезно относящийся к любым утверждениям», Вы, я уверен, не можете не понимать, что доказать что либо можно только в рамках некоторой модели. Модели же всегда условны, и потому доказательства висят в воздухе.

Ещё доказать можно с некой вероятностью. Знаком вам такой метод?

Например, один из этапов создания и внедрения любых устройств ждавтоматики - это опытная эксплуатация. Когда создаваемое устройство/система ставится на промышленный объект, опечатывается, и в течении года эксплуатируется. Вопрос: можно ли после этого делать какой-то вывод о надежности и безопасности системы в целом?

незваный гость писал(а):

Любопытным моментом (наверняка Вам известным) является то, что в отличии от физических объектов программы не стареют. Т.е., в физическом устройстве накапливаются трещины, грязь, происходит физико-химическое изменение материала со временем. А все дефекты программ закладываются их разработчиком в момент разработки, и только проявляются со временем. (Могу рассказать байку о моих взаимоотношениях с отделом тестирования, когда я говорил, что в системе есть опасный дефект, а мне отвечали — на стенде не обнаружено, значит исправлять нельзя…) Поэтому многие традиционные категории отказов плохо переносятся на ПО. Но это так, к слову…

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

незваный гость писал(а):

Так и представляешь себе главного технолога кроманьонцев, который говорит: «Наши кремниевые топоры выпускались и будут выпускаться всегда!» Плохо, однако, верится.

Ближайшие лет 20 замены реле не предвидится.
Надеюсь, такая формулировка больше устроит.

незваный гость писал(а):

Мне это просто интересно — как Вы себе это представляете? «на западе запрещено» «даже в плане исследований» — кем? кому? как? зачем запрещать? Это что, стволовые клетки, или Дарвиновская теория?

Это мировая практика. Если за 40 лет(включая транзисторы) все попытки влезть приводили к плачевным результатам, то отсюда вывод, что нечего там делать.

незваный гость писал(а):

Доброе дело, хорошее дело. Лучший способ проявить нетерпимость, однако, — это продемонстрировать ограниченность конкретной аналогии.

Аналогии применимы редко и чаще всего они вредны. Это мое мнение.

[незваный гость]

О! Мы, наконец, приходим к согласию…

bsivko писал(а):

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

Т.е., требования к системе могут иметь различную природу, в том числе и законодательную, но разработка ПО — это экономический процесс. Так?

bsivko писал(а):

2007 г. н.э.: "Всё есть $ " (незваный гость)

Опять передёргиваете? (В такой логике Ваши сообщения — «всё суть ж.д.». Но я не верю, что Вы так думаете.) Может, оно того не стоит?

bsivko писал(а):

Ещё доказать можно с некой вероятностью. Знаком вам такой метод?

Нет. Мне знакомо, что можно доказать, что с некоторой вероятностью… Что, вообще говоря, не одно и тоже. Далее, подобное доказательство базируется на некоторой статистической модели. Что опять-таки определяет пределы доказанного.

bsivko писал(а):

Например, один из этапов создания и внедрения любых устройств ждавтоматики - это опытная эксплуатация. Когда создаваемое устройство/система ставится на промышленный объект, опечатывается, и в течении года эксплуатируется. Вопрос: можно ли после этого делать какой-то вывод о надежности и безопасности системы в целом?

Какой-то — можно. Например, о непригодности системы. Сделать вывод о пригодности гораздо сложнее. И, снова: все прогнозы о будущем — это результат некоторой модели, которая сама нуждается в доказательстве.

bsivko писал(а):

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

Согласен.

bsivko писал(а):

Ближайшие лет 20 замены реле не предвидится.

Готов поверить.

bsivko писал(а):

незваный гость писал(а):

Мне это просто интересно — как Вы себе это представляете? «на западе запрещено» «даже в плане исследований» — кем? кому? как? зачем запрещать?

Это мировая практика. Если за 40 лет(включая транзисторы) все попытки влезть приводили к плачевным результатам, то отсюда вывод, что нечего там делать.

Ещё раз по тому же месту: где, что и как запрещается. Не используется, а запрещается, причём на уровне исследований. Вы ведь утверждали именно это?

[bsivko]

незваный гость писал(а):

Т.е., требования к системе могут иметь различную природу, в том числе и законодательную, но разработка ПО — это экономический процесс. Так?

Вот так:

bsivko писал(а):

С одной стороны, создание ПО имеет стоимость в некое число денежных знаков.

незваный гость писал(а):

Опять передёргиваете? (В такой логике Ваши сообщения — «всё суть ж.д.». Но я не верю, что Вы так думаете.) Может, оно того не стоит?

Может и передергиваю. Но я пишу то, что вижу. То что вы думаете я в точности не вижу. Вижу то, что вы пишете.

незваный гость писал(а):

Нет. Мне знакомо, что можно доказать, что с некоторой вероятностью… Что, вообще говоря, не одно и тоже. Далее, подобное доказательство базируется на некоторой статистической модели. Что опять-таки определяет пределы доказанного.

Мы начали с того, что в этом мире ничего абсолютно доказать невозможно. Вернулись?
Я начал с того, что у меня вероятностное понимание вопроса верификации. Опять повторить?

незваный гость писал(а):

Какой-то — можно. Например, о непригодности системы. Сделать вывод о пригодности гораздо сложнее. И, снова: все прогнозы о будущем — это результат некоторой модели, которая сама нуждается в доказательстве.

Т.е. например если есть 2 системы, одна из которых испытывалась, а другая нет. Вы какую выберите? Или вам всем равно?

незваный гость писал(а):

Ещё раз по тому же месту: где, что и как запрещается. Не используется, а запрещается, причём на уровне исследований. Вы ведь утверждали именно это?

Как такового запрета нет.

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

[незваный гость]

bsivko писал(а):

Мы начали с того, что в этом мире ничего абсолютно доказать невозможно.

Не-а. Мы начали совсем с другого:

незваный гость писал(а):

1) Разработка программ — это практическая деятельность. Поэтому к ней неприменимы, скажем, критерии правильности доказательства из математики.

2) Программы полезны только во взаимодействии с внешней средой — как потребители (им нужно железо, на котором бежать) и как производители (будь то управление оборудованием или HMI игры).

3) Полезность программ — это ещё и экономическая категория. Соответственно, и качество — тоже экономическая категория.

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

bsivko писал(а):

Мы начали с того, что в этом мире ничего абсолютно доказать невозможно. Вернулись?
Я начал с того, что у меня вероятностное понимание вопроса верификации. Опять повторить?

Да хоть до посинения повторяйте. От повторения аргументы ещё ни разу ни стали сильнее.

Самое главное, что Вы упорно смешиваете мухи с котлетами: требования к верификации и экономику ПО. Если Вы внимательно прочитаете тезисы, то Вы увидите, что в них нет ни малейшего противоречия Вашей позиции.

bsivko писал(а):

Т.е. например если есть 2 системы, одна из которых испытывалась, а другая нет. Вы какую выберите? Или вам всем равно?

Отчего же. Та, которая испытывалась, внушает большее доверие. Но вот насколько большее — большой и интересный вопрос. У Майкла Крайтона есть любопытная статья «Инопланетяне вызывают глобальное потепление». Почитайте, помогает методологически.

bsivko писал(а):

Как такового запрета нет.

Отлично!

[bsivko]

незваный гость писал(а):

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

Зачем?

Ну раз так хотите скурпулезности..

незваный гость писал(а):

1) Разработка программ — это практическая деятельность. Поэтому к ней неприменимы, скажем, критерии правильности доказательства из математики.

Не практическая разработка программ - это как?

Критерии применимы ровно настолько, насколько выполнено док-во. Не больше и не меньше. То, что оно не охватывает все аспекты работы ПО думаю понятно.

незваный гость писал(а):

2) Программы полезны только во взаимодействии с внешней средой — как потребители (им нужно железо, на котором бежать) и как производители (будь то управление оборудованием или HMI игры).

ПО это информация, а она на каком-то физическом носителе. Это все, что в этом пункте?

незваный гость писал(а):

Полезность программ — это ещё и экономическая категория. Соответственно, и качество — тоже экономическая категория.

Враки. Полезность не всегда может быть оценена только в деньгах.

Сравниваем "новостную ленту" по возрастающей:
"Данный продукт позволяет нам экономить 1 $ в год." - аксиома, к которой вы клоните.
"Новый комплекс ПО позволяет вести разработку в 2 раза быстрее"
"Новое ПО для верификации систем позволяет находить в 2 раза большее число ошибок"
"АПК 'Солнышко' предотвратил катастрофу аэробуса и тем самым спас около сотни жизней"

незваный гость писал(а):

Да хоть до посинения повторяйте. От повторения аргументы ещё ни разу ни стали сильнее.

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

незваный гость писал(а):

Самое главное, что Вы упорно смешиваете мухи с котлетами: требования к верификации и экономику ПО. Если Вы внимательно прочитаете тезисы, то Вы увидите, что в них нет ни малейшего противоречия Вашей позиции.

Не вижу достаточно полного понимания позиций(обоюдно).

незваный гость писал(а):

Отчего же. Та, которая испытывалась, внушает большее доверие. Но вот насколько большее — большой и интересный вопрос.

После года эксплуатации оценить вероятность опасного отказа можете?

незваный гость писал(а):

У Майкла Крайтона есть любопытная статья «Инопланетяне вызывают глобальное потепление». Почитайте, помогает методологически.

После Г.С.Альтшуллера "Как стать гением" ничего нового. И с моей точки зрения у Альтшуллера более правильная постановка задачи и ответ для описываемой в статье ситуации.

[worm2]

bsivko писал(а):

После года эксплуатации оценить вероятность опасного отказа можете?

В предположении, что вероятность опасного отказа есть случайная величина, распределённая по пуассоновскому закону (т.е. в рамках какой-то идеальной модели) --- да. Но вот насколько верно это предположение? Вдруг в этом году была сравнительно тёплая зима, а в следующем как нагрянут морозы под минус 40 --- и кто знает, может, в таких условиях что-нибудь сломается с вероятностью 100% ?

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

[незваный гость]

bsivko писал(а):

У меня есть более важные дела.

Согласен.

bsivko писал(а):

Зачем?

Мне уже не нужно. Ничего не нужно…

[bsivko]

worm2 писал(а):

В предположении, что вероятность опасного отказа есть случайная величина, распределённая по пуассоновскому закону (т.е. в рамках какой-то идеальной модели) --- да. Но вот насколько верно это предположение? Вдруг в этом году была сравнительно тёплая зима, а в следующем как нагрянут морозы под минус 40 --- и кто знает, может, в таких условиях что-нибудь сломается с вероятностью 100% ?

Если говорить о 100%-тной вероятности безошибочности, то её никто не дает.

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

worm2 писал(а):

Но вот есть ли у Вас формальные технологии, которые можно так же эффективно применять в других mission critical областях --- этого я из Ваших постов не понял. Наверняка ведь конкретный опыт здесь играет определяющую роль?

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

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

[незваный гость]

Я думал, что поскольку мы ни в чём согласится не можем, то нам и говорить не о чем. Сейчас понял, что был неправ. Вы не готовы согласится с моими тезисами. Но это не значит, что я не могу согласится с Вашими. Поэтому я предлагаю: сформулируйте свою позитивную позицию, позволяющие обосновать принятие решений при разработке ПО (на всех этапах).

Добавлено спустя 21 минуту 32 секунды:

bsivko писал(а):

И с моей точки зрения у Альтшуллера более правильная постановка задачи и ответ для описываемой в статье ситуации.

Я с некоторым трудом нашёл книгу Альтшуллера, но, просмотрев несколько страниц, не понял, как она связана со статьей Крайтона. Скажем, с основным тезисом: два числа и формула — это ещё не наука. Даже если Гору дают Нобелевскую премию, что вызывает здоровый смех у образованной публики, и соответствующее отношение к Нобелевскому комитету. Вы не дадите ссылочки подробнее что искать у Альтшуллера? Скажем, главы, или страницы?

[незваный гость]

worm2 писал(а):

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

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

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

bsivko будет меня пинать, что я опять всё свожу к деньгам, но … Готова ли Ваша компания заплатить, например, за переписывание всего кода на другом языке? Переучивание персонала? Остановить поставки на пару лет? А между тем, это может быть составной частью «технологии». Кстати, я был бы большим противником такового переписывания «с нуля». Не потому, что я влюблён в этот неизвестный мне язык. А потому, что такие переписывания редко кончаются хорошо. Обычно лучше работает постепенное замещение устаревшего кода.

worm2 писал(а):

Наверняка ведь конкретный опыт здесь играет определяющую роль?

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

Поэтому подобные системы очень консервативны. Меня не удивляют ничуть слова bsivko, что реле были, есть, и будут. Действительно, системы на базе электроники должны предложить не просто столь же надежное решение, но и в чём-то принципиально лучшее.

Я наблюдал такой переход дважды. Первый раз — как уже свершившийся факт в системах управления компрессорами и турбинами. Там новые системы защиты позволили поднять экономию топлива на 3-5% (это очень немалые деньги) и обеспечить практически безостановочное производство (только плановые остановки). Сейчас релейные защиты тяжёлых машин, как я понимаю, не рассматриваются никем.

Другой переход, который я видел, связан с системами защиты энергосистем (blackout типа Нью-йорскского). Там такой переход ещё только происходит. На данный момент обычной практикой является кодирование в программе релейной логики. Но эта практика уходит, уступая более точным динамическим алгоритмам защиты.

[bsivko]

незваный гость писал(а):

Поэтому я предлагаю: сформулируйте свою позитивную позицию, позволяющие обосновать принятие решений при разработке ПО (на всех этапах).

Если рассматривать в плане руководства/заказчика, то от них исходит требование, что ошибок по вине системы не должно быть вовсе. Такое может быть выполнено только при использовании стратегии обеспечения безопасности на безопасных элементах. Построение реле как безопасного элемента возможно, но вот любое микропроцессорное устройство при силовом воздействии может повести себя непредсказуемым образом.
Требования остаются, а времена меняются. На микроэлектронной базе уже нужно использовать другую стратегию. Построение систем на небезопасных элементах подразумевает, что безопасных систем не существует, возможно только снижение вероятности опасного отказа/сбоя к некому пределу. В этом случае используется принцип обнаружения опасного отказа и перехода в безопасное состояние до того, как появится второй отказ. При этом оценивается как быстро система может обнаружить опасный отказ и требуется доказательство (не обяз математическое) того, что система обнаружит любой опасный отказ.
Кроме того, на микроэлектронной базе появляется ПО. Но это не говорит о том, что нельзя строить ПО безопасным образом.
Например, согласно регламенту пуска ЭЦ(полностью релейной) станции требуется после монтажа проверить каждое действие, которое может сделать диспетчер. Т.е. задание маршрутов, проверка на враждебность маршрутов, замыкание секций, исскуственное размыкание и пр.. Релейные системы в отличие от ПО не зависают, могут быть построены так, что не обладать внутренней памятью (т.е. действие не зависит от предыдущих манипуляций, а только от состояний) и пр.. ПО логики станции можно построить аналогичным образом, исключив в нем зависания и поставить зависимости только от текущих состояний {это пример решений проблем}.
Исполнительный уровень работает уже другим образом. В конечном итоге состояния, влияющие на безопасность, определяют реле 1-го класса (т.к. никто не может гарантировать, что например электромагнитная помеха не изменит состояние ячейки памяти). Связь между логикой ПО и исполнительной группы - это отдельная категория, там свои особенности и принципы.
Если рассматривать сторонний софт, например ОС, на которой работает система, компилятор и пр.. то тут проблемы могут решаться с помощью диверситета и дублирования. Например, один и тот же софт работает на разных машинах под разными ОС, собранный на разных компиляторах.
Соответственно, при предоставлении конечного продукта заказчику предъявляются те решения и способы, которые были использованы. При чем информация предоставляется независимому сертификационному центру, эксперты которого делают заключение, на основании которого уже и принимается решение.

Решений проектирования много, и в деталях я все рассказать не могу т.к. у меня своя область.

незваный гость писал(а):

Я с некоторым трудом нашёл книгу Альтшуллера, но, просмотрев несколько страниц, не понял, как она связана со статьей Крайтона. Скажем, с основным тезисом: два числа и формула — это ещё не наука. Даже если Гору дают Нобелевскую премию, что вызывает здоровый смех у образованной публики, и соответствующее отношение к Нобелевскому комитету. Вы не дадите ссылочки подробнее что искать у Альтшуллера? Скажем, главы, или страницы?

По моему мнению (так читать до след. цитаты), статья Крайтона не об одной формуле как науке.
Статья о том, что существует "согласованная наука", так сказать, некое "научное мнение", которое не дает пути развитию в ряде случаев.И эта согласованная наука выдает описанные в статье результаты.
У Альтшуллера данная "согласованная наука" представлена как "внешние обстоятельства". Т.е. любая инновация, изобретение, открытие - не выживают в схватке с обстоятельствами в случае, если оно не поддерживается, не развивается и не пробивается человеком/организацией. Все примеры, приведенные Крайтоном попадают под это определение.

Он говорит, что:

Цитата:

В заключение я хотел бы отметить, в какого рода ситуациях требуется консенсус. Консенсус нужен только там, где не хватает научных аргументов.

Обращаю внимание, что 2 вопроса(2 формулы), которые были рассмотрены, на сейчас не формализованы и фактически безрезультатны. Т.е. проверить формулы мы никак не можем. Можно как-то обосновать, но проверить (только практика может что-то рассудить) никто не может. Поэтому эти 2 формулы на сейчас - всё что есть. И здесь нужен консенсус, т.к. пока что аргументов не хватает. С одной стороны это ненаучно (нет проверки практикой), с другой - научно, т.к. это всё что есть по рассматриваемому вопросу и по этим формулам можно сказать, что всё именно так по сегодняшним представлениям науки.

Крайтон говорит что нужен консенсус. Т.е. фактически нужно что-то, чтобы определяло, нужен консенсус или нет. Но вся история говорит о том, что его нет. Внешние обстоятельства это не только группа авторитетных ученых, это вся система в целом. Если система пришла к какому-то состоянию, то её просто так из него не выведешь. И Альтшуллер показывает, как нужно вести себя новаторам (белым), и как вести себя черным (представителям внешних обстоятельств) чтобы что-то получилось.

незваный гость писал(а):

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

Играют роль любые факторы. Может просто не хватить времени например.

Вы оказались на необитаемом острове с ноутбуком. Каковы факторы? Деньги? Нет. Заряд батарей, ваше здоровье и запас припасов - вот ваши главные факторы.

незваный гость писал(а):

Готова ли Ваша компания заплатить, например, за переписывание всего кода на другом языке?

Не понимаю сути вопроса. Потому что не указано: зачем? Зачем переписывать код?
К слову говоря, у нас с моим участием идет сейчас сборка кода 2х разных модулей (1 на другой платформе, 2й на другом железе). Потому что в одном случае нужен диверситет, в другом требуется более высокая эксплуатационная готовность. Принципы построения остаются, есть мысли по улучшению, но не с коренной ломкой.

незваный гость писал(а):

Поэтому подобные системы очень консервативны. Меня не удивляют ничуть слова bsivko, что реле были, есть, и будут. Действительно, системы на базе электроники должны предложить не просто столь же надежное решение, но и в чём-то принципиально лучшее.

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

[e2e4]

Вы уж извините, если это уже было в этой теме - всю не прочитал - взято с баш'а, по-моему, просто гениально:

Фрагмент индийского кода:

int a;
...
if( a != 7) a = a;
else a = 7;

Конечно, это не ошибка (наверное, хотя что имел ввиду автор - хрен знает). Но как получаются подобные конструкции - могу легко представить - постоянная правка кода под заказчика, нечеткое ТЗ - и вуаля

Добавлено спустя 4 минуты 52 секунды:

Ну и конечно золотое правило новичков в Си - автоматически проставлять открывающую и закрывающую фигурные скобки после if (...), else if (...), else. Бывало, по пол-дня отлаживал программы с нераставленными фигурными скобками. Причем, форматирование-то сделано верно, глаз не улавливает подвоха .

Ну и здесь уже упоминалось -

while(1);
{
}

Прекрасный способ потратить несколько часов на поиск ошибок программы/компилятора/целевой системы .

[anonim]

Ох и давненько я здесь не был, так что и ник свой (bekas) потерял, пришлось взять классический anonim. А сообщение мое связано с тем, что выплыла очередная ошибка в моей практике: система технлогического программирования работала без проблем уже четыре года и вдруг дала сбой. Причина оказалась до банальности простой, когда человеческий глаз видит то, что он желает видеть. Прототип функции выглядел как void func(char m[256]), а в самой функции было выражение типа sizeof(m).
Программисту думалось, что sizeof(m) был равен 256, ан нет - он равен 4 (размер указателя), так как в языке Си принципиально массив нельзя передать по значению (разве что если упаковать его в структуру). В результате такой ошибки все было хорошо до тех пор, пока число объектов не превышало 4 (это были управляющие программы, выполняющиеся в контроллерах), а как их стало 5, так связь системы отображения с исполняемой системой была заблокирована для этой пятой программы. И вроде тестировалось все, а вылезло боком через четыре года...