Sukhoi SuperJet для верующих и неверующих

Тема: Sukhoi SuperJet для верующих и неверующих

Обсуждаем: Sukhoi SuperJet для верующих и неверующих, Forum.msk, 29.01.2007

Первый самолет Sukhoi SuperJet-100, предназначенный для наземных испытаний, доставили в воскресенье в подмосковный Жуковский на тяжелом транспортном самолете Ан-124 "Руслан"

10.02.2013 Grisha пишет:
Сообщить модератору
Ссылка на это сообщение
 

2 Grisha

Вы уж извините меня, тут-то про самолёты пишут, а мы о программировании говорим. хотел бы уточнить, что Вы имели ввиду, говоря о JAVA как о наиболее надёжном языке? какие критерии его так характеризуют?



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

10.02.2013 Hogner John пишет:
Сообщить модератору
Ссылка на это сообщение
 

Пара статеек в тему с непрофильного ресурса
http://habrahabr.ru/post/145371/
http://habrahabr.ru/post/83534/

10.02.2013 astoronny пишет:
Сообщить модератору
Ссылка на это сообщение
 

Если подразумевается встоенная систем JUnit Еesting Аramework, то это эффективное средство для unit testing, не более. Багов ловить вполне помогает, при разработке, причем на начальных стадиях, в основном — что и подчеркнуто в названии...
К какой-либо надежености в реальном времени и защите от сбоев она отношения не имеет, насколько я понимаю.

10.02.2013 musha пишет:
Сообщить модератору
Ссылка на это сообщение
 

> Помнится где-то встречал цифру о потребном времени проверки современного процессора на все возможные комбинации на его входах. Оказалось что это время превышает время существования Земли. Я уже не говорю о сбоях памяти космическими лучами, интенсивность которых на высоте в порядки превышает наземную радиацию. ;)

именно поэтому перебором и не тестируют. перебором даже не проектируют. а для лучей есть защищенное исполнение.

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

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

10.02.2013 _TG_ пишет:
Сообщить модератору
Ссылка на это сообщение
 

на практике у цифровой системы есть простые и разработанные давным давно способы проверки корректности создаваемой и передаваемой информации. [...] сравните например аналоговый карбюратор и цифровую систему впрыска - колдовство над мотором ушло в прошлое и уже воспринимается как байки.



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



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


Этот подход применяется там, где отказоустойчивость реализуется методом резервирования. Резервирование работает для случайных отказов (например, сбой процессора из-за пролетевшей частицы космического излучения) и не работает для систематических отказов (например, дефектная партия транзисторов). На производстве есть свои методы борьбы с систематическими отказами, в софтверной индустрии свои. Ошибки софтверного архитектора (неучтенный сценарий) или программиста (введена константа 22 вместо 20) как правило приводят именно к систематическим ошибкам. С ними и борются независимыми командами. Я бы еще сказал, что ключевые инженеры в независимых командах не должны принадлежать к одной школе, так как возможны общие ошибки, связанные с пробелами в образовании.

10.02.2013 Grisha пишет:
Сообщить модератору
Ссылка на это сообщение
 

Если подразумевается встоенная систем JUnit Еesting Аramework, то это эффективное средство для unit testing, не более. Багов ловить вполне помогает, при разработке, причем на начальных стадиях, в основном — что и подчеркнуто в названии...
К какой-либо надежености в реальном времени и защите от сбоев она отношения не имеет, насколько я понимаю



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

Ну а остальное, ИМХО, баг разработчика. Компьютер за него думать не может.

10.02.2013 astoronny пишет:
Сообщить модератору
Ссылка на это сообщение
 

