16+
Суббота
18 ноября
Вход |Карта сайта | |Upload |codebook | PARTS

 О смысле всего сущего 0xFF

 Средства и методы разработки

 Мобильная и беспроводная связь

 Блошиный рынок Объявления

caxapa

Микроконтроллеры ARM 

AVR PIC MSP PLD,FPGA,DSP 

Кибернетика Технологии 

Схемы, платы, компоненты 

Средства и методы разработки

 
   Новая тема Правила Регистрация Поиск »» Архив
Вернуться в конференциюТопик полностью
fk0  (10.11.2017 12:44) , в ответ на В статье про блоки управления для метрополитена -> упоминается некая система АРС с частотами 75–375 Гц. Это оно (внутри)? Вопрос - а как эти герцы попадают в локомотив? Некая рельсовая цепь упомянута. А схемотехнику этого чуда можно глянуть? автор: Evgeny_CD
Почитал, пока ехал в метро... Не оценил. Оставляет явное чувство незавершенности, выхвачены и рассмотрены только отдельные аспекты надежности аппаратуры. Более того, напоминает попросту распил. Во-первых ни слова не сказано про программное 
обеспечение. Но это же самое главное. Баг-ориентированная разработка ПО попросту с легкостью умножит на ноль все прочие усилия. Но я не увидел какие меры по разработке ПО приняты. Значит ли это, что как обычно, программистам выдали весьма нечеткое и постоянно меняющееся ТЗ и они со своей колокольни что-то додумали и как-то решили, как это обычно бывает? При этом рассматривались и тестировались только положительные сценарии. И никаких мер по верификации ПО не было вообще? Исходя из собственного опыта я бы предположил, что при серьезной разработке ПО разработка управляющих алгоритмов вообще отделена должна быть от собственно ПО, алгоритмы должны верифицироваться каким-либо образом (на модели, например), потом программисты должны просто закодировать данную им свыше логику без самодеятельности. Потом должны быть какие-то средства проверки уже не алгоритмов, а самого ПО, что оно правильное, соответствует заданию, что оно обладает нужными свойствами. Как в статике, так и в динамике (речь как и о традиционных средствах, использующихся программистами, так и о проверке правильности работы управляющих алгоритмов, про которые выше). Какие-то средства обеспечения обработки сбоев в ПО (обработка ошибок традиционно заметается под коврик, да ее вообще обычно нет!), причем в системе в целом. Что толку, если ПО постоянно сбоит и движение блокируется? Безопасно да. Но работать же невозможно. В статье утверждается, мол, "современные МК часто сбоят", но не вижу средств предпринятых для выявления сбоев, проверки, что вычисления осуществляются правильно (например, какие-то проверочные расчеты), что управляющие алгоритмы реализуются правильно (например, параллельный алгоритм осуществляющий проверку правильности соответствия входных сигналов и управляющих сигналов по заданному набору правил). Из разумного, что я там увидел, это то, что более низкоуровневые компоненты получают возможность реализовать какую-то более упрощенную логику управления (блокировать движение самостоятельно, в обход остальных схем), если последние вдруг не работают правильно. Про железо, особенно касательно помехоустойчивости, по-моему сильно за уши притянуто. Да, многие современные компоненты более чувствительны к электромагнитному излучению. Но что из этого следует? Да ровно ничего. Микропроцессор поэтому и должен помещаться в экран и выходящие наружу цепи должны быть защищены. А в статье делаются выводы, мол элементы 20-летней давности более надежны. Да у них своих особенностей хватает, отсутствующих у современных компонентов. Выводы причем с потолка взятые. Там ж нет ссылок на результаты испытаний, например, вообще ссылок на источники.
[ZX]
 [x][x][x][x][x][x] [x][x][x][x][x][x][x][x]

Тема выделяется по переводу строки или автоматом

 

Имя


Регистрация позволит вам редактировать и перемещать ваши сообщения и прикреплять к ним файлы.
 
Символы: á é ó ú ý « »
Главная | Карта сайта | О проекте | Проекты | Файлообменник | Регистрация | Вебмастер | RSS
Лето 7526 от сотворения мира. При использовании материалов сайта ссылка на caxapу обязательна.
MMI © MMXVII