Numerosi sono i sistemi di comunicazione impiegati per lo scambio delle informazioni tra le varie ECU (Electronic Control Unit) di un autoveicolo. In particolare il BUS LIN viene utilizzato per connessioni locali di sottosistemi sensori e attuatori.

All’interno di un autoveicolo sono presenti diversi sistemi di comunicazione su bus seriali. Il più affermato è probabilmente il CAN bus per le sue caratteristiche di robustezza e semplicità. L’evoluzione tecnologica ha portato alla realizzazione di nuovi bus di comunicazione ad esempio: Flexray e TTT-CAN. Si stanno anche affermando nuovi bus ad alta velocità quali MOST of Firewire per applicazioni multimediali a bordo del veicolo. Il protocollo LIN (Local Interconnect Network) nasce invece per esigenze opposte a quelle dei bus precedenti: la necessità è quella di collegare i sensori e gli attuatori di un singolo sottosistema del veicolo in modo semplice e soprattutto economico. Alcuni esempi sono: i dispositivi di controllo degli automatismi contenuti all’interno di una portiera: movimento vetro, chiusura portiera, regolazione specchietto laterale, oppure il controllo dei sensori all’interno del motore: livelli dei fluidi, temperature. Come si vedrà in seguito la comunicazione su bus LIN avviene su un solo filo, un dispositivo master gestisce la comunicazione sul bus, e deve avere una temporizzazione precisa, mentre i dispositivi slave connessi al bus ricavano il sincronismo dai messaggi inviati dal master. Queste caratteristiche consentono di realizzare dispositivi a basso costo e di facile assemblaggio, Il bus LIN paga però questa economia costruttiva in termini di banda di comunicazione: la massima velocità non supera i 20Kbit/s e questo limita anche il massimo numero di dispositivi collegabili al bus. Ogni dispositivo connesso al bus è definito nodo, l’insieme di tutti i nodi del bus si definisce cluster. La specifica prevede un numero massimo di 16 nodi per ogni cluster e un estensione del bus che non deve superare i 40 metri. La comunicazione avviene su un unico filo ed è di tipo master/slave, ogni nodo può contenere uno o più slave (fisici o logici), solamente un nodo contiene la funzione master che fornisce tutte le sincronizzazioni necessarie per al comunicazione. Il master deve avere una temporizzazione precisa, per gli slave invece è ammessa una tolleranza del clock del 14%, gli slave infatti utilizzando l’intestazione dei messaggi inviati dal master per sincronizzare  il proprio baudrate. Il  bus LIN eredita molte delle caratteristiche del bus CAN in particolare la modalità di comunicazione che è di tipo boradcast. Non esiste una comunicazione punto punto tra master e slave, ogni messaggio inviato è ricevuto da tutti i  nodi della rete. Si elimina così il problema di conflitti e di sincronizzazione. Il bus è perciò deterministico poiché l’invio di un messaggio dipende esclusivamente dalle temporizzazioni del master. Ogni messaggio si definisce frame ed ha un proprio identificativo PID che ha la struttura di figura 1, la specifica prevede 64 PID (0x00…0x3F) di cui gli ultimi quattro riservati per comandi specifici del protocollo.

Figura 1: struttura di un frame slot. Il break byte è seguito dal sync byte = 55h utilizzato dagli slave per ricavare il baud rate e dall’identificativo PID della frame. Ogni byte tranne il break ha la struttura 1start+8data+1stop. Il PID byte contiene un identificativo a 5bit e due bit di chekcsum

Lo scambio dati tramite le frame può avvenire secondo tre diverse combinazioni:

➤ Master verso uno o più slave

➤ Uno slave verso il master

➤ Uno slave verso uno o più slave

Per ogni identificativo PID utilizzato  i singoli slave che compongono il cluster devono dichiararsi:

➤ Publisher

➤ Subscriber

➤ Nessuno dei due precedenti

Se uno slave si dichiara publisher per una frame significa che intende utilizzare in scrittura il campo dati del messaggio o in altre parole inviare dati sul bus utilizzando l’area dati della frame. Viceversa se uno salve si dichiara subscriber per una frame significa che intende leggere e utilizzare  i dati associati al messaggio. Nel caso in cui uno slave non si dichiari publisher o subscriber di una frame semplicemente ignora la frame o meglio riceve e non utilizza il suo campo dati mentre esegue sempre tutte le operazioni di sincronismo previste per ogni frame.

