Здесь мы рассмотрим упрощенный подход к разработке программного диагностического обеспечения. Разработка программ диагностического обеспечения сложных объектов на современных языках программирования приведены в работах [5, 17].
Первой задачей при разработке диагностического обеспечения является выбор микроЭВМ, пригодной для проектирования системы диагностирования и управления машиной. Поскольку выбор микроЭВМ определяет характеристики системы, необходим тщательный анализ схем управления, выполненных на базе той или иной микроЭВМ, и на его основе выбор оптимального варианта.
Одноразрядные микроЭВМ — это весьма специфичные устройства, которые совершенно не годятся для численных операций и используются для логической обработки и выполнения функций таймера. Однако для решения данных задач их с большой эффективностью можно использовать в автомобильной аппаратуре.
Наибольшее распространение в автомобильной электронике получили 4- и 8-разрядные микроЭВМ. Если сравнить эти два класса, то следует отметить, что 4-разрядные микроЭВМ обладают явным преимуществом при выполнении логических операций, для чего они оснащены большим набором команд.
Программы для диагностики АВТОМОБИЛЯ. Кто лучше читает ошибки через OBD2 и Андроид? Часть 1.
Восьмиразрядные микроЭВМ уступают им по количеству команд логической обработки, и эффективность их в этом смысле ниже. Однако, что касается арифметических операций, то здесь ситуация меняется на противоположную, поскольку набор команд в 4-разрядных микроЭВМ для этой цели недостаточен. Кроме того, по точности вычислений они в 16 раз уступают 8-разрядным микроЭВМ. Поэтому в системах, выполняющих с высокой скоростью высокоточные вычисления, следует применять 8-разрядные микроЭВМ [69].
Величина потребляемого тока современных микроЭВМ составляет около 10 мА, что считается вполне приемлемым при остановке двигателя.
После выбора микроЭВМ на основании предварительного проектирования схемы управления составляется подробное техническое задание для разработки программы. Существуют различные методики разработки программ. На рис. 10.2 показана наиболее распространенная блок-схема последовательности разработки программы.
Сначала составляется общая блок-схема, описывающая работу системы управления, а также синхронизацию и последовательность выполнения ее операций. Затем для каждой операции составляется подробная частная блок-схема, с помощью которой подтверждается ее соответствие техническому заданию и отсутствие ошибок в последовательности работы системы. Далее в соответствии с блок-схемой, обычно на языке ассемблера, составляется программа. Трансляция программы с языка программирования на машинный язык осуществляется другой высокопроизводительной большой ЭВМ, то есть главный компьютер транслирует программу целевого компьютера, написанную на языке программирования, в машинные слова.
Составить программу, соответствующую техническому заданию, редко когда удается сразу. Обычно она содержит много синтаксических и логических ошибок. Ошибки, касающиеся языка, например синтаксические ошибки, обнару
Не могу написать программу! Что делать! Как начать писать код!
Рис. 10.2. Блок-схема процесса разработки программы
живаются ассемблером, поэтому их можно увидеть в выходном сообщении главного компьютера об ошибках.
Логические ошибки обнаруживаются при моделировании выполнения программы и отладки ее на реальной машине. При обнаружении ошибки осуществляется коррекция программы и повторное ассемблирование (трансляция программы с помощью ассемблера).
Коррекция программы обычно производится главным компьютером, выполняющим ее ассемблирование. В процессе коррекции программы часто возникает необходимость ввести какие-то дополнительные команды, удалить ненужные команды или произвести их замену. Для этого используется специальная программа, называемая редактором.
После коррекции программы и повторного ассемблирования проводится моделирование. На этом этапе программа фактически выполняется разрабатываемыми аппаратными средствами в целях подтверждения нормальной работоспособности системы.
Поскольку и на этом этапе довольно сложно обнаружить программные ошибки, то на аппаратуре обеспечения разработки осуществляется отладка программы. В процессе отладки выполнение программы можно остановить на произвольном шаге, вывести на экран текущее содержимое регистров ЦП и ОЗУ и внести соответствующие изменения. Кроме этого, существует функция трассировки, которая позволяет отслеживать выполнение программы. К средствам обеспечения разработки программ относятся автономный оценочный комплекс и виртуальные вычислительные машины, подключаемые к аппаратуре обеспечения разработки микроЭВМ. Если при моделировании не удается создать условия, идентичные реальным, тогда отладка программы производится на реальной машине.
Для отладки на реальном автомобиле объектную программу после ассемблирования необходимо записать в программируемое ПЗУ (ППЗУ). Используемое для записи устройство называется программатором ППЗУ. Большинство серийно выпускаемых однокристальных микроЭВМ содержит встроенное стираемое программируемое ПЗУ (СППЗУ) или внешнее СППЗУ, которое устанавливается в штекер на корпусе микроЭВМ. Таким образом, на заключительном этапе контроля программы осуществляется на реальном автомобиле, и здесь необходимо крайне тщательно проверить и оценить программу.
Если результаты отладки на реальном автомобиле соответствуют спецификации, процесс отладки считается завершенным и выдается заказ на изготовление «зашитых» программ серийного производства.
Источник: studref.com
Prolog — Экспертная система диагностики болезней
Для каждого симптома будет храниться название и вероятность. Для симптомов, которые не являются характерными для заболевания будет установлена вероятность, равная нулю. Также, к симптомам отнесена температура, задаваемая диапазоном величин. В базе данных будут храниться ответы пользователя (есть/нет) и значение для температуры. Теперь можно описать содержимое базы данных:
CLAUSES % fact(t(38.6)). % такие записи использовались для тестирования sickness(«kor», [t(38, 40, 1), simptom(«suhoi_kashel», 1), simptom(«nasmork», 1), simptom(«chihanie», 1), simptom(«golovnaya_bol», 1), simptom(«otek_vek», 1), simptom(«sip», 1), simptom(«lihoradka», 0.1), simptom(«mokrii_kashel», 0) ]). sickness(«prostuda», [t(37, 42, 1), simptom(«nasmork», 1), simptom(«zalozhennost_nosa», 1), simptom(«chihanie», 1), simptom(«bol_mishc», 0.1), simptom(«snizhenie_obonyaniya», 0.1), simptom(«mokrii_kashel», 0.3), simptom(«hripota», 0.2), simptom(«lihoradka», 0.05) ]). sickness(«koronavirus», [t(37, 42, 1), simptom(«suhoi_kashel», 1), simptom(«snizhenie_obonyaniya», 1), simptom(«bol_mishc», 0.5), simptom(«zalozhennost_nosa», 0.5), simptom(«sip», 0.2), simptom(«lihoradka», 0.1), simptom(«bol_gorla», 0), simptom(«uvelichenie_limfouzlov», 0) ]). sickness(«vetryanka», [t(37, 42, 1), simptom(«rvota», 1), simptom(«sip», 1), simptom(«lihoradka», 1) ]). sickness(«sifilis», [t(36.5, 36.7, 1), simptom(«shakr», 1), simptom(«uvelichenie_limfouzlov», 0.5), simptom(«lihoradka», 0.5), simptom(«bol_gorla», 0.25) ]).
- выводит пользователю потенциальные белезни (вероятность которых больше нуля);
- если этих болезней больше одной — то:
- выбирает первый попашийся симптом, пока что не участвовавший в опросе;
- задает вопрос, добавляет результат в БД;
- переходит к новому шагу.
Вывод подходящих болезней
Чтобы получить все подходящие болезни потребуется предикат, проверяющий подходит ли симптом болезни к тем данным что успел ввести пользователь:
check_simptom(simptom(Name, Chance), SimChance):- Chance > 0, fact(simptom(Name, yes)), !, SimChance = Chance; Chance = 0, fact(simptom(Name, no)), !, SimChance = 1; NOT(fact(simptom(Name, _))), SimChance = 1, !. check_simptom(t(Min, Max, Chance), SimChance):- Chance > 0, fact(t(Value)), Value >= Min, Value Max, !, SimChance = 1; NOT(fact(t(_))), !, SimChance = 1.
Тут учитывается, что если шанс симптома не навен нулю — то пользователь должен подвердить у себя такой симптом, а если веростяность симптома равна нулю — то пользователь должен отвергнуть симптом. В обоих случах правило завершится успешно если симптом еще не должен быть опршен (не успели спросить). Написано два правила, так как симптомы бывают двух типов — при проверке температуры проверяется принадлежность диапазону.
Имея такой предикат можно написать предикат, принимающий на вход список симптомов и возаращающий их вероятность (исходя из ответов пользователя):
calc_chance([], 1.0):-!. calc_chance([Simptom|Tail], Chance):- check_simptom(Simptom, SimChance), !, calc_chance(Tail, TailChance), Chance = SimChance*TailChance. calc_chance([Simptom|Tail], Chance):- check_simptom(Simptom, SimChance), !, calc_chance(Tail, TailChance), Chance = SimChance*TailChance. calc_chance(_, 0.0).
Чтобы перебрать все подходящие болезни — остается просто перебрать болезни, для каждой из них вызвать этот предикат и проверить что шанс больше нуля:
proper_sickness(Name, Chance):- sickness(Name, Simptoms), calc_chance(Simptoms, Chance), Chance > 0.
Выбор симптома для опроса
Теперь надо выбрать не исопльзованный симптом, характерный для подходящих болезней. Для этого с помощью proper_sikness перебираются подходящие болезни, дальше из БД выбираются их симптомы, с помощью member эти симптомы перебираются по порядку, предикат is_not_used проверят что симптом раньше не исопльзовался, предикат name вернет его имя, подходящее для задания вопроса:
unused_simptom(SimptomName):- proper_sickness(Sikness, _), sickness(Sikness, Simptoms), member(Simptom, Simptoms), is_not_used(Simptom), name(Simptom, SimptomName), !. is_not_used(t(_, _, _)):- NOT(fact(t(_))). is_not_used(simptom(Name, _)):- NOT(fact(simptom(Name, _))). name(t(_, _, _), «temperatura»):-!. name(simptom(Name, _), Name):-!.
Предикат member можно взять там.
Опрос
При проведении опроса на хвод будет получено имя симптома, из предыдущего фрагмента кода следуюет, что если это температура — надо спросить число (значение температуры), а если это имя любого другого симптома — то ответом должно быть да или нет. Для ввода значений да/нет написана вспомогательная функция:
read_yes_no(Answer):- write(«yes or no? : «), readln(String), string_to_yes_no(String, Answer), !. read_yes_no(Answer):- write(«wrong answer»), nl, read_yes_no(Answer). make_question(«temperatura»):- write(«vasha temperatura: «), readreal(T), assert(fact(t(T))), !. make_question(Name):- write(«u vas est «), write(Name), read_yes_no(Answer), assert(fact(simptom(Name, Answer))).
Видно, что предикат make_question после ввода симптома выполнят запись результата в базу. между запусками программы, базу данных надо очищать — по крайней мере, при запуске внутри интрерпретатора она не очищается сама:
clear:- retract(fact(_)), !, clear; !.
Консультация
consultation:- NOT(proper_sickness(_, _)), write(«i cant help you. «), nl, !. consultation:- findall(Name, proper_sickness(Name, _), Names), Names = [_], proper_sickness(Name, Chance), Percent = Chance*100, write(«your sikness is «), write(Name), write(» with «), write(Percent), write(«%»), nl, !. consultation:- proper_sickness(Name, Chance), Percent = Chance*100, write(Name), write(» with «), write(Percent), write(«%»), nl, fail. consultation:- unused_simptom(Name), make_question(Name), consultation.
Предикат, выполняющий консультацию првоеряет если ли хоть одна болезнь, подходящая под симптомы пользователя:
- если таких нет — выводится сообщение, что помочь не можем;
- если такая одна — она выводится на экран;
- если таких несколько — выбирается симптом и задается дополнительный вопрос.
Результаты:
Запустим программу, попробуем пользоваться системой:
Выше приведен процесс определения заболевания пользователя, но не всегда все так здорово, например, если ввести в эту систему температуру 36.6 — то программа скажет, что у вас сифилис, так как есть всего одна болезнь в базе с такой температурой. Система вообще не рассматривает вариант что у человека нет температуры (не зря же он к врачу обратился?). База симптомов очень маленькая. Не рассматривается вариант, что у человека может быть одновременно несколько болезней. И так далее.
Источник: pro-prof.com
Чиптюнинг часть3: написание прошивки
Собственно из-за отсутствия времени решил пока написать про написание прошивки в сжатом виде. Позже когда со временим будет попроще напишу развернутый материал. А на первых парах сегодняшнего материала хватит для понимания что такое написания прошивки.
Все описанное в данной статье делается на ваш страх и риск. Ответственности за поврежденные вами ДВС и понесенные вами убытки не несу.
Начнем с того что прежде чем писать прошивку нам надо иметь:
1) Средства для проведения диагностики автомобиля. Кабеля Consult и диагностического ПО вполне достаточно.
2) ECU с возможностью их перепрошивки.
3) ПО для изменения прошивки ECU. (Я буду использовать Nistune, для моих нужд его триал версии вполне достаточно.)
4) Программатор чипов.
5) Двигатель в идеальном или близком к идеалу состояние.
Остановимся подробнее на состояние двигателя. Т.к. неисправный двигатель может «развалиться» или в лучшем случае свести к минимуму наши труды.
Что требуется от двигателя перед началом тюнинга:
1) Отсутствие кодов ошибок.
2) Свежий воздушный фильтр и исправный MAF.
3) Исправный и правильно настроенный TPS(ДПДЗ)
4) Бензонасос и топливный фильтр — новые или в идеальном состояние. Исправные и чистые форсунки.
5) Правильно выставленное зажигание по стробоскопу. Как правило для Nissan Это 15 градусов (реже 20).
6) Новые или в хорошем состояние свечи зажигания. Для турбомоторов Nisssan я бы рекомендовал свечи производства NGK с зазором 0,6мм
Так же не стоит при тюнинге расчитывать на чудо. К примеру если мы имеем полный сток SR20DET, то по MAF-у мы упираемся в потолок равный 290 лс, а по форсункам в 280. И превышение максимально возможных параметров для форсунок опасно для двигателя смертью.
И написание каждой прошивки свыше 280 лс рассчитывается индивидуально под приобретенные спеки снимающие потолок в 280 л.с.
Так даже для потолка стока в 280 л.с. я бы рекомендовал поставить бензонасос 255 л/ч.
Далее как выглядит написание прошивки в nistune. Собственно писать я её буду под сток двигатель с бустконтроллером, прямоток и нулевиком.
При запуске Nistune с начала выбираем модель под которую будет писаться прошивка. Это очень важный момент т.к. разные ECU имеют разные адресные карты и с «не родным» адресным файлом, ваша машина в лучшем случае просто не заведется.
Далее там появиться меня и ищем в нем свою платформу и двигатель. После выбора так же надо будет выбрать прошивку нашего двигателя.
После того как у нас откроется прошика мы сможем её редактировать. Прошивку тоже желательно выбирать согласно модели своего ECU.
Первым делом я направися во вкладку Limits. Она отвечает за отсечки по TPS, оборотам, скорости.
Изменение параметров не вызывает трудности. После клика мыши открывается не большое меню с бегунком которым и производится регулирование.
Soft Rev limit 1 — отвечает у нас за отсечку по оборотам когда дроссель полностью не открыт.
Hard Rev limit 1 — отвечает у нас за отсечку по оборотам когда дроссель полностью открыт. Не рекомендую эту отсечку трогать со стоковыми валами т.к. сток валы примерно при 7500 тысячах начинают активно деградировать.
Safety Rev limit — отвечает за отсечку оборотов при полностью закрытом дросселе.
Safety TP limit — отвечает за отсечку по допустимому открытию дросселя.
Speed limit 1 — отвечает за отсечку по скорости при полностью открытом дросселе.
Speed limit 2 — отвечает за отсечку по скорости когда дроссель полностью не открыт.
Я трогал только отсечку по скорости, поставил оба параметра в 250 км/ч.
Так же если есть необходимость можно изменить карту MAF и К константу при замене форсунок.
В нистюн это все автоматизированно. Если будете работать с другой программой константу К придется считать в ручную. Формула расчета замены форсунок не сложна (производительность старых форсунок / производительность новых форсунок) * константа старых форсунок = константа новых форсунок.
Т.к. у нас прямоток и нулевик, то нам нужно убрать в ECU ограничения что бы наши улучшения не свелись к нулю (да, да прямоток и нулевик без перепрошивки не дают некого прироста мощности, одни звуковые изменения)
Находим вкладку Limit tables
Min TPulse width — этот параметр отвечает за длительность впрыска топлива что бы двигатель не заглох когда вы после активного педалирования бросаете газ. Его можно не трогать.
Min TPulse width — этот параметр отвечает за максимальное время впрыска топлива. Это и есть один из ограничителей наших спеков типа нулевика и прямотока. Т.к. двигатель даже получая больше воздуха, в цилиндры не нальет топлива больше чем положено и сделает нулевик, и прямоток бесполезными. Тут можно начиная примерно с 2800 оборотов ставить 175. Не советую без тонкой настройки ставить максимальное значение в 255 т.к. вам скорее всего будет заливать свечи и взорвется выхлоп.
Load cut — отсечка по топливу/бусту. Вторая палка мешающая нашим спекам увеличить мощность нашего мотора. Из-за этого параметра при поступление воздуха больше чем указано мозгу он отсекает подачу топлива. Тут можно выставить везде 255 если вы собираетесь дуть в двигатель больше 1кг. Я ограничился так же 175 от 2800 оборотов.
В моем случае я на этом закончил. И сохранил прошивку сразу для записи её на чипы.
Но сохраняем в формате odd/even для 256 чипов. Если у вас ECU использует 512 чипы то нужно сохранять одним файлом.
После прихода некоторых спеков напишу про более подробное написание прошивки с расширением топливных карт и прочими интересными вещами.
Источник: www.drive2.ru