Обсуждение

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

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

на практике этот "взрыв" ограничен "наличием отсутствия" датчиков :)

Это в программной инженерии отсутствие датчиков. В системной инженерии датчиков обычно более чем достаточно.

это там где одним из механизмов пытаются "впрокрустить" человека с его фактором ?

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

а они точно меряют то, что нужно измерить, а не то, что можно померять ? если в ваших системах где-то идёт "а вот тут приходит сигнал (или подтверждение) от человека" - тогда тушите свет автоматизации

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

значит, вам повезло. Обычно вместо нужного датчика "ось сломалась" ставят датчики "мотор работает", "шестерня крутится" и "ось крутится" и из ответов "да,да,нет" делают вывод :) Ну или большие чорную и красную кнопки для человека и окошко из плексигласа, чтобы посмотрел. а самописцы - сбоку пишут что-то на своей волне ...

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