Struttura della  frame

Ogni frame è suddivisa in due parti: l’intestazione e il buffer dati. L’intestazione è sempre presente e viene inviata solo dal master mentre il buffer dati potrebbe anche non essere presente. I dati sono codificati in byte con struttura identica a quella utilizzata dalla comunicazione UART e cioè 1bit di start 8 bit dati e 1bit di stop. Anche in questo caso viene ereditata la terminologia del bus CAN indicando il bit start come bit dominante in quanto modifica lo stato della linea di comunicazione, mentre il bit di stop, che lascia inalterata la linea di comunicazione, si indica come recessivo. L’intestazione è formata da due bytes di sincronizzazione seguiti dal PID identificativo della frame. Il master  invia inizialmente  il segnale di sincronizzazione che consiste nella trasmissione di almeno 13 bit dominanti seguiti da 1 bit recessivo, condizione non ammessa durante la normale comunicazione in quanto dopo 9bit deve essere trasmesso un bit di stop recessivo. Ogni slave pertanto deve riconoscere il sync break che segnala l’inizio della trasmissione di una nuova frame e deve attendere l’iigura 1nvio dei dati. Il break è seguito dal secondo byte di sincronizzazione che vale sempre 55h. Questo valore permette di avere una commutazione della linea ad ogni bit inviato. I nodi slave calcolano il tempo tra due successive commutazioni per ricavare il baudrate di trasmissione utilizzato dal master. Dopo questa fase di sincronizzazione il terzo byte, inviato sempre dal master, è l’identificativo PID della frame che ha la struttura indicata in figura 2. L’intestazione è seguita da 2 fino al massimo 8 byte di dati e chiuso dalla checksum di 1 byte. I valori nel buffer dati sono definiti signals e possono essere di tipo scalare con dimensione da 1bit a 16bit oppure di tipo array che può includere al massimo 8bytes. Inizialmente la checkusm veniva calcolata solo sul buffer dati. Dalla versione 2.0 della specifica è stata introdotta l’enhanced checksum che include nel calcolo anche il byte PID identificativo della frame.

Trasmissione delle frame

Il master ha il compito di iniziare ogni nuova comunicazione sulla linea del bus inviando l’intestazione di tre bytes di ogni frame. Come si vedrà in seguito il master scandisce una tabella che elenca tutti gli identificativi delle frame previste per il cluster. Le frame sono di tipo incondizionato (unconditional frame) quando ammettono un solo nodo publisher. Spesso accade però che per alcuni dispositivi slave non sia necessaria un’interrogazione periodica poiché
i cambiamenti di stato sono rari. Un esempio potrebbe essere il dispositivo di regolazione dello specchietto retrovisore esterno di un veicolo. Per ottimizzare il traffico sul bus è stato introdotto un diverso tipo di frame la event triggered frame. Il nodo publisher per una event triggered frame risponde alla richiesta inviando i dati solo se questi sono cambiati dall’ultima trasmissione altrimenti il bus rimane nello stato recessivo. Rispetto all’unconditional frame possono esistere più nodi che si dichiarano publisher per una event triggered frame e possono verificarsi diverse situazioni:

➤ nessuno degli slave publisher rileva un cambiamento dei dati rispetto all’ultima trasmissione. Nell’area dati della event triggered frame il bus rimane “in silenzio” nello stato recessivo e tutti i nodi sottoscrittori di questa frame utilizzeranno l’ultimo dato ricevuto come dato valido.

➤ Un solo nodo rileva un cambiamento dei dati rispetto all’ultima trasmissione. In questo caso la comunicazione è identica alla trasmissione di una unconditional frame. Un solo nodo publisher scriverà i nuovi dati nel campo dati della frame e tutti i siubscriber aggiorneranno i dati ricevuti.

➤ Più nodi rilevano dei cambiamento e devono trasmettere i nuovi dati. In questo caso si genera un conflitto sul bus causato dalla trasmissione contemporanea di più publisher. L’errore viene rilevato dagli salve e dal master che attiva una procedura di anticollisione costituita da una sequenza di unconditional frame rivolte ai singoli nodi publisher della event triggered frame. In questo modo il master in condizioni normali con una sola richiesta periodica nterroga contemporaneamente tutti gli salve publisher della frame. Per definizione i dati cambiano di rado perciò solo nel (raro) caso in cui ci sia un cambiamento contemporaneo su più nodi è necessario attivare una sequenza di unconditional frames per interrogare singolarmente tutti gli slave.

