Цитата:
Сообщение от nsksky
(Сообщение 750484)
Молчаливым стал, ибо устал я от Вас - в Calterm'е Вы не понимаете от слова совсем, а в открытом формате - bin - сидите и дальше ковыряйте свои биты байты дальше, там их 3 ГБ! Решения свои продавать не собираюсь, а вот то, что Ваши поделки опасны для двигателя, доказать не получается по одной только причине - у Вас авто всегда виновно, а не прошивка....
|
Цитата:
Сообщение от чавойто 161
(Сообщение 750519)
ну во первых если вы себя считаете просто пользователем ПК, то хотя бы элементарно надо отличать гигабайт от мегабайт это если вы про размер дампа процессора MPC5566 который стоит в СМ2220/2150.
По поводу "вашего решения" все давно уяснили уже, да и вы это прямым текстом обозначили. Ну и третье, кто там в чем не понимает, от слова совсем, это соответственно сам персонаж nsksky, в системах CR. Ибо понятий как данные системы работают у него поверхностные и на уровне потребителя-водителя. Ибо в противном случае смог бы хоть как то техническим языком обосновать свои утверждения почему все решения вокруг опасны, для авто а якобы его самое правильное. Ну и как раз утверждения, про то, что у некоторых виновато само авто, яркое тому подтверждение, ибо у большей половины заливальщиков проблем с авто нет, если они не видят кодов DTC в ЭБУ. Про датастрим и его просмотр это не о них, там кучу непонятных значений. Я в отличии от вас в первую очередь диагност и только во вторую калибровщик.
И очень хотелось бы услышать все таки мнение гуру, почему так вредно снимать разьемы физически с отключенных систем? Вот у меня противоположное мнение и всегда его придерживаюсь, в калибровке разных систем как дизелей так и инжекторов, и считаю что если решение полноценное то ни каких подключенных разьемов быть не должно. Есть конечно системы где нет решений полноценных на данный момент, но это не о cummins e4/5. Да и решать задачу можно разными путями и подходами. Так вот не хватает технических аргументаций в ваших утверждениях, что именно по вашему у всех неправильно, а у вас учтено? Можно конечно спрятаться за словами это секретно и индивидуально, но может прокатить на драйве у водителей им чем больше в уши втираешь тем больше они верят. Здесь на техническом форуме не прокатит, выступили с осуждением какого либо продукта (которым сами пользуетесь в работе, по своим же словам) обоснуйте грамотно.
|
Добрый день, уважаемые. интересное обсуждение, хочется озвучить свои мысли не желчи ради, а для развития мозга и развития общего целого, так сказать, если получится) во-первых респекты обеим сторонам: и тем, кто глубоко понимает алгоритмы каминсов на уровне разработчиков ПО, а также и тем, кто работает более нативно в бине так сказать и имеет широкий опыт в работе с системами управления в целом, не только каминсами. Вообще, думаю, что конечно не так важен инструмент для работы, важен конечный результат работы. под конечным результатом чипа эсуд понимается определенный набор изменений параметров работы авто/двс/эсуд, полученных либо изменением численных значений/конечных состояний калибровок/таблиц (область калибровок), либо модификацией самих алгоритмов программного обеспечения уровня application методом изменения их логики, вообще удаления или маскирования части прошивки с алгоритмами. другие уровни прошивки: загрузка, программно-аппаратная часть, дублирование, защита и т.д. трогаются редко или вообще не трогаются). С технической точки зрения, если конечный результат безопасен для человека/авто/двс.., то какая разница как он получен:calter, inca, canape, winols или еще жестче - дизасм и разбор. Размытые границы здесь конечно в оценке результатов деятельности модификатора. Часто при гибком программном обеспечении, возможность отключения, изменения работы функций закладывается уже в калибровки на уровне разработки и имхо, это хорошо. это конечно проще, если работа ведется с готовым инструментарием производителя, несомненно. за то, это все таки безопаснее, многое инкапсулировано в собственные процессы того же калтерма, ведь человеческий фактор ошибки присутствует везде. между тем в калтере конечно выведены не все настройки алгоритмов, что есть на уровне приложения в прошивке. к примеру, если мы захотим адаптировать эсуд каминс на другом двигателе, то это сделать на уровне калтера будет проблематично. ---------- что касается снятия разъемов, то видится, что выше высказавшиеся специалисты говорят немного о разных вещах. со стороны коллеги Чавойто есть логика в отсеченных выводах ЭБУ - чем проще система, тем она надежнее. конечно в неотключенной электрике отключенных функций могут возникать кз и т.п., что приведет к проблемам работы всей эсуд. понимая колегу Новосиба, скажу, что безопасность работы системы конечно на первом месте и отключать что либо от мозгов нужно, когда уверен, что отключение датчиков/им не повлияет на работу других важных функций системы управления, нарушение в работе которых недопустимо. естественно для такого понимания, желательно иметь документация описывающую алгоритмы досконально и разбираться в этом. в качестве абстрактного примера, попытаюсь двигаться снизу вверх, от малого к большему. например при отключении какого либо датчика физически от системы управления начинает работать самодиагностика эсу по определенному алгоритму. ну это естественно обрыв или вариации в зависимости от типа отключаемого компонента. то есть нужно выключить диагностику данного компонента в ПО. естественно недостаточно выключить только обрыв, необходимо выключать и остальные типы ошибок по данному компоненту, как уровня электрики, так и неправильности, неправдоподобности. обобщить вряд ли смогу на все системы управления в мире). далее, в зависимости от критичности функции отключаемого компонента для других алгоритмов, то есть где он еще используется, если используется, кроме целевых функций, и как используется. допустим, уровень диагностики сигнала отключаемого компонента мы прошли успешно. далее вопрос как система управления замещает данный сигнал в родной- отключаемой функции. итак, поднялись на уровень отключаемой функции: как правило, система замещает сбойный сигнал на значение по дефолту, которое призвано минимизировать возможные опасности для человека/машины. также возможны последствия в виде ограничения характеристик работы, ограничения функциональности работы системы. это так называемая функциональная безопасность. это калибровщик тогда тоже должен обойти или нивелировать исходя из разумного подхода или не делать то есть. при взаимозависимости отключаемой функции с другими, нужен анализ влияния и последствий, затем решение о необходимости затрагивать зависимые функции. этот анализ должен быть проведен для всех функций в идеале, что возможно при наличии хорошего информационного источника. могут быть и частные вещи в виде подсистем дублирования, защиты и тд. с ниим тоже что то надо делать программно, иначе они воздействуют на выходные характеристики объекта управления. буду рад услышать ваше видение, и поправки, коллеги. |
