OberonCore

Для накопления материала.

По материалам доклада в Гонконге:
http://www.inr.ac.ru/~info21/texts/2016 ... vation.pdf

Местная утренняя газета точнёхонько в день доклада пустила с приоритетом новость, взволновавшую редакцию достаточно сильно, чтобы посвятить ей передовицу:

В аэропорту Гонконга новая система управления воздушным движением от Raytheon (US) вырубилась на 26 секунд, из-за чего все, естественно, обделались -- как на земле, так и особенно в воздухе.

Система должна была начать работу ещё в 2012, но из-за неудовлетворительных результатов опытной эксплуатации (при дополнительных затратах в 90 миллионов HKD -- сверх полутора первоначальных миллиардов) она была введена в полную эксплуатацию только в середине ноября с.г.

Полная эксплуатация проходит с чередой инцидентов по вине системы (один самолёт исчез с экранов на 12 секунд, другой удвоился, третий был направлен впритык к земле, четвёртый и пятый опасно сблизились в воздухе, шестой оказался привидением на экране ...).

Передовица утверждает, что все подобные глюки должны были быть устранены во время опытной эксплуатации, и вот сейчас отцы Гонконга взволновались не на шутку (спецкомиссия, "дать ответ в 48 часов" и т.п.).

Судя по количеству глюков, можно предположить, что система написана на C++ с какой-нибудь CORBA -- как у атомных программистов до просветления.

***

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

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

Кроме того, сопровождение эквивалентных по функционалу программ, написанных на Обероне и, скажем, на С++, должно быть просто несоизмеримо по трудозатратам.

Другими словами, использование правильных инструментов при кодировании оказывает достаточно серьёзное влияние и на другие этапы жизни программ.

***

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

Казус в Гонконге демонстрирует, что IT-без-умие близко подошло к той грани, за которой платить придётся уже человеческими жизнями.

Беру на вооружение, Илья. Не хотелось бы повторения даже на уровне "Ариан-5".
А там был даже не С++. Там была необозримая Ада!!
Когда уже до манагеров дойдёт, что вопросы технические должны решать инженеры.
Сегодня по вине нашего провайдера опять полдня в выходной провёл на работе. Дорасчёт на КП на 12 (sic!!!!!)минут засёк обрыв связи раньше, чем вышестоящая организация. Smart Fep, чо? Федеральный комплекс же!)))

"Ошибки в софте для МРТ ставят под сомнение научные работы"
viewtopic.php?f=86&t=5800



Не совсем системы управления, но смежное.
Из направления критического ПО, скажем так.

viewtopic.php?f=12&t=5615

«Самолёты Tornado бундесвера не могут быть задействованы ночью»

viewtopic.php?f=12&t=3458

"По ком звонит ANSYS"
(опять же, не совсем системы управления, но критические для физического мира софтверные вопросы)

Когда и вижу столько ссылок на программные сбои -- начинаю не иллюзорно осознавать про какие "миллиарды долларов" вещают пророки в пустыне ИТ. Ушёл читать. Без злорадства, люди всё-таки гибнут. Но с укрепляющимся убеждением порочности современных инструментов. Да капиталистических способов производства тоже.

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

Бьются Аэробусы (конкретная модель) периодически выкатыванием за взлётную полосу. Но они выкатываются в N раз чаще без последствий, пилоты знают эту особенность (буквально в этом году было где-то - кажется, в Калининграде! - такое ЧП).
Там при включении реверса на торможение при посадке иногда что-то идёт не так (именно в стиле случайного глюка, как следует из описаний) - и вместо реверса происходит разгон (ну, видимо, направляющие, которые должны отклонить тягу вперёд, не встают в нужную позицию).
Годами такая шняга.

Калининград -- да. Без последствий, но в нашем "Храброво" -- Айрбас 320 выкатился так, что пришлось отменить несколько десятков полётов.
Несколько лет назад был случай в Иркутске (вместо торможения лайнер начал разгоняться и врезался в гаражи).
Понятно, что надо брать соотношение количество полётов к аварийным ситуациям, но тенденция откровенная: усложнение техники на существующих принципах не приводит к повышению надёжности/безопасности. Это как квартирные воры и стальные двери.

Тут показательно, что не могут устранить годами ошибку.

А если подойти к этому вопросу с другой стороны: производителю НЕ НУЖНО, чтобы такие ошибки были справлены? Личный опыт по таким штукам у меня есть))

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

Тем не менее, маразм крепчает.

https://tjournal.ru/p/aircraft-software



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



Бред. Даже если не драматизировать по поводу C, а допустить, что это приемлемый язык (который обуздывается организационными мерами, ДОПУСТИМ), то ясно же, что просто это откат на более низкий уровень. От технологии специализированной технологии разработки фиг знает на что.
Вопрос, опять же, интересует психиатрический: ЧТО ТАМ В ГОЛОВАХ ТВОРИТСЯ? КАК И НАХРЕНА?

Впрочем, я слышал такой аргумент:
"Трудно найти разработчиков на ADA"

Звучит жутковато. Т.е. разработку софта критических систем можно доверить людям, которые не способны перейти на Аду за 2 недели?
(А ведь разработчики софта Бе-200 после двухнедельных обучающих семинаров приступили к работе без проблем).

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

Переход с Ада на Си -- это не просто бред...))) Это апофеоз)))
И маразм этот иначе, как капиталистическим способом производства я не могу назвать. Комдив, по-моему. правильные соображения привёл выше.
Что касается ойПадофф на самолёте -- ой-упадёт... Как пить дать. Это всё откровенные меры удешевления. Хотя, те, кто такие решения принимает ведь наверняка -- ЗНАЮТ, что так делать нельзя.