node_capability_file;
LIN_language_version = “2.1”;
node step_motor {
  general {
    LIN_protocol_version = “2.1”;
    supplier = 0x0005; function = 0x0020; variant = 1;
    bitrate = automatic min 10 kbps max 20 kbps;
    sends_wake_up_signal = “yes”;
    }
  diagnostic {
    NAD = 1 to 3;
    diagnostic_class = 2;
    P2_min = 100 ms; ST_min = 40 ms;
    support_sid { 0xB0, 0xB2, 0xB7 };
    }
  frames {
   publish node_status {
    length = 4; min_period = 10 ms; max_period = 100 ms;
    signals {
      state {size = 8; init_value = 0; offset = 0;}
      fault_state {size = 2; init_value = 0; offset = 9; fault_enc;}
      error_bit {size = 1; init_value = 0; offset = 8;}
      angle {size = 16; init_value = {0x22, 0x11}; offset = 16;}
}
  }
 subscribe control {
   length = 1; max_period = 100 ms;
   signals {
     command {size = 8; init_value = 0; offset = 0; position;}
     }
  }
  encoding {
   position {physical_value 0, 199, 1.8, 0, “deg”;}
   fault_enc {logical_value, 0, “no result”;
   logical_value, 1, “failed”;
   logical_value, 2, “passed”;}
   }
 status_management {
   response_error = error_bit;
   fault_state_signals = fault_state;
   }
free_text { “step_motor signal values outside 0 - 199 are ignored” }

Descrizione dei nodi e del cluster

La descrizione dei nodi e del cluster deve avvenire con una sintassi standard definita dalle specifiche del bus. Lo scopo è quello di descrivere in modo completo e privo di ambiguità le caratteristiche dei singoli nodi, l’obiettivo è quello di realizzare una procedura automatica in grado di effettuare la configurazione e il setup di un cluster risolvendo i conflitti e l’assegnazione degli identificativi delle frame. Le caratteristiche di ogni nodo sono elencate nel Node Capibility File NCF, mentre le specifiche del cluster sono definite nel LIN Description File LDF. Questi files ricordano la funzione dei descrittori dei dispositivi USB, elencano le caratteristiche del nodo le frame supportate, definiscono l’interfaccia del nodo per le procedure di diagnostica/configurazione, forniscono indicazioni sul tipo e il formato dei dati scambiati nella comunicazione.

Il file  NCF:
questo file elenca in dettaglio le caratteristiche del nodo ed è suddiviso in più sezioni.

General:
contiene indicazioni di tipo generale sulla versione protocollo LIN supportata gli identificativi supplier/function/variant  del dispositivo (descritti in seguito),  il bitrate, il comportamento nei confronti del segnale di sleep/wakeup.

Diagnostic:
contiene le informazioni sull’interfaccia del nodo utilizzate dal protocollo di diagnostica e configurazione, definisce la classe diagnostica dello slave e le temporizzazioni previste per le comunicazioni di diagnostica.

Frame:
descrive le diverse frame supportate dal nodo. In questa sezione  il nodo dichiara se sottoscrive o pubblica una data frame, la formattazione, la codifica dei dati scambiati nelle singole frame, eventuali tirggered frame. Si definisce anche il periodo di scheduling delle frame. L’informazione sarà utilizzata dal master per generare la tabella di scheduling delle frame.

Status  management:
contiene informazioni sul funzionamento dello slave e indicazioni sulla codifica di eventuali errori rilevati.

Free  text:
qui il costruttore può inserire informazioni aggiuntive sulle caratteristiche del dispositivo in formato testo senza una sintassi particolare.

Il file  LDF:
questo file descrive in dettaglio le caratteristiche del cluster formato dai nodi collegati tramite il LIN bus. L’LDF può essere generato automaticamente partendo dall’elaborazione dei file NDF relativi ai nodi che compongono il cluster. Il file contiene informazioni di carattere generale sul protocollo LIN, l’elenco dei nodi collegati, gli identificativi delle unconditional frame e triggered frames utilizzate dal protocollo di comunicazione. La tabella delle diagnostic frames e dei messaggi di configurazione del cluster. Le schedule table che elencano le frame e il relativo periodo di scansione. Il master può contenere più di una schedule table ma in un determinato istante solamente una può essere attiva.

Configurazione e diagnostica

Con la revisione 2.0 della specifica del protocollo LIN sono stati introdotti i messaggi dedicati alla configurazione dei
parametri e alla diagnostica. Questi messaggi sono definiti Packet Data Unit PDU e vengono gestiti nel transport layer. Una PDU viene incapsulata dal protocol layer in una frame con PID = 0x3C (master request) e 0x3D (slave reply). Ogni PDU è suddivisa in frame di 8 byte, ogni frame (da non confondere con le frame del protocol layer) comprende un’intestazione che dipende dal tipo di PDU e un buffer dati come indicato in figura 2.

Figura 2: struttura delle PDU utilizzate nel transport layer per i messaggi di configurazione e diagnostica. Nel protocol layer alla PDU viene aggiunta l’intestazione della frame con PID = 0x3C o 0x3D e la checksum per il buffer dati.

Il primo byte della PDU è il NAD Node AD--dress byte che identifica univocamente lo slave a cui è rivolta la PDU ed è seguito dal PCI Protocol Control Information che contiene informazioni sul formato della PDU Il PCI identifica tre tipi di PDU: SF Single Frame se la PDU è formata da solo 8 byte, mentre per dimensioni maggiori di 8bytes: FF First Frame per la prima frame di 8 bytes della PDU e CF Consecutive Frames per le frame successive. Nell’intestazione delle PDU inviate dal master verso gli slave si trova anche il SID Service Identifier byte che identifica il servizio richiesto di configurazione/diagnostica dalla PDU mentre ogni risposta dallo slave al master deve contenere il Response Service Identifier RSID. Per l’identificazione degli slave ogni nodo definisce all’interno del proprio file NCF tre parametri d’identificazione: Il supplier  ID intero a 16bit assegnato dal consorzio LIN bus. Il  function ID intero a 16bit assegnato dal produttore del dispositivo. Il  variant ID intero a 8bit che identifica una sottoclasse specifica del prodotto. Ogni dispositivo può avere inoltre un proprio numero seriale a 32 bit assegnato dal produttore. Un nodo slave in operational state viene identificato da una terna univoca di valori supplier ID, function ID e NAD. Tramite le PDU è possibile modificare il NAD di un nodo slave. In questo modo il master dopo aver analizzato gli NCF dei nodi slave che compongono il  cluster può assegnare alcuni NAD se questi non sono univoci. Con le PDU di configurazione il master può invece assegnare agli slave i codici PID relativi alle frame gestite dal cluster. Le PDU di identificazione consentono invece di ottenere gli identificativi supplier/function/variant o il serial number di un nodo slave. Per le funzioni di diagnostica i dispositivi collegati su bus LIN sono suddivisi in tre classi: dispositivi di classe I riconoscono solo le PDU di configurazione di tipo SF (Single Frame). In genere sono dispositivi semplici, la diagnostica è implementata nel protocol layer (segnale di fault). Dispositivi in classe II Supportano sia le PDU di configurazione che di identificazione anche di tipo multiframe. Anche in questo caso la diagnostica è implementata nel protocol layer. Questi dispositivi devono poter operare anche in classe I. Dispositivi in classe III sono dispositivi evoluti che includono un “intelligenza” locale in grado di effettuare autonomamente operazioni di verifica e diagnostica. Come i dispositivi in classe II supportano PDU di configurazione e di diagnostica anche in modalità multiframe.

Conclusioni

La descrizione precedente fornisce un punto di partenza che introduce i concetti principali per chi desidera realizzare un sistema di comunicazione embedded secondo le specifiche bus LIN. Non è stata trattata l’interfaccia tra l’applicativo della ECU e il driver di comunicazione sul bus LIN.

Ti potrebbe interessare anche:

Veicoli a guida autonoma

Firmware 138 Speciale Automotive

Comunicazione dati – Parte 1

Articoli Correlati

I bus per applicazioni Automotive

CanOpen Bus