К сожалению, не исключает...
Особенно в сложных распределенных системах да с асинхронными процессами.
В таких джавовских системах устранять memory leak — это просто песня :-(((
Утешает, что в неджавовских может быть еще хуже :-)))
Теоретически, это все должно отлавливаться на стадии integration testing и уже без всякого JUnit, но реальность вносит свои жестокие коррективы.
Так что если тот лиик не шибко уж большой, так многие серверные аппликации годами с таковым живут :-(

10.02.2013 musha пишет:
Сообщить модератору
Ссылка на это сообщение
 

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

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

> Ошибки софтверного архитектора (неучтенный сценарий) или программиста (введена константа 22 вместо 20) как правило приводят именно к систематическим ошибкам. С ними и борются независимыми командами.

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

10.02.2013 _TG_ пишет:
Сообщить модератору
Ссылка на это сообщение
 

> для потребителя разница революционная. при принципиальной неизменности функциональности.

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

> обычно все таки с ними борются путем тестирования каждой строчки кода и 100% контролем входных и выходных значений и 100% обработкой ошибок.

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

> вы можете привести пример области отличной от авиастроения где есть жесткое требование написания прошивки для дсп разными коммандами программистов?

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

> как то в банках например справляются без двух веток кода, при сравнимых цифрах надежности.

Поподробнее, пожалуйста, про надежность банковского ПО. А то у меня обратное впечатление как у пользователя банковских услуг.

10.02.2013 musha пишет:
Сообщить модератору
Ссылка на это сообщение
 

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

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

> Даже в этом случае есть как минимум целый класс ошибок, которым от этого ни жарко, ни холодно.

ну знаете. тут можно договориться что и на альтернативный софт надо выписывать людей из разных стран. а то вдруг они друг с другом поговорят. 100% гарантии не дает ни один способ.

> Поподробнее, пожалуйста, про надежность банковского ПО. А то у меня обратное впечатление как у пользователя банковских услуг.

надежность мейнфреймов производства ибм гоняющих софт на коболе написанный в 80х годах имеет те же самые в минус 7 - 8 - 9. я никогда не слышал чтобы в постоянной эксплуатации каких либо устройств постоянно применялись бы ветки написанные разными людьми одновременно. я не говорю что это не нужно, просто непонятно чем авиатехников не устраивает опыт других индустрий, с гораздо более длинной историей. впрочем все это оффтоп. есть данность, требование органов.

10.02.2013 s_jet пишет:
Сообщить модератору
Ссылка на это сообщение
 

95023 в цветах Interjet:

http://sphotos-h.ak.fbcdn.net/hphotos-ak-prn1/...

http://i.zlowiki.ru/130210_ed87336c.jpg

10.02.2013 _TG_ пишет:
Сообщить модератору
Ссылка на это сообщение
 

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

Ага, пошла демагогия :) Стало быть вопрос закрыт до того момента, как Вы предъявите мне мое слово "революционность'

> 100% гарантии не дает ни один способ.

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

> надежность мейнфреймов производства ибм гоняющих софт на коболе написанный в 80х годах имеет те же самые в минус 7 - 8 - 9

Ключевая фраза "в 80-х годах". Как с тех пор возросли возможности новой техники и сложности кода? Ах, да, чуть не забыл: Вы же отказались признать вопрос связи сложности с надежностью закрытым ;) Так что извините, мне эта дискуссия надоела :)

10.02.2013 musha пишет:
Сообщить модератору
Ссылка на это сообщение
 

> Так что извините, мне эта дискуссия надоела :)

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

10.02.2013 MAX_T пишет:
Сообщить модератору
Ссылка на это сообщение
 

Там в банках нет жесткого RealTime



ошибаетесь. Пример - биржевые сделки.

10.02.2013 musha пишет:
Сообщить модератору
Ссылка на это сообщение
 

кстати вот стандарт на безопасный софт для критических приложений:
http://en.wikipedia.org/wiki/IEC_61508
вот методика тестирования наиболее критичного софта
http://en.wikipedia.org/wiki/Modified_Condition/Decision_Coverage

никакой мистики. есть реал тайм ембеддед операционные системы сертифицированные по 61508.

Ответить в тему:



Авиапорт.Конференции

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