2.4.3 Передача даних всередині блоку керування

Периферійні пристрої, що підтримують роботу мікроконтролера, повинні мати можливість зв'язку з ним. Це здійснюється за допомогою адресної шини і шини даних. Мікроконтролер видає через адресну шину, наприклад, адресу пам'яті RAM, зміст якої повинен зчитуватися. Шина даних потім використовується для передачі тих даних, що відносяться до цієї адреси.

Раніше на автомобілях обходилися 8-бітовою шиною з восьми провідників, по яких одночасно можна передавати 256 значень. За допомогою звичайної для цих систем адресної шини на 16 біт можна запрошувати 65536 адресів. Сьогодні складніші системи вимагають використання шин даних на 16 біт або навіть 32 біт. Для того, щоб зменшити кількість електричних імпульсів, адресна шина і шина даних можуть об'єднуватися в одну мультиплексну систему, тобто адреси і дані передаються із зрушенням за часом і з використанням одних і тих же провідників. Для даних, які не повинні передаватися швидко (наприклад, дані пам'яті по несправностях), застосовуються послідовні інтерфейси тільки з однією лінією передачі даних.

2.4.4 Програмування EoL

Різноманіття моделей автомобілів, що потребують різних програм управління і баз даних, вимагає обов'язкового зменшення типажу блоків управління, необхідних для конкретного виготівника автомобілів. Для цього весь діапазон пам'яті Flash-EPROM з програмами і специфічним для конкретного варіанту набором даних може програмуватися на кінцевій стадії виробництва автомобіля за допомогою так званого програмування EoL (End of Line — кінець потокової лінії збірки).

Іншою можливістю зменшення різноманіття цих варіантів є запис в пам'яті декількох варіантів даних (наприклад, модифікацій коробок передач), які потім можуть вибиратися шляхом введення відповідного коду в кінці складального конвеєра. Це кодування вводиться в пам'ять EEPROM.

2.5 Програмне забезпечення блоків керування

Коли перші мікроконтролери почали застосовуватися в блоках керування, то у використовуваних ними програмах був об'єм від 4 Кбайт або навіть ще менше. У мікросхем пам'яті (чіпів) у той час ємність була не більша. З цієї причини програми повинні були розроблятися за допомогою кодів, що економлять пам'ять. Найбільш часто вживаною мовою програмування був «асемблер». Команді в цій мові мнемонічні і вони в цілому відповідають машинному коду мікроконтролера. Проте, як правило, програми на мові «асемблер» важко читати і інтерпретувати.

З часом ємність чіпів пам'яті все збільшувалася, а діапазон функцій, що реалізовуються системою керування двигуном, ставав все складнішим. Кількість функцій, що зростали, зробила неминучим створення модулів програмного забезпечення. Програмне забезпечення блоку керування двигуном структуроване на модулі, кожен з яких містить певну групу функцій (наприклад, замкнутий контур лямбда-керування, регулювання частоти обертання колінчастого валу на холостому ходу та ін.). Ці модулі мають, звичайно, застосовуватися не в одному проекті, а в багатьох подібних проектах. Тому необхідне використання стандартних інтерфейсів для вхідних і вихідних змінних. У зв'язку з цим мова програмування «асемблер» досягла меж своїх можливостей стосовно автомобільної електроніки.

При сучасних вимогах до розробки програмного забезпечення неминучим стало застосування мов програмування високого рівня. Тепер все програмне забезпечення системи керування двигуном створюється на мові високого рівня — головним чином на мові програмування Сі. Програмування на мові високого рівня забезпечує: можливість коректування програмного забезпечення; модульність; взаємозамінність пакетів програм; незалежність програмного забезпечення від мікро-контролера, що використовується в блоці управління.

Велика частина інновацій у автомобільну техніку здійснюється за рахунок використання електроніки. Раніше програмне забезпечення розглядалося як «додаток» до апаратної частини. З часом програмному забезпеченню почало приділятися все більше значення. Разом зі складністю електронних систем, керованих мікроконтролерами, якість програмного забезпечення стала головним чинником при його розробці, оскільки проблеми, що виникають із-за недосконалості програмного забезпечення, шкодять репутації фірми-виробника і збільшують вартість гарантій.

11