Rozdział 2. Architektura sprzętu

Rozdział 1. Założenia projektu | OpenDiag - STM32 CAN Tool | Rozdział 3. Architektura oprogramowania


Rozdział 2. Architektura sprzętu

2.1 Cel

Urządzenie OpenDiag jest interfejsem pomiędzy komputerem PC a magistralami CAN pojazdu.

Jego zadaniem jest:

  • komunikacja z komputerem przez USB,
  • komunikacja z magistralami CAN pojazdu,
  • konwersja protokołów diagnostycznych,
  • zapewnienie izolacji warstw sprzętowej i programowej.

2.2 Schemat blokowy

Proponuję przyjąć taki schemat jako bazę całego projektu:

.                       +----------------------+
                        |      Komputer        |
                        | Linux / Windows      |
                        +----------+-----------+
                                   |
                              USB 2.0 (CDC)
                                   |
                  +----------------+---------------+
                  |          STM32 MCU             |
                  |                                |
                  | USB Device                     |
                  | CLI / Parser / ELM / STN       |
                  |                                |
                  | CAN1        CAN2      CAN3     |
                  +---+----------+-----------+-----+
                      |          |           |
                +-----+---+  +-----+--+ +----+----+
                | SN65... | | SN65... | | SN65... |
                +-----+---+ +-----+---+ +-----+---+
                      |          |          |
                    HS-CAN     MS-CAN      I-CAN

2.3 Jednostka centralna

Pierwszą platformą będzie:

STM32F767ZI (Nucleo-144)

Powody:

  • łatwe debugowanie,
  • ST-Link,
  • Virtual COM,
  • USB Device,
  • trzy kontrolery CAN,
  • bardzo wygodne prototypowanie.

Docelowo kod ma być przenoszalny na:

  • STM32H723
  • STM32H562

bez zmian logiki aplikacji.


2.4 Interfejs USB

Urządzenie posiada dwa niezależne kanały komunikacyjne. Kanał 1 ST-Link Virtual COM.

Przeznaczenie:

  • logi,
  • debug,
  • diagnostyka firmware.

Nigdy nie będzie używany przez FORScan.

Kanał 2

USB Device.

Na początku:

USB CDC.

Docelowo możliwe:

  • CDC
  • WinUSB/Vendor
  • DFU

2.5 Interfejs CAN

Projekt zakłada obsługę trzech niezależnych magistral.

Kanał Przeznaczenie
CAN1 HS-CAN
CAN2 MS-CAN
CAN3 I-CAN / przyszłość

Każdy kanał posiada:

  • osobny kontroler CAN,
  • osobny transceiver,
  • niezależną konfigurację.

Nie stosujemy przełączników HS/MS.


2.6 Transceivery

Pierwsza wersja wykorzystuje:

SN65HVD230

Powody:

  • 3,3 V
  • zgodność ze STM32
  • łatwa dostępność
  • niski koszt

Każdy kontroler CAN posiada własny transceiver.


2.7 Złącze OBD-II

Pierwsza wersja projektu wykorzystuje: Pin Funkcja
4 GND
5 Signal GND
6 HS-CAN H
14 HS-CAN L
3 MS-CAN H
11 MS-CAN L
1 I-CAN H (jeśli występuje)
8 I-CAN L (jeśli występuje)
16 +12V

Projekt powinien umożliwiać łatwą zmianę mapowania dla innych producentów pojazdów.


2.8 Zasilanie

Źródła zasilania:

  • USB (podczas programowania i testów)
  • OBD-II (+12 V z pojazdu)

Na etapie prototypu (Nucleo) zasilanie z OBD nie jest wymagane, ale w projekcie docelowym przewidujemy:

  • zabezpieczenie przed odwrotną polaryzacją,
  • bezpiecznik,
  • filtr przeciwzakłóceniowy,
  • przetwornicę 12 V → 5 V → 3,3 V.

2.9 Sygnalizacja

Minimalny zestaw:

  • LED Power
  • LED USB
  • LED CAN1
  • LED CAN2
  • LED CAN3
  • LED Error

Na Nucleo wykorzystamy tylko dostępne diody, a pełna sygnalizacja pojawi się na własnej płytce.


2.10 Rozszerzenia sprzętowe

Nie są wymagane w pierwszej wersji, ale architektura ma przewidywać możliwość dodania:

  • gniazda microSD,
  • Ethernet,
  • Bluetooth,
  • Wi-Fi,
  • izolacji galwanicznej CAN,
  • zewnętrznego zasilania.

Jedna propozycja do dyskusji

Tutaj chciałbym zaproponować jedną zmianę względem typowych interfejsów ELM327. Lepiej zdefiniować je jako:

  • Port CAN A
  • Port CAN B
  • Port CAN C

A dopiero w konfiguracji przypisać:

CAN A → HS-CAN
CAN B → MS-CAN
CAN C → I-CAN

Dlaczego? Bo wtedy ten sam sprzęt bez zmian będzie można wykorzystać z Oplem, grupą VAG, PSA czy innymi pojazdami, gdzie przypisanie magistral do złącza OBD wygląda inaczej. Firmware pozostanie uniwersalny, a mapowanie stanie się elementem konfiguracji, a nie projektu. To moim zdaniem lepiej wpisuje się w założenie z Rozdziału 1, że budujemy uniwersalny interfejs diagnostyczny, a nie urządzenie wyłącznie do jednego modelu samochodu.