Перед створенням різні дані по одній лінії, повинно бути ретельно визначено та погоджено безліч критеріїв. Ці критерії відомі як комунікаційний протокол, або протокол зв'язку. Протокол визначає:
♦ послідовність передачі і формат даних;
♦ керуючі сигнали;
♦ виявлення помилок;
♦ обробка помилок;
♦ швидкість передачі.
Також повинен бути визначений і погоджений фізичний рівень сигналів. Він включає наступні параметри:
♦ тип лінії зв'язку (мідний дріт, оптоволокно);
♦ тип кодування передачі (аналоговий або цифровий);
♦ тип сигналів (напруга, струм, частота або ін.).
Схема, що відповідає цим критеріям, відома як шинний інтерфейс і найчастіше за все буде виконана у вигляді однієї інтегральної схеми. Ця ІС буде в деяких випадках мати додаткову схему - наприклад, пристрій пам'яті. Вона може бути відповідним чипом, настільки дешевим,
наскільки це можливо через велику їх кількості, використовуваного на транспортному засобі. Як це відбувається часто з протоколом будь-якої системи, очікується, що набуде поширення тільки один протокол. Однак так буває
Мережа CAN фірми Bosch
Фірма Bosch розробила протокол, відомий як CAN (Controller Area Network). Як стверджується, протокол відповідає практично всім умовам і реалізується на кристалі малої площі, тому вартість мікросхеми невелика, C A N підходить для передачі даних між компонентами трансмісії, шасі і для мобільних комунікацій.
Це компактна система, що робить її практичною для застосування в багатьох областях. На фізичному рівні існує дві модифікації системи, які задовольняють різним нормам передачі. Одна-для передачі даних на швидкостях від 100 кбіт до 1 М біт в секунду повинна використовуватися для швидкісних пристроїв управління. Інша передає сигнали зі швидкістю від 10 до 100 кбіт- повільна шипа для простої комутації та операцій управління.
CAN-модулі виготовляються безліччю напівпровідникових фірм, таких як Intel і Motorola.
Доступні модулі Voll-CAN для швидкісних шин і Basie-CAN для низьких швидкостей передачі даних. Вони існують як в автономному вигляді, так і в інтегрованому в різні мікропроцесори. Всі модулі підтримують єдиний САМ-
протокол. Очікується, що цей протокол буде затверджений
Міжнародною Організацією Стандартів (ISO).
Багато датчики і приводи ще не реалізовані і шинному варіанті, і хоча були випущені дослідні зразки, повністю відмовитися від звичайної кабельної мережі поки неможливо. Електронні блоки інтерфейсу повинні бути розташовані і безпосередній близькості, в ідеалі інтегровані всередину датчиків і приводних механізмів. Особливо це важливо для датчиків і приводів двигуна. Внаслідок проблем з нагріванням і вібрацією потрібно їх подальше вдосконалення, щоб гарантувати надійність і низьку ієну. На рис 4.21 показано, як виглядає шинна система на транспортному засобі.
Сьогодні зроблено суттєвий крок до використання
шин даних для спілкування приладів з блоками управління. На рис. 4.22 наведено приклад від компанії Volvo.
Сигнальний формат CAN
Сигнал повідомлення в форматі CAN складається з послідовності двійкових знаків (біт). Наявність напруги (або світла в оптоволокне) означає логічну «1», в той час як їх відсутність означає логічний «0». Довжина повідомлення може складати від 44 до 108 біт. Повідомлення починається стартовим бітом, потім йде ідентифікатор приймально-передавача, біт контролю, безпосередньо дані повідомлення, контрольна
сума CRC (надлишковий циклічний код для виявлення та виправлення помилок - cyclic redundancy check), біт підтвердження і, нарешті, кілька степових бітів (рис. 4.23).
Початок повідомлення (заголовок) ідентифікує призначення повідомленні, а також його пріоритет. Як тільки заголовок помешен на шину, він повторно зчитується вже з шини. Якщо він відрізняється від посланого - значить, шина Ланіта пристроєм, що має більш високий пріоритет. Якщо справа йде так, передавач зупинить передачу власного повідомлення. Це дуже важливо в разі передачі даних в автомобілі.
Рис 4.23. «Слово» повідомлення по протоколу CAN