Yurik

Добрый день, уважаемые. интересное обсуждение, хочется озвучить свои мысли не желчи ради, а для развития мозга и развития общего целого, так сказать, если получится) во-первых респекты обеим сторонам: и тем, кто глубоко понимает алгоритмы каминсов на уровне разработчиков ПО, а также и тем, кто работает более нативно в бине так сказать и имеет широкий опыт в работе с системами управления в целом, не только каминсами. Вообще, думаю, что конечно не так важен инструмент для работы, важен конечный результат работы. под конечным результатом чипа эсуд понимается определенный набор изменений параметров работы авто/двс/эсуд, полученных либо изменением численных значений/конечных состояний калибровок/таблиц (область калибровок), либо модификацией самих алгоритмов программного обеспечения уровня application методом изменения их логики, вообще удаления или маскирования части прошивки с алгоритмами. другие уровни прошивки: загрузка, программно-аппаратная часть, дублирование, защита и т.д. трогаются редко или вообще не трогаются). С технической точки зрения, если конечный результат безопасен для человека/авто/двс.., то какая разница как он получен:calter, inca, canape, winols или еще жестче - дизасм и разбор. Размытые границы здесь конечно в оценке результатов деятельности модификатора. Часто при гибком программном обеспечении, возможность отключения, изменения работы функций закладывается уже в калибровки на уровне разработки и имхо, это хорошо. это конечно проще, если работа ведется с готовым инструментарием производителя, несомненно. за то, это все таки безопаснее, многое инкапсулировано в собственные процессы того же калтерма, ведь человеческий фактор ошибки присутствует везде. между тем в калтере конечно выведены не все настройки алгоритмов, что есть на уровне приложения в прошивке. к примеру, если мы захотим адаптировать эсуд каминс на другом двигателе, то это сделать на уровне калтера будет проблематично. ---------- что касается снятия разъемов, то видится, что выше высказавшиеся специалисты говорят немного о разных вещах. со стороны коллеги Чавойто есть логика в отсеченных выводах ЭБУ - чем проще система, тем она надежнее. конечно в неотключенной электрике отключенных функций могут возникать кз и т.п., что приведет к проблемам работы всей эсуд. понимая колегу Новосиба, скажу, что безопасность работы системы конечно на первом месте и отключать что либо от мозгов нужно, когда уверен, что отключение датчиков/им не повлияет на работу других важных функций системы управления, нарушение в работе которых недопустимо. естественно для такого понимания, желательно иметь документация описывающую алгоритмы досконально и разбираться в этом. в качестве абстрактного примера, попытаюсь двигаться снизу вверх, от малого к большему. например при отключении какого либо датчика физически от системы управления начинает работать самодиагностика эсу по определенному алгоритму. ну это естественно обрыв или вариации в зависимости от типа отключаемого компонента. то есть нужно выключить диагностику данного компонента в ПО. естественно недостаточно выключить только обрыв, необходимо выключать и остальные типы ошибок по данному компоненту, как уровня электрики, так и неправильности, неправдоподобности. обобщить вряд ли смогу на все системы управления в мире). далее, в зависимости от критичности функции отключаемого компонента для других алгоритмов, то есть где он еще используется, если используется, кроме целевых функций, и как используется. допустим, уровень диагностики сигнала отключаемого компонента мы прошли успешно. далее вопрос как система управления замещает данный сигнал в родной- отключаемой функции. итак, поднялись на уровень отключаемой функции: как правило, система замещает сбойный сигнал на значение по дефолту, которое призвано минимизировать возможные опасности для человека/машины. также возможны последствия в виде ограничения характеристик работы, ограничения функциональности работы системы. это так называемая функциональная безопасность. это калибровщик тогда тоже должен обойти или нивелировать исходя из разумного подхода или не делать то есть. при взаимозависимости отключаемой функции с другими, нужен анализ влияния и последствий, затем решение о необходимости затрагивать зависимые функции. этот анализ должен быть проведен для всех функций в идеале, что возможно при наличии хорошего информационного источника. могут быть и частные вещи в виде подсистем дублирования, защиты и тд. с ниим тоже что то надо делать программно, иначе они воздействуют на выходные характеристики объекта управления. буду рад услышать ваше видение, и поправки, коллеги.