Ответ на критику ChipTuningPRO А. Бразговского
01.10.2015 г. на сайте «Центра инженерных разработок АРС Адакт» появилась статья А.Бразговского (далее по тексту «А.Б.»), обрушившая массу критических замечаний по поводу работы нашего редактора калибровок. Прочтение вызвало у нас полное недоумение, в первую очередь непрофессионализмом автора и его аргументами, основанными на домыслах и ошибочных убеждениях. Ниже мы рассмотрим несколько пунктов «обвинений» и постараемся дать на них конструктивный ответ. Изложение будет дано в форме цитат (с полным сохранением орфографии и контекстного смысла) с ответами на эти цитаты.
Цитата: Два родственных ЭБУ Siemens EMS3132 и EMS3134. По сути это один и тот-же ЭБУ. Один проц, одна базовая модель, одна и та-же калибровка (под копир в общем-то практически) но почему-то в 3132 СТР это гордо называет "обогащение", а в 3134 это "базовая неравномерность для диагностики пропусков" Ну в принципе одинаково звучит ведь, разве нет? Но в 3132 мы крутим "ускорительный насос", а в 3134 правим алго обнаружения пропусков. По мнению автора это где-то рядом ведь. А что? Все в одной флешке. Но не обольщайтесь! Возможно что это что-то третье... А почему нет?! Никому нет веры, даже самому себе! Да и страшного по мнению автора ничего ведь нет. На 3132 четыре года мы это все крутили (да и сейчас продолжаем крутить) как ускорилку, а вот на 3134 мы это будем "крутить" как "базовую неравномерность для обнаружения пропусков".
Комментарий: Итак, суть первой части заявлений А.Бразговского в том, что ЭСУД Siemens EMS3132 и EMS3134 являются очень близкими родственниками. Выводы такие автор делает на основе трёх вещей:
идентичность процессора, идентичности «базовой модели» (весьма туманное понятие, никто в достоверности не знает, что имеется в виду), «одна и та же калибровка»
(смысл этого пункта также весьма расплывчатый). Оценивать «идентичность» систем управления по типу процессора никак нельзя. Один и тот же тип процессора может
применяться в системе управления двигателем и в посудомоечной машине, однако, это не говорит о том, что эти объекты управления имеют хоть какое-то сходство в логике своей работы и уж, тем более,
в калибровочных данных. Базовая модель? Предположим, что А.Б. имел в виду наименование ЭБУ. Оно действительно отличается одной цифрой, но это совершенно не говорит нам о том,
что системы могут быть похожи. Например, ЭБУ EMS3130 тоже отличается от сравниваемых систем одной цифрой, тем не менее, это совершенно иная ЭСУД с совершенно иными алгоритмами,
калибровками и процессором (раз уж А.Б. ссылается на него, сошлёмся и мы). Ну и пункт третий, про «одну и ту же калибровку». Если имелась в виду идентичность алгоритмов работы систем
и структуры калибровочных данных, то это тоже не так по причине того, что EMS3132 работает с механическим приводом дросселя, а EMS3134 с электронным.
Последнее подразумевает внесение в систему управления большого количества новых алгоритмов для управления электронным дросселем.
Таким образом, «идентичность» систем — это фантазии А.Б., основанные на трёх заблуждениях. Да, системы немного похожи, потому что проектировались
в одном КБ, но имеют и существенные различия.
Перейдём теперь непосредственно к обвинению, озвученному во второй части цитаты. Сразу скажу, что оно обоснованное. В модуле EMS3132 действительно имеется серьёзная ошибка
в интерпретации упомянутой таблицы. Это обидное недоразумение, для нас весьма неприятное. Радует одно: подобные ситуации — плод случайных ошибок и исключение из правил, причём, вероятность
появления подобных ошибок в новых модулях ничтожно мала, так как несколько лет назад мы кардинально изменили всю цепочку создания модуля, от усовершенствования методов исследования ПО до
переноса результатов исследований в карты калибровок.
Вернёмся к злополучной таблице: на самом деле это неравномерность момента для диагностики пропусков, как это и описано в новом модуле EMS3134. Обратите внимание, что при создании модуля
мы не опирались на прошлые исследования EMS3132, а произвели всю работу «с нуля». Если бы мы хотели ввести наших клиентов в заблуждение или если бы эти системы были действительно так похожи (как
утверждает г-н Бразговский), то эта ошибка так бы и перекочевала в новый модуль. Кстати, в модулях EMS3132 «альтернативных» редакторов почему-то эта таблица названа ошибочно, в точности
как у нас, что недвусмысленно указывает на бессовестный плагиат.
Любопытный момент: ни «нормальный редактор» (под которым А.Б. имеет в виду визуализатор WinOLS), ни
опыт и знания, ни что-то другое не помогли г-ну Бразговскому узнать истинное назначение этой таблицы. До тех пор, пока мы не выпустили модуль EMS3134, в котором алгоритм обнаружения
пропусков очень похож на EMS3132, А.Б. так и продолжал ошибочно считать эту таблицу «обогащением», то есть именно так, как интерпретировано в ненавистном ему нашем редакторе.
Возникает вопрос: а если редактор так плох, зачем вы им пользуетесь? Ведь есть «нормальный редактор», где по внешнему виду можно угадать (!) назначение всех таблиц!
Видимо, с угадыванием не всё так гладко:)
Настало время заострить внимание на методе идентификации таблиц, которым пользуется А.Б.. Суть метода в том, что визуализируя некоторые структурированные данные при помощи WinOLS,
можно угадать назначение таблицы. Действительно, некоторые таблицы имеют весьма характерную форму, например, 3D-карты углов опережения зажигания хорошо идентифицируются и спутать их
с чем-то другим сложно. Казалось бы, это путь к успеху, но не тут то было: даже если вы «опознали» таблицу, невозможно без исследования программы управления понять её истинное назначение,
а также невозможно выяснить, используется ли эта таблица вообще. К примеру, в ПО MELCO есть много таблиц, которые внешне очень похожи на калибровки системы MIVEC, однако, к этим таблицам
нет обращения из программы, они «мёртвые».
Вот простой пример, иллюстрирующий сказанное:
На картинке визуализирована область калибровок прошивки для Mitsubishi Lancer X. Обратите внимание на упорядоченные повторяющиеся структуры, если их визуализировать в 3D, то выглядят они так:
Красиво, не правда ли? И очень похоже на фазы ГРМ для выпускного и впускного вала. Тем не менее, это «мёртвые» таблицы, они не используются в программе. А настоящие фазы — чуть дальше, это участки, выделенные красным. Конечно, угадать это невозможно, для получения подобной информации нужно дизассемблировать программу управления и понять, как она работает, чем мы и занимаемся. Таким образом, утверждение Бразговского о тождественности таблиц, основанное на их внешнем виде не выдерживает критики, это из рода «угадал — не угадал».
Цитата: Bosch M7.9.7(+).
Например "Базовый УОЗ". Базовый УОЗ1 и Базовый УОЗ2. Это вообще как? Когда работает 1, а когда 2. А может тот, что 1, на самом деле 2?
Кстати у ВАЗоТаза они одинаковые и именно в этом на 75% кроется не желание авто работать без ДФ. Почему? А вот почему.
У БОШа не бывает "Базовый УОЗ 1" и "Базовый УОЗ 2". Один из них является Аварийным углом, а именно звучит примерно так "Базовый УОЗ при аварии ДФ".
И дальше все становится понятным. Ибо ну не могут на нормальном ПО эти 2 угла быть одинаковые, что и показывает практика при разборе аналогичного ПО на нормальных авто.
Комментарий: Ох, мне бы такую уверенность в том, что «У БОШа не бывает» и что «дальше все становится понятным»...
Впрочем, остановимся подробнее на этом моменте. Каждый уважающий себя калибровщик систем Bosch наверняка читал все доступные документы под общим названием «Funktionsrahmen».
Кто не понял по-немецки, не торопитесь заглядывать в словарь, ключевое слово здесь — «уважающий». Так вот, г-н Бразговский не читал, если написал такое.
Подобные документы содержат оригинальное полное описание алгоритмов работы той или иной системы управления двигателем, описание калибровок и рекомендации по калибровке.
Разумеется, это ДСП, но в Германии тоже люди... иными словами, некоторые документы стали доступны, один их них, даже на английском, что редкость, давным давно лежит в файловом архиве
сайта chiptuner.ru. Это описание ЭСУД Bosch ME7.3, которая является базой для многих других подобных систем, включая рассматриваемую нами Bosch M7.9.7.
Итак, речь про таблицы базовых УОЗ, Bosch их называет KFZW. Заглянем в первоисточник:
Переводить? Для тех, кто в танке:
KFZW — карта угла опережения зажигания
KFZW2 — карта угла опережения зажигания, вариант 2
Что не так в CTPro? Калибровщику стыдно не знать такие вещи, это «библия» тюнинга систем Bosch.
Если почитать документ более подробно, то можно выяснить, что «вариант 2» — это версия таблицы УОЗ для комплектации системой регулируемых фаз ГРМ:
Здесь описан расчет базового УОЗ в зависимости от комплектации системой регулировки фаз. Системная константа SY_NWS определяет тип системы (0 — нет регулировки фаз; 1 и 2 — разные варианты регуляторов). Посмотрев на блок-схему видно, что при отсутствии системы регулировки фаз таблица KFZW2 не используется. Возникает вопрос, зачем она отображается в CTPro? А по той простой причине, чтобы видеть как можно больше всего, что изменено в прошивке. Так сложилось исторически, что эту неиспользуемую таблицу тоже изменяют и многим не нравилось то, что CTPro не видела этих изменений. Для любознательных сообщу интересную техническую особенность: когда проект Bosch (прошивка) собирается, то некоторые неактивные куски кода не попадают в проект, при этом записи о калибровках будут присутствовать в выходном файле A2L. Так что даже если у нас имеется инженерная карта (A2L), то некоторые калибровки, описанные в ней, могут не использоваться и «крутить» их бессмысленно. В системе Bosch M7.9.7 ВАЗ эффект оптимизации приводит к тому, что таблица KFZW2 (Базовый УОЗ2) присутствует в области калибровок, но к ней нет обращений из программы:
На скриншоте показана функция вычисления базового УОЗ. Адрес таблицы KFZW выделен жёлтым. Функция чтения из 3D-таблицы помещает считанное значение в переменную UOZTab, после чего
прибавляются коррекции УОЗ по EGR, ALFA и детонации. Результат помещается в переменную UOZWithCor. Если поискать по всему коду адрес таблицы KFZW2, то вы её не найдёте.
Желающие могут попробовать сделать это самостоятельно.
Таким образом, фантазии г-на Бразговского показали его некомпетентность, как специалиста в области чип-тюнинга и отсутствие специальных знаний.
Пренебрежительное «ВАЗоТаз» и высокомерное сравнение оных с «нормальными авто» по сути есть оскорбление для той части людей (причём, далеко не худшей её части), которые ездят на таких автомобилях.
К сожалению, в нашей стране подобная ситуация не редкость, в последнее время меня не покидает ощущение, что 95% людей у нас занимаются не своим делом...
Цитата: И так мы продолжвем говорить об УОЗ1 и УОЗ2. Вообще придумано автором редактора прикольно. Вот только на практике для тюнера, заплатившего за модуль 10 килорублей, это не смешно порой. Так вот Siemens Sim43(47) Открываем и что мы видим? Опять Базовый УОЗ 1 и Базовый УОЗ 2. Но на сименсе ведь тож не дураки сидят и таблицы эти называются по другому, а следовательно и работают по другому, а не так как их видит автор редактора. А называются они правильно "Базовый УОЗ" и "Минимальный реализуемый УОЗ". Согласитесь, разница есть. А потом незадачливый тюнер "покрутив" эти "картишки" в редакторе оном не может понять почему стало хуже только....
Комментарий: что-же такого придумано автором прикольного? Это старый модуль и уровень исследования программного кода был существенно ниже, чем сейчас, это факт.
Тем не менее, в названиях этих калибровок нет ошибок, это действительно рабочие таблицы УОЗ. Один и два. Без конкретики, потому что, если не знаешь, лучше молчи
(а то получится что-то вроде самоуверенных и не имеющих отношения к действительности утверждений А.Б. в предыдущем пункте).
Попробуем разобраться, что же такое УОЗ 1 и УОЗ 2 в данном случае. Начнём с того, что г-н Бразговский сильно поторопился с угадыванием назначения второй таблицы, назвав её
минимальным реализуемым УОЗ. Термин, кстати, придумал ваш покорный слуга, а кое-кто его позаимствовал. Даже не заглядывая в код ясно, что эта таблица не может служить в качестве
минимального УОЗ, давайте посмотрим на её значения:
Значения «за +30» в зоне средних оборотов и нагрузок как бы намекают... на то, что А.Б. опять не угадал. Для примера минимальный УОЗ в системе Bosch ME17:
В той же режимной области минус 20, однако.
С г-ном Бразговским всё ясно, попробуем уточнить назначение этих таблиц, для этого придётся снова заглянуть в код:
Здесь видно, что вычисляется дельта между значениями первого и второго УОЗ. А дальше эта дельта используется в некой таблице, которая адресуется структурой #stru_A0AE4, которая есть не что иное, как таблица эффективности:
Адрес таблицы вычисляется так: 25h * 4000h + 870h = 94870h (4000h — это размер сегмента в модели памяти данного процессора), в переводе на адресное пространство файла даёт значение 14870h.
Да, это именно она, таблица эффективности, желающие могут проверить её адрес в прошивке CA669012. А что такое дельта УОЗ для эффективности? Это разница между оптимальным УОЗ и рабочим.
Следовательно, одна из перечисленных таблиц является рабочим углом опережения зажигания, а другая — УОЗ-ом для моментной модели, а никак не «минимальным реализуемым УОЗ».
«На сименсе ведь тож не дураки сидят» — сказал А.Б.. Верно, не поспоришь... дураки, они в другом месте...
Цитата: Siemens Sim28 (29) Маска ошибок. Если ошибку удаляем, а она не удаляется, то не спеши винить редактор, а читай всплывающие подсказки. иными словами если Вы выключили в редакторе какую-то ошибку, но ошибка продолжает гореть, то проблема не в редакторе, а в кривых программистах Сименса. А может просто не работает "алгоритм автоматического построения путем анализа кода прошивки"? Видишь суслика? Нет! А он там есть! Например для Siemens Simtec 76 даже патч по удалению ошибки нарисовали и выложили на сайте. А чего, зачем редактор учить правильно строить маску.
Комментарий: г-н Бразговский снова заблуждается, а всё потому, что использует методы гадания, а не научный подход. Построение маски у нас действительно автоматическое. Вот, к примеру, скриншот работы утилиты, которая строит маску DTC для SIMK43:
Утилита на входе получает бинарный файл прошивки, анализирует программный код, ищет функции, отвечающие за выставление DTC, определяет адреса для маски.
Делает она это беспристрастно и ей всё равно, какой номер у кода DTC. Внимательный пользователь нашего ПО мог заметить, что во многих системах Siemens в маске отсутствуют «самые интересные»
пункты, а именно коды для деактивации ошибок по нейтрализатору и лямбда-зондам. Следуя логике, можно предположить два варианта: либо разработчик специально скрывает «интересные»
калибровки с какой-то целью, либо там действительно этих кодов нет. Вариант первый можно сразу отмести, потому что, во-первых, нам нет смысла скрывать калибровки от пользователей,
так как это ухудшает привлекательность нашего ПО и, самое важное, обман рано или поздно вскроется и репутация будет подпорчена. Во-вторых, как уже сказано выше, маску строит программа,
она беспристрастна и найдёт в софте всё, что только сможет. Вариант 2 кажется более правдоподобным, особенно в свете того, что в Европе ведут нешуточную борьбу с понижением норм токсичности.
В Германии, к примеру, это уголовное преступление. Итак, разработчики Continental (бывший Siemens) действительно предпринимают ряд мер для того, чтобы усложнить отключение второй лямбды и
контроля нейтрализатора и сейчас я вам это докажу. Возьмём софт Siemens SIM28, на который ссылается наш «обвинитель», А.Бразговский.
Внутри программы управления каждый DTC описан довольно сложными структурами данных, которые перечисляются друг за другом в виде таблицы. Одна структура описывает несколько связанных кодов,
например, коды для диагностики датчика температуры воздуха P0110, P0112, P0113 описаны в одной структуре. Мы не будем рассматривать, как именно выбирается код из группы связанных кодов,
это сложно и неинтересно. Вместо этого, «пройдёмся» по коду, поищем «неинтересные» (к примеру, P0110, P0112, P0113 — контроль цепи датчика температуры воздуха) и «интересные» (P0420 — Низкая эффективность нейтрализатора) и
посмотрим, что же придумали разработчики и, самое главное, в чём заблуждается г-н Бразговский.
На скриншоте вы видите две структуры данных,
описывающих номера DTC выбранных нами для сравнения групп неисправностей:
Теперь найдём в коде места, которые имеют ссылки на эти две структуры, как мы видим на них ссылается уже другая структура данных. Сложно? Да. Но вместе мы разберёмся.
Обратите внимание на цифры, выделенные красными прямоугольниками, это порядковый номер группы DTC в общем списке всех возможных типов неисправностей, которые существуют в программе. Теперь нам осталось найти функцию, отвечающую за активацию неисправностей. Мы сделали это давно, поэтому, сразу покажем вам результат: таких функций оказалось две и вызываются они после проверки условий возникновения неисправности. Например, для одной из выбранных нами группы DTC (P0110, P0112, P0113), функция «выставления ошибки» должна вызываться после проверки значения АЦП датчика температуры воздуха. Если напряжение меньше или больше определённых порогов, то должна выставиться ошибка. Это стандартная логика контроля любого канала АЦП, вы все её знаете. Вот место, где вызывается нужная нам функция SetDTC:
Перед вызовом функции в регистры R12, R13, R14 и R15 загружаются аргументы функции:
R12 — порядковый номер группы в списке структур
R13 — параметр, конкретизирующий какой именно код выставить (для каждого номера возможны до 6 разных кодов, в нашем примере их три: P0110, P0112, P0113)
R14 — адрес маски в области калибровок
R15 — адрес дополнительного параметра для выставления ошибки (этот параметр нам сейчас не интересен)
Обратите внимание на номер 33h. Он соответствует номеру для группы кодов P0110/P0112/P0113, то есть это именно то место в программе, где производится проверка каналов АЦП ДТВ, в чём
нетрудно убедиться, поднявшись чуть выше:
Здесь мы видим проверку значения канала АЦП ДТВ на попадание в диапазоны, заданные двумя константами, что подтверждает правильность наших рассуждений.
А теперь мы подошли к самому интересному: найдём вызов функции активации DTC с номером 6Eh. Чуть выше мы определили, что этот номер соответствует кодам P0420 — Низкая эффективность работы нейтрализатора.
Как можно заметить, для номера 6Eh вызывается немного другая функция, которую мы назвали SetDTC_Unmask. Как и в предыдущем примере, в эту функцию тоже передаются аргументы:
R12 — номер группы в списке
R13 — параметр, конкретизирующий какой именно код выставить (в структуре для каждого номера возможны до 6 разных кодов)
R14 — константа 1 (это не калибровка, а жёстко заданное значение в программе)
Здесь нет адреса маски, поэтому становится ясно, что для DTC P0420 НЕ ПРЕДУСМОТРЕНО маски в области калибровок, что и требовалось доказать!
Напоследок давайте найдём вызов функции активации DTC для ещё каких-нибудь «интересных» кодов, например, для P0170/P0171/P0172
Снова тот же вызов без маски. О чём это нам говорит? О двух вещах: во-первых, г-н Бразговский попытался обмануть всех вас, предъявив необоснованные обвинения,
не подкреплённые никакими научными аргументами. Во-вторых, разработчики Siemens действительно ведут борьбу с понижением норм токсичности.
Напоследок, ликбез специально для г-на Бразговского про патч для SIMTEC: патч изменяет не калибровки, а модифицирует код (стыдно не понимать разницу между калибровкой и модификацией кода).
И сделан этот патч именно по той причине, что при помощи калибровок добиться желаемого невозможно, маски-то нет! В коде просто «вырезаются» вызовы некоторых функций активации DTC,
чтобы система не смогла выставить определённые коды, для которых не предусмотрено маски.
Заключение
Анализ некомпетентности А.Бразговского можно продолжать и дальше, но, есть пара причин, по которым мы не станем этого делать: 1. у нас не так много свободного времени; 2. анализ некоторых моментов требует слишком глубокого погружения в программный код, в котором большинство читателей разобраться не смогут. Всё-же реверс-инжиниринг — очень сложное и трудоёмкое занятие, в отличие от методов угадывания А.Б., рассмотренных в начале нашей статьи. Именно по причине высокой сложности анализа на разработку модуля у нас уходит от нескольких месяцев до года. По этому поводу процитируем А.Б. ещё раз:
Цитата: Все новые модули, на самом деле выходят на старые авто, которые давно уже "окучили" с помощью других редакторов и сняли там все сливки.
Вот здесь я готов подписаться под каждым словом: г-н Бразговский именно этим и занимается: «окучивает» горе-тюнеров своими прошивками, созданными наугад в WinOLS, и «снимает все сливки».
А. Михеенков, разработчик ChipTuningPRO.
