Как проектируют ненастоящие программисты

Никто никаких требований не придумывал, то, что ТЗ может быть выполнено, сомнению не подвергалась.

Как проектируют ненастоящие программисты

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

Как проектируют ненастоящие программисты

20 секунд до столкновения, это очень много. В типовых, давно выпускаемых системах предотвращения столкновений для большегрузов, например, от Bendix, сигнализация начинается с 5 секунд. Но если сделать участником проекта руководство заказчика, то можно установить и полчаса ;)

Как проектируют ненастоящие программисты

Если при расстоянии между объектами 3 метра они совпадают, с целью предотвращения столкновений ближе вы их подпускать не сможете. Вы просто не будете понимать, столкнулись объекты или нет. И вам потребуется запас, т.е. реально, расстояние, на котором вы будете сигнализировать об опасном сближении, у вас будет около 5 метров.

Как проектируют ненастоящие программисты

У STM32 есть отечественные аналоги, от Миландра. Но дороже, раз в 50, даже в гражданском исполнении.

Как проектируют ненастоящие программисты

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

Как проектируют ненастоящие программисты

Знакомая картина. Не у нас, у смежников, у них небольшое предприятие, порядка 10-20 сотрудников. Сначала сделали на винде, потом на линукс, потом соорудили свой какой-то проц без ОС вроде. У них там 5 ведущих программистов сменилось за время разработки. Постоянно вылазят какие-то баги, которые они исправляют за свой счет. Пока образцов было немного, как-то удавалось латать, но когда стало под десяток шасси, начались проблемы с финансированием. Претензии идут постоянно, то здесь то там, командировки дорогие. В отрыве от денег, многое выглядит иначе. Представляется, что можно сделать и так, и эдак, а когда возникает вопрос, на какие шиши, оказывается что никак нельзя.

Как проектируют ненастоящие программисты

Возможно, что и так. Практика, как известно, критерий истины.

Как проектируют ненастоящие программисты

Речь о системе предотвращения столкновений, поэтому, оповещать следует только об опасных сближениях. Можно, конечно, считать все сближения опасными, но это приемлемо только для тех, кто в карьере редко бывает и может себе позволить кратковременное нервное напряжение. Но это только моё видение вопроса, если соберётесь делать свою систему предотвращения столкновений, конечно, реализуете свои идеи :) Здесь во многом вопрос психологии, нужно проводить соцопросы, и их, к слову, проводили, например, американцы, их госконтора NHTSA, вроде так. Есть статистика отношения к системам помощи водителей, в зависимости от возраста, пола, стажа вождения, вида отображения информации и т.д. и т.п. Ведь не всем нравится даже сопровождение звуком указателей поворота. В общем, мне лично представляется, что 3 метра, это недостаточно. У нас были нарекания от заказчиков на этот счет. Хотя авто там было другого вида.

Как проектируют ненастоящие программисты

Подробнее — пищалка на поворотнике всегда адекватно отражает ситуацию — всегда информирует, что поворотник включен. Индикатор близости в режиме предотвращения ДТП даже при идеальной работе отражает ситуацию не всегда адекватно, т.к. не всегда сближение опасно, а он должен предупреждать об опасных сближениях, а не обо всех. Не опасные сближения водитель будет вынужден сам отфильтровывать и игнорировать, а это напрягает. Вдобавок, система, очевидно, будет работать идеально не всегда, и к этому ещё добавятся ложные сообщения о сближениях вообще. Система будет сильно грузить водителя из-за большой вероятности ложных тревог, скажем так.

Как проектируют ненастоящие программисты

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

Как проектируют ненастоящие программисты

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

Как проектируют ненастоящие программисты

Договор на поставку всегда какой-то есть, там оговариваются сроки замены/ремонта по гарантии. Мне интересно было, какие периоды гарантии устанавливают в них заказчики из ЖД или с карьеров. Но если есть отдельный договор на техобслуживание, то пункт о гарантии может наверное, отсутствовать. Договор на техобслуживание заключается каждый год? Неплохо было бы, продать систему, и отвечать за неё только до времени, пока есть запчасти от сторонних производителей.

Как проектируют ненастоящие программисты

Только если вы заказчик. Формально, ТЗ выдаёт заказчик. Откуда он его берет, сам пишет или просит написать исполнителя, неважно.

Как проектируют ненастоящие программисты

Насчёт дефектов, дефект, это несоответствие. А если грузовик свалился, но техника при этом работала строго в соответствии с ТЗ, то это не баг, а фича :) Никто разработчика за такое осудить не сможет.

Как проектируют ненастоящие программисты

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

Как проектируют ненастоящие программисты

Насчёт ТЗ ниже прочитал, понятно :)

Как проектируют ненастоящие программисты

Дороже намного, конечно. Больше 100000 р на грузовик однозначно. Но у системы с локаторами другой функционал.

Как проектируют ненастоящие программисты

Есть пределы ответственности? Отвечаете только в рамках технических возможностей системы? Ну там типа самосвал в карьер свалился, но система по параметрам и не могла это предотвратить, вы не виноваты? Как в ТЗ сформулировано — чтобы техника не сваливалась или точность позиционирования обеспечить? И кто ТЗ составляет, заказчик полностью самостоятельно, или по вашим предложениям?

Как проектируют ненастоящие программисты

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