IT201800003980A1 - Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti - Google Patents

Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti Download PDF

Info

Publication number
IT201800003980A1
IT201800003980A1 IT102018000003980A IT201800003980A IT201800003980A1 IT 201800003980 A1 IT201800003980 A1 IT 201800003980A1 IT 102018000003980 A IT102018000003980 A IT 102018000003980A IT 201800003980 A IT201800003980 A IT 201800003980A IT 201800003980 A1 IT201800003980 A1 IT 201800003980A1
Authority
IT
Italy
Prior art keywords
devices
messages
bus
slave
master
Prior art date
Application number
IT102018000003980A
Other languages
English (en)
Inventor
Fred Rennig
Ludek Beran
Original Assignee
Stmicroelectronics Application Gmbh
St Microelectronics Des & Appl
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Stmicroelectronics Application Gmbh, St Microelectronics Des & Appl filed Critical Stmicroelectronics Application Gmbh
Priority to IT102018000003980A priority Critical patent/IT201800003980A1/it
Priority to EP19162919.5A priority patent/EP3547620B1/en
Priority to US16/360,229 priority patent/US10678726B2/en
Priority to CN201920370576.5U priority patent/CN209642692U/zh
Priority to CN202210298149.7A priority patent/CN114666183A/zh
Priority to CN201910221331.0A priority patent/CN110365564B/zh
Priority to JP2019057403A priority patent/JP7253950B2/ja
Priority to KR1020190033439A priority patent/KR102370862B1/ko
Publication of IT201800003980A1 publication Critical patent/IT201800003980A1/it
Priority to US16/874,055 priority patent/US11366778B2/en
Priority to US17/806,587 priority patent/US11675721B2/en
Priority to JP2022185693A priority patent/JP2023018057A/ja
Priority to US18/309,103 priority patent/US20230267087A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40078—Bus configuration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4063—Device-to-bus coupling
    • G06F13/4068—Electrical coupling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4063—Device-to-bus coupling
    • G06F13/4068—Electrical coupling
    • G06F13/4072—Drivers or receivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0061—Error detection codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40013—Details regarding a bus controller
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/4013—Management of data rate on the bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/403—Bus networks with centralised control, e.g. polling
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/12—Plc mp multi processor system
    • G05B2219/1215—Master slave system
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/22—Pc multi processor system
    • G05B2219/2231—Master slave
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/31—From computer integrated manufacturing till monitoring
    • G05B2219/31179—Master sends message with address of slave to all slaves, slave answers, interrupt
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/09—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Automation & Control Theory (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Radar Systems Or Details Thereof (AREA)

Description

DESCRIZIONE dell’invenzione industriale dal titolo:
“Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti”
TESTO DELLA DESCRIZIONE
Campo tecnico
La descrizione è relativa a una comunicazione supportata da bus per l’uso, per es., nelle applicazioni automotive.
Per esempio, una o più forme di attuazione possono essere applicate alla comunicazione tra le unità di controllo elettronico (ECU, “Electronic Control Unit”) delle luci di un veicolo (per es., luci anteriori, posteriori, interne) e i corrispondenti moduli di illuminazione, per es. moduli di luci LED.
Sfondo tecnologico
Varie applicazioni, per es. nel campo automotive, comportano lo scambio di dati su una o più reti di bus. Caratteristiche desiderabili per tali applicazioni sono una elevata velocità di trasmissione (“data rate”), la robustezza, la rilevazione dei guasti, la sicurezza e il basso costo.
I sistemi esistenti di comunicazione per veicoli standardizzati ad elevata velocità di trasmissione (per es., 1 Mbit/s) possono implicare controllori di protocollo accurati e complessi che usano componenti esterni. Può risultare che questi siano costosi, specialmente quando implementati come degli ASIC (Application Specific Integrated Circuit) e/o degli ASSP (Application Specific Standard Product) bipolari/analogici a singolo chip.
Le luci dei veicoli (per es., le luci anteriori, posteriori e interne) stanno diventando sempre più sofisticate e distribuite (per es., LED a Matrice, LED ambiente). Controllare tali sistemi sofisticati e distribuiti può comportare un controllo con una elevata velocità di trasmissione. Inoltre, sono desiderabili una robustezza e una sicurezza di grado automotive, specialmente per i sistemi di illuminazione anteriore e posteriore.
I dispositivi di pilotaggio (“driver”) di LED possono essere efficienti in termini di costo, per es., quando impiegano tecnologie a singolo chip come una tecnologia BCD (Bipolar-CMOS-DMOS). D’altra parte, si nota che i controllori di protocollo ad alta velocità di trasmissione che usano, per es., una tecnologia BCD possono essere costosi e dipendono da una sorgente di clock accurata (cristallo).
Per i segnali di temporizzazione (“clock”) e di dati può essere adottato un cablaggio differenziale al fine di facilitare la robustezza, il che può aumentare il costo del cablaggio dei fili.
La crescente complessità della rete di comunicazione in un veicolo, per es., per pilotare sorgenti di illuminazione distribuita, come le matrici di LED, può condurre perciò a un aumento dei costi di produzione, che può essere difficilmente compatibile con i modelli di business nell’industria automobilistica.
Una o più forme di attuazione sono applicabili, per esempio, a un bus CAN (Controller Area Network). Questo è un dispositivo ben noto che può facilitare la comunicazione, per es., tra microcontrollori e dispositivi a bordo di un veicolo senza un elaboratore host. Il funzionamento di un bus CAN può essere basato su un protocollo basato su messaggi, come trattato negli standard quali, per es., ISO 11898-2:2015 e ISO 11898-2:2016.
Scopo e sintesi
Nonostante la vasta attività nell’area, sono desiderabili ulteriori soluzioni perfezionate.
Per esempio, sono desiderabili soluzioni che possono facilitare, per es., la realizzazione di reti per veicoli per pilotare sorgenti di luci LED distribuite efficienti in termini di costo, ad alta velocità di trasmissione, che sono conformi ai requisiti automotive in termini di robustezza, di rilevazione dei guasti e di sicurezza. Soluzioni simili possono anche facilitare la realizzazione di reti ad alta velocità di trasmissione per l’implementazione, per es., in sistemi di automazione della produzione o simili.
Uno scopo di una o più forme di attuazione è di contribuire a fornire tali soluzioni migliorate.
Secondo una o più forme di attuazione, tale scopo può essere raggiunto per mezzo di un procedimento avente le caratteristiche esposte nelle rivendicazioni che seguono.
Una o più forme di attuazione possono essere relative a un sistema corrispondente.
Una o più forme di attuazione possono essere relative a dispositivi corrispondenti, per es. (interfacce) trasmettitore e ricevitore che è previsto che lavorino insieme.
Una o più forme di attuazione possono essere relative a un segnale corrispondente.
Una o più forme di attuazione possono essere relative a un veicolo corrispondente, per es. un veicolo a motore quale una autovettura.
Le rivendicazioni sono parte integrante dell’insegnamento tecnico qui fornito con riferimento alle forme di attuazione.
Una o più forme di attuazione possono fornire una soluzione hardware, adatta per realizzare una rete di comunicazione per la comunicazione, per es., tra unità di controllo elettronico (ECU) e moduli di illuminazione, come moduli di luci LED.
Una o più forme di attuazione possono realizzare un’interfaccia di bus di comunicazione master-slave che può essere usata in applicazioni automotive.
Tale interfaccia di bus di comunicazione per l’uso in applicazioni automotive può fare affidamento sul protocollo standardizzato CAN FD (Flexible Data-Rate) per pilotare i moduli di illuminazione in un veicolo (“CAN FD Light”).
Una o più forme di attuazione possono fare affidamento su tecnologie di rete diverse da una rete CAN FD standardizzata, per es. per l’uso in applicazioni non automotive, come per es. i sistemi di automazione o simili.
Per esempio, una o più forme di attuazione possono usare un cablaggio di bus differenziale e possono fornire una densità di fronti definita (per es., un fronte da recessivo a dominante ogni 10 bit) ai fini della sincronizzazione.
Una o più forme di attuazione possono implementare un controllo di ridondanza ciclico (CRC, “Cyclic Redundancy Check”) e un controllo degli errori per motivi di sicurezza.
In una o più forme di attuazione, lo scambio di dati può fare affidamento su uno schema master–slave, in cui i “satelliti”, vale a dire gli slave, inviano dati sul bus di comunicazione (soltanto) su richiesta del dispositivo master. Un tale schema di funzionamento può non implicare una caratteristica di risoluzione delle collisioni, nella misura in cui un funzionamento normale può avere come obbiettivo evitare le collisioni, con le collisioni trattate come errori.
In una o più forme di attuazione, un funzionamento normale del bus di comunicazione può comportare che un master invii dati (regolarmente) agli slave. Un tale flusso continuo (“stream”) (regolare) di dati può essere usato dagli slave come una sorta di watchdog o di “battito cardiaco” (heartbeat) della rete. Se lo stream regolare di dati non è ricevuto entro un intervallo di tempo definito, gli slave possono entrare in una modalità di sicurezza (“fail-safe” o “limp-home”).
In una o più forme di attuazione, dati quali i dati di diagnosi dagli slave, possono essere cercati dal master, per es. usando messaggi (“frame”) di comando dedicati. Un certo slave indirizzato può reagire a una tale richiesta entro un certo periodo di tempo. Tali reazioni possono essere usate dal master per rilevare la disponibilità degli slave.
Breve descrizione delle figure
Una o più forme di attuazione saranno ora descritte, a puro titolo di esempio, con riferimento alle figure annesse, nelle quali:
- la Figura 1 è esemplificativa di una possibile implementazione di forme di attuazione;
- la Figura 2 è esemplificativa di una possibile implementazione di un dispositivo master in forme di attuazione;
- la Figura 3 è esemplificativa di una possibile implementazione di un dispositivo slave in forme di attuazione;
- la Figura 4 è un diagramma esemplificativo di un possibile funzionamento di forme di attuazione;
- la Figura 5 è uno schema a blocchi esemplificativo di un possibile funzionamento di forme di attuazione che gestisce un frame “broadcast”;
- la Figura 6 è uno schema a blocchi esemplificativo di un possibile funzionamento di forme di attuazione che gestisce un frame di “diagnosi”;
- la Figura 7 è uno schema a blocchi esemplificativo di un possibile funzionamento di forme di attuazione che gestisce un frame di “errore”;
- la Figura 8 è uno schema a blocchi esemplificativo di una possibile implementazione di un ciclo di comunicazione master in forme di attuazione; e
- la Figura 9 è uno schema a blocchi esemplificativo di una possibile implementazione di un ciclo di comunicazione slave in forme di attuazione.
Descrizione dettagliata di esempi di forme di attuazione
Nella descrizione che segue, sono illustrati uno o più dettagli specifici, allo scopo di fornire una comprensione approfondita di esempi di forme di attuazione di questa descrizione. Le forme di attuazione possono essere ottenute senza uno o più dei dettagli specifici o con altri procedimenti, componenti, materiali, ecc. In altri casi, operazioni, materiali o strutture note non sono illustrate o descritte in dettaglio in modo tale che certi aspetti delle forme di attuazione non saranno resi poco chiari.
Un riferimento a “una forma di attuazione” nel quadro della presente descrizione intende indicare che una particolare configurazione, struttura, o caratteristica descritta con riferimento alla forma di attuazione è compresa in almeno una forma di attuazione. Per cui, le frasi come “in una forma di attuazione” che possono essere presenti in uno o più punti della presente descrizione non fanno necessariamente riferimento proprio alla stessa forma di attuazione. Inoltre, particolari conformazioni, strutture o caratteristiche possono essere combinate in un modo adeguato qualsiasi in una o più forme di attuazione.
I riferimenti usati qui sono forniti semplicemente per convenienza e quindi non definiscono l’ambito di protezione o l’ambito delle forme di attuazione.
Come indicato, una o più forme di attuazione possono avere come obiettivo fornire un’interfaccia di bus masterslave “robusta” che può essere usata in applicazioni automotive.
Una o più forme di attuazione possono fare affidamento su un protocollo e un’interfaccia fisica CAN FD standardizzati e possono sfruttare un cablaggio di bus differenziale fornendo al tempo stesso una certa densità di fronti ai fini della sincronizzazione.
Una o più forme di attuazione possono implementare un controllo di ridondanza ciclico (CRC) e un controllo degli errori per la conformità alla sicurezza.
Lo schema della Figura 1 è generalmente esemplificativo di un dispositivo in cui un primo dispositivo 10 e un insieme di secondi dispositivi 201, 202, …, 20n, per es., a bordo di un veicolo V, sono accoppiati tramite un bus 30. Per esempio, il bus 30 può essere un bus differenziale. Un bus CAN è un esempio di un tale bus differenziale possibile.
In un tale dispositivo come esemplificato nella Figura 1, il primo dispositivo 10 trasmette sul bus 30 “primi” messaggi che trasportano un insieme di porzioni di messaggio di dati operativi, e i secondi dispositivi nell’insieme di secondi dispositivi 201, 202, …, 20n identificano nei primi messaggi rispettive porzioni di messaggio di dati operativi a loro indirizzate e reagiscono ad esse implementando rispettive operazioni.
Come esemplificato nella Figura 1, una o più forme di attuazione possono essere applicate a reti di bus di comunicazione locale, per es., per pilotare dei gruppi (“cluster”) di LED (per es., le luci di un veicolo). Nel caso in cui tali reti di bus siano compatibili con reti CAN FD standard, esse sono indicate qui come reti “CAN FD Light”.
Per il resto, si apprezzerà che un riferimento a tale possibile applicazione è puramente a titolo esemplificativo e non è da interpretare (neanche indirettamente) come limitativo per le forme di attuazione.
Per esempio, un sistema di comunicazione come esemplificato nella Figura 1 può anche essere adatto per l’uso con dispositivi di pilotaggio per le luci anteriori e/o le luci interne di un veicolo.
Sistemi di comunicazione simili possono essere adatti per l’uso con un qualsiasi altro tipo di ECU e di dispositivi di pilotaggio (non necessariamente all’interno di un veicolo), a condizione che possano basarsi su un’architettura master-slave.
La Figura 1 è esemplificativa di un sistema secondo forme di attuazione che comprende un dispositivo master 10, per es. una unità di controllo elettronico (ECU), per es., per dei gruppi di LED nelle luci posteriori in un veicolo.
Si pone di nuovo l’accento sul fatto che un riferimento a tale possibile applicazione è puramente a titolo esemplificativo e che non deve essere interpretato (neanche indirettamente) come limitativo per le forme di attuazione.
Una o più forme di attuazione possono comprendere una pluralità di “satelliti” o dispositivi slave 201, 202, …, 20n, per es. circuiti di pilotaggio (lineari) di LED, in comunicazione con il dispositivo master, tramite un bus di comunicazione 30.
In una o più forme di attuazione, sia il dispositivo master 10 sia i dispositivi slave 201, 202, …, 20n possono essere alimentati da una sorgente di alimentazione 40, per es. una batteria fornita nel veicolo.
In una o più forme di attuazione, il dispositivo master 10 e i dispositivi slave 201, 202, …, 20n possono essere riferiti a masse differenti.
Un dispositivo master 10 come illustrato nella Figura 1 può comprendere uno o più dei componenti seguenti:
- un convertitore principale (per es., “buck”) 101, - un convertitore opzionale (per es., di nuovo “buck”) 102,
- un blocco circuitale 103 regolatore di tensione lineare a bassa caduta (“low-dropout”, LDO), di standby, reset e finestra, e watchdog,
- un blocco circuitale 104 supervisore di tensione, di power-good, oscillatore e abilitazione,
- un microcontrollore 106,
- un circuito ricetrasmettitore 105 per la comunicazione con altre ECU eventualmente montate nel veicolo (per es., un ricetrasmettitore LIN2.2/ HS-CAN), e - un punto di accesso a un bus di comunicazione esterno 107 connesso al ricetrasmettitore 105 per la comunicazione con altre ECU comprese nel veicolo.
In una o più forme di attuazione, il microcontrollore 106 può essere alimentato dal convertitore principale 101 e/o dal convertitore opzionale 102. Il microcontrollore 106 può essere accoppiato con il blocco circuitale 103 e con il ricetrasmettitore 105, e può essere adatto per la comunicazione e/o la cooperazione con il bus di comunicazione 30.
A parte gli aspetti discussi in seguito, una tale architettura per il dispositivo master 10 è tradizionale nella tecnica, rendendo così superfluo fornire qui una descrizione più dettagliata.
In una o più forme di attuazione, la funzionalità “master” del dispositivo 10 può essere implementata usando un controllore di protocollo integrato nel microcontrollore 106 e un ricetrasmettitore CAN FD (non visibile nella Figura 1).
Per esempio, in una o più forme di attuazione come qui esemplificate, il master 10 è un microcontrollore (µC), che gestisce una comunicazione su bus. Un tale microcontrollore può usare un controllore di protocollo CAN FD integrato che può gestire il protocollo CAN FD senza l’intervento di un software. Questa può essere una scelta preferibile rispetto a far funzionare tramite SW un controllore differente che occuperebbe le risorse di un core di microcontrollore e che può essere indesiderabilmente lento. Una o più forme di attuazione facilitano così il riuso di un controllore di protocollo hardware esistente, con messaggi CAN FD inviati e il loro contenuto controllato tramite software.
In una o più forme di attuazione, i dispositivi slave 20 possono essere implementati come dispositivi di pilotaggio di LED usando una tecnologia BCD.
In una o più forme di attuazione, lo scambio di dati sul bus di comunicazione 30 può basarsi su uno schema master–slave, in cui gli slave 201, 202, …, 20n possono inviare dati sul bus di comunicazione 30 (soltanto) su richiesta di un dispositivo master 10.
Come indicato, in una o più forme di attuazione:
- un tale schema di funzionamento può non comportare una caratteristica di risoluzione delle collisioni, nella misura in cui un funzionamento normale può avere come scopo evitare le collisioni, con le collisioni trattate come errori,
- un funzionamento normale del bus di comunicazione 30 può comportare che il master 10 invii regolarmente (cioè, in intervalli di tempo definiti) dati agli slave 201, 202, …, 20n con tali dati ricevuti da (tutti) gli slave 201, 202, …, 20n. Un tale stream regolare di dati può essere usato dagli slave come un watchdog o un “battito cardiaco” della rete. Come risultato del fatto che lo stream regolare di dati non è ricevuto entro un intervallo di tempo definito, gli slave possono entrare nella loro modalità di sicurezza (fail-safe o limp-home).
In una o più forme di attuazione, dati come dati di diagnosi dagli slave 201, 202, …, 20n possono essere richiesti dal master 10 usando frame di comando dedicati, per es. “secondi” messaggi inviati dal master 10 sul bus 30. Un certo (singolo) slave 20i indirizzato può reagire, per es., rispondere a una richiesta emessa dal master entro un certo periodo di tempo. Una tale risposta, inviata dallo slave 20i sulla rete di bus 30, può essere usata dal master 10 per rilevare la disponibilità e/o il funzionamento corretto dello slave 20i.
Si apprezzerà che:
- i primi messaggi discussi qui corrispondono sostanzialmente a messaggi broadcast come trasmessi tradizionalmente in un protocollo basato su messaggi come, per es., un protocollo di bus CAN nel quale i messaggi trasmessi sul bus da un dispositivo sono ricevuti (simultaneamente) da (tutti) gli altri dispositivi, con questi ultimi dispositivi atti a implementare rispettive operazioni in funzione di porzioni di dati operativi convogliate da tali messaggi broadcast,
- sebbene inviati per così dire “fisicamente” in broadcast sul bus da un dispositivo (master), i secondi messaggi sono in effetti indirizzati “logicamente” a singoli altri dispositivi (slave) sostanzialmente come messaggi di richiesta, tramite cui ai dispositivi slave è richiesto di reagire inviando verso il dispositivo master – entro un certo intervallo di tempo – una rispettiva risposta, come per es. un messaggio di diagnosi, con possibili collisioni di tali risposte evitate nella misura in cui il dispositivo master alloca rispettivi intervalli di risposta, non in collisione, ai dispositivi slave.
Si noterà anche che, nel quadro della presente descrizione, entrambi i termini “frame” e “messaggio” possono essere usati per indicare messaggi scambiati tra partecipanti nel bus di comunicazione 30.
In una o più forme di attuazione, il protocollo di comunicazione può usare (soltanto) frame con formato CAN FD, senza commutazione di bit rate e con ID standard.
Estensioni come quelle che supportano un ID esteso, frame CAN tradizionali o una commutazione di bit rate possono essere incluse opzionalmente. Frame che non sono supportate dall’implementazione possono essere ignorati, con i bit previsti per cambiare queste modalità operative mantenuti a un loro valore fisso.
La Figura 2 è uno schema a blocchi esemplificativo di una possibile implementazione di un dispositivo master 10 secondo forme di attuazione.
In tutte le figure qui annesse, parti o elementi simili sono indicati con riferimenti/numeri simili e una descrizione corrispondente non sarà ripetuta per brevità.
Perciò, la Figura 2 rappresenta un dispositivo master 10 che può comprendere:
- un punto di accesso a un bus di comunicazione 30, per es. un bus CAN,
- un punto di accesso a un secondo bus di comunicazione 107,
- un circuito ricetrasmettitore 105 per la cooperazione con il bus di comunicazione 107,
- un circuito ricetrasmettitore 108, per es. un ricetrasmettitore CAN FD, per la cooperazione con il bus di comunicazione 30, e
- un microcontrollore 106, che comprende a sua volta un controllore di protocollo di comunicazione (HW e/o SW) 1062, per es. un controllore di protocollo CAN FD, una estensione di protocollo di comunicazione (per es., SW) 1061, per es. un’estensione di protocollo “CAN FD Light”, ed eventualmente altri blocchi circuitali 1063.
In una o più forme di attuazione, un’estensione di protocollo CAN FD 1061 aggiuntiva può controllare il controllore di protocollo CAN FD 1062 per implementare il lato master del protocollo CAN FD Light, come qui esemplificato.
In una o più forme di attuazione, un accesso all’interfaccia fisica del bus 30 può essere fornito usando un ricetrasmettitore CAN FD 108 per il resto tradizionale.
La Figura 3 è uno schema a blocchi esemplificativo di una possibile implementazione di un dispositivo slave 20i secondo forme di attuazione.
Come esemplificato nella Figura 3, un dispositivo slave 20i può comprendere:
- un circuito controllore di protocollo e di comunicazione 201, per es. un controllore di protocollo e di comunicazione “CAN FD Light”,
- aree di memoria 202,
- un ricetrasmettitore 203, per es. un ricetrasmettitore CAN FD, per la cooperazione con il bus di comunicazione 30, e
- eventualmente altri blocchi circuitali di ECU 204. A parte gli aspetti discussi in seguito, una tale architettura per i dispositivi slave 20i è tradizionale nella tecnica, rendendo così superfluo fornire qui una descrizione più dettagliata.
Per esempio, in una o più forme di attuazione, l’implementazione del circuito controllore di protocollo e di comunicazione 201 può avvenire per mezzo di un hardware specifico per l’applicazione (“application-specific”) in modo da ridurre la necessità di processori integrati per eseguire del software.
In una o più forme di attuazione, il circuito controllore di protocollo e di comunicazione 201 può comprendere un oscillatore accurato (non visibile nella Figura 3) per l’uso nella generazione e nel campionamento dei bit di dati.
La Figura 4 è un diagramma esemplificativo di un possibile funzionamento di un circuito controllore di protocollo e di comunicazione 201, per es. un circuito controllore di protocollo e di comunicazione CAN FD Light.
Un controllore di protocollo e di comunicazione 201 come esemplificato nella Figura 4 comprende:
- un controllore di comunicazione 2010,
- un controllore di protocollo 2011, che comprende a sua volta un circuito trasmettitore 2012, un circuito contatore degli errori di trasmissione (TEC, “Transmit Error Counter”) 2013, un circuito ricevitore 2014 e un circuito contatore degli errori di ricezione (REC, “Receive Error Counter”) 2015, e
- un oscillatore 2016, opzionalmente di un tipo compensato per tensione, processo e temperatura e/o regolato in modo corrispondente.
In una o più forme di attuazione, il circuito trasmettitore 2012 e/o il circuito ricevitore 2014 possono essere configurati per cooperare con il ricetrasmettitore 203, per es. un ricetrasmettitore CAN FD, per una comunicazione sul bus 30.
In una o più forme di attuazione, il circuito trasmettitore 2012 può essere configurato per effettuare una preparazione dei frame (2012a), un riempimento con bit (“bit stuffing”) (2012b), un inserimento di CRC (2012c), un controllo degli errori del frame (2012d), un conteggio degli errori (2012e) e un riscontro (“acknowledge”) (2012f).
In una o più forme di attuazione, il circuito ricevitore 2014 può essere configurato per effettuare una decodifica di bit (campionamento – 2014a), una rilevazione degli errori (2014b), una rimozione dei bit di riempimento (“bit destuffing”) (2014c), una verifica del CRC (2014d) e una generazione dell’acknowledge (2014e).
In una o più forme di attuazione, il controllore di comunicazione 2010 può inviare, rispettivamente ricevere, dati al, rispettivamente dal, controllore di protocollo 2011 per controllare la comunicazione.
In una o più forme di attuazione, il fatto di applicare un’architettura master-slave a un bus di comunicazione 30 basato su CAN FD può fornire la possibilità di sfruttare i vantaggi del protocollo CAN FD (per es., elevata velocità di trasmissione, segnalazione differenziale robusta, CRC a scopi di sicurezza) superando nel contempo i suoi punti deboli, per esempio il requisito di una temporizzazione di clock accurata per una comunicazione multilaterale (per es., per l’arbitraggio, la segnalazione degli errori, la verifica dei frame da parte di ogni ECU), la complessità elevata e l’assenza di intervalli (“slot”) di comunicazione garantiti a causa dell’assenza di un master di comunicazione centrale.
In una o più forme di attuazione come qui esemplificate, può essere impiegata una larghezza di banda elevata (per es., 500 kbit/s, preferibilmente 1 Mbit/s) e la comunicazione può comportare di verificare i requisiti di sicurezza ASIL B (Automotive Safety Integrity Level B). Per esempio, soddisfare tali requisiti di sicurezza può essere facilitato da un valore di CRC che è inviato con ciascun frame di dati.
In una o più forme di attuazione come qui esemplificate, come risultato della ricezione di un frame di dati, per es. un “primo” messaggio inviato dal master 10 sul bus 30, i destinatari (gli slave 201, 202, …, 20n) inviano un bit di riscontro (“acknowledge”) in modo tale che almeno un bit di acknowledge sia ricevuto dal mittente (il master 10) se il sistema funziona correttamente.
Perciò, come risultato della ricezione di almeno un bit di acknowledge dagli slave 201, 202, …, 20n, il master 10 può rilevare se è ancora accoppiato alla rete di bus 30. Siccome i partecipanti della rete di bus 30 sono connessi a uno stesso filo, un trasmettitore può essere atto a rilevare se non sta funzionando correttamente, e può entrare di conseguenza in uno stato “passivo” per non disturbare la comunicazione sul bus.
In una o più forme di attuazione, un partecipante della rete di bus 30 in uno stato passivo (per es., recessivo) può essere in grado di rilevare il valore della tensione differenziale del bus, ma può non essere in grado di pilotare il bus, vale a dire può non essere in grado di forzare un certo valore della tensione differenziale del bus.
In una o più forme di attuazione, il clock di campionamento dei dati può essere generato individualmente nei circuiti ricevitori. Sarà quindi vantaggiosa una densità di fronti minima dello stream di dati, per es., con un fronte da recessivo a dominante almeno ogni per es. 10° bit, facilitando così una sincronizzazione del circuito ricevitore con lo stream di dati.
In una o più forme di attuazione, una rete di bus differenziale facilita un trasferimento di dati “robusto” a basso costo. In una o più forme di attuazione, può anche essere implementato un risveglio (“wake-up”) tramite la rete, e gli slave 201, 202, …, 20n possono essere risvegliati usando uno schema di wake-up (WUP, “Wake-Up Pattern”) secondo lo standard ISO 11898-2:2015, per es. usando un tempo di filtro TFilter(breve).
Una o più forme di attuazione possono così trarre vantaggio da un protocollo CAN FD tradizionale, per es. a 1 Mbit/s, senza commutazione di bit rate per motivi di compatibilità. Perciò, la compatibilità può essere cercata implementando (in un controllore di protocollo CAN FD per il resto tradizionale) (soltanto) un sottoinsieme di caratteristiche di un protocollo CAN FD tradizionale (per es., non implementando la caratteristica di commutazione di bit rate).
Una rete di comunicazione come qui descritta si presta a un uso con teoricamente qualsiasi “versione” di protocollo CAN e/o CAN FD.
Per esempio, in una o più forme di attuazione come qui esemplificate:
- può essere usato (soltanto) il formato di frame di base FD (FBFF, “FD Base Frame Format”) CAN, senza dovere fare ricorso a un ID esteso, per es. al fine di aumentare il carico utile (“payload”) di dati di ciascun frame (per esempio, fino a 64 byte per frame);
- può essere supportato (soltanto) un formato di frame (FBFF), con i bit nel campo di controllo fissati e l’ID esteso (EID, bit di IDE sempre dominante), la commutazione di bit rate (BRS, sempre dominante) e l’indicazione di stato di errore (ESI, sempre dominante) che non richiedono di essere supportati: per es. un frame di FD (FDF) può essere impostato (in modo stabile) a recessivo.
In una o più forme di attuazione, il fatto di supportare (soltanto) un formato di frame, per es. il formato di frame di base CAN FD, può avere come risultato un’implementazione più semplice e può facilitare una riduzione dei costi.
Il campo di dati in un formato di frame di base CAN FD può essere lungo fino a 64 byte. A seconda del numero dei byte di dati, può essere calcolato un CRC17 o un CRC21. In una o più forme di attuazione, può essere inviato ed accettato (soltanto) un bit delimitatore di CRC.
In una o più forme di attuazione, i partecipanti 20 della rete possono comprendere un contatore degli errori di ricezione (REC) 2015 e un contatore degli errori di trasmissione (TEC) 2013.
In una o più forme di attuazione, come risultato del fatto che il contatore degli errori di ricezione 2015 nel partecipante 20i della rete tra i partecipanti 201, 202, …, 20n della rete raggiunge una certa soglia, si può assumere che l’accoppiamento del partecipante 20i della rete al bus di comunicazione 30 sia perso.
In una o più forme di attuazione, come risultato del fatto che il contatore degli errori di trasmissione nel partecipante 20i della rete tra i partecipanti 201, 202, …, 20n della rete raggiunge una certa soglia, il nodo 20i può smettere di inviare dati e può entrare in uno stato passivo (stato recessivo) per evitare di disturbare il bus.
In una o più forme di attuazione, il contatore degli errori di trasmissione di uno qualsiasi tra i partecipanti 201, 202, …, 20n della rete può essere resettato da un comando dal master 10, che può essere inviato a un certo partecipante 20i come risultato del fatto che non è ricevuto alcun dato dal nodo 20i per un certo periodo di tempo. La ricezione di un comando di reset in un certo slave 20i può sbloccare quello slave, che può essere entrato in uno stato passivo a causa per es. di qualche condizione eccezionale (per es., distorsione).
Una o più forme di attuazione possono adottare REC/TEC nella misura in cui questi sono (già) previsti nello standard “de facto” del bus CAN.
Un concetto di sicurezza di una o più forme di attuazione può essere costruito sulla struttura del protocollo master-slave e su un funzionamento che comporta l’invio di messaggi entro un dato periodo di tempo e la ricezione corretta di questi messaggi.
Una o più forme di attuazione possono contemplare circostanze come discusso in seguito.
a. Soglia di TEC superata
i. TEC in un master: il master è a conoscenza del fatto di non essere più accoppiato agli slave -> è emesso un messaggio di avvertimento (per es., al guidatore: lampada, messaggio sul cruscotto, ecc.)
ii. TEC in uno slave: un certo slave è a conoscenza della sua incapacità di inviare messaggi di diagnostica al master -> entrata in uno stato di sicurezza (fail-safe o limp-home), per es. retroilluminazione LED attivata
b. Soglia di REC superata
i. REC in un master: rete “distorta” (per es., cavi cortocircuitati o altri motivi) -> il master invierà comandi di fail-safe agli slave ed emetterà un messaggio di avvertimento (per es., al guidatore)
ii. REC in uno slave: rete “distorta” -> lo slave arresterà la comunicazione (così eviterà il rischio potenziale che il bus stia bloccando la comunicazione degli altri slave) ed entrerà nello stato di sicurezza
c. Il master invia un “primo” messaggio
i. Il master non riceve alcun riscontro -> il TEC incrementa nel master, con la stessa reazione discussa in precedenza
ii. Gli slave non ricevono “primi” messaggi in un dato periodo di tempo -> rete distorta (uguale a un malfunzionamento di REC negli slave, con la stessa reazione discussa in precedenza)
d. Il master invia un “secondo” messaggio
i. Il master non riceve alcun riscontro (ACK) -> stessa reazione discussa in precedenza
ii. Il master non riceve una risposta dallo slave indirizzato -> rete distorta (almeno nello slave interessato, con la stessa reazione discussa in precedenza) iii. Lo slave non riceve il “secondo” messaggio -> Nessuna azione; la comunicazione è verificata tramite i “primi” messaggi, con la stessa reazione discussa in precedenza a tale riguardo
e. Lo slave risponde a un “secondo” messaggio inviando un frame di diagnosi
i. Il master non riceve il frame di diagnosi entro un certo periodo di tempo o riceve una risposta distorta -> rete distorta (almeno nello slave interessato, con la stessa reazione discussa in precedenza per un malfunzionamento di REC nel master)
ii. Lo slave non riceve un riscontro: rete distorta -> stessa reazione discussa in precedenza per un malfunzionamento di TEC nello slave; nella possibile assenza di TEC negli slave (si veda anche qui di seguito), non è fornita alcuna reazione e la comunicazione è verificata dalla ricezione di “primi” messaggi provenienti dal master.
Come indicato, una o più forme di attuazione possono contemplare di “rinunciare” al concetto di REC/TEC per gli slave, mantenendolo nel contempo (soltanto) nel master, per es. come parte del protocollo CAN (FD) originale, in modo tale che (soltanto) il master valuterà il suo TEC/REC.
In una o più forme di attuazione, in una situazione di fail-safe/limp-home, gli slave (per es., i dispositivi di pilotaggio di LED delle luci posteriori in un’automobile) entreranno in uno stato di sicurezza, per es., con le luci posteriori accese (almeno parzialmente) affinché l’auto possa ancora essere vista da altri guidatori al buio, interrompendo al tempo stesso altre funzioni ausiliarie che possono aumentare il consumo di potenza, al fine di evitare per es. un surriscaldamento o altri malfunzionamenti.
Naturalmente, il tipo e la natura di una situazione di fail-safe/limp-home possono variare in funzione del genere di slave coinvolto: per es., le luci interne possono essere semplicemente spente per evitare di disturbare un guidatore durante la guida di notte.
In una o più forme di attuazione, il master può anche entrare in uno stato di sicurezza se la sua connessione di rete con il controllore principale (controllore del telaio/carrozzeria, un controllore di livello superiore) tramite il bus 107 ha insuccesso. Come risultato del fatto che il master entra in uno stato di sicurezza, il master può inviare un comando agli slave accoppiati a esso di entrare in rispettivi stati di sicurezza. Inoltre, il master può reagire a distorsioni della rete con messaggi di allarme, per es., informando il guidatore tramite messaggi sul cruscotto e/o una lampada di avviso.
In una o più forme di attuazione, qualsiasi mittente può ricevere da almeno un destinatario un bit di riscontro (“ACK”) come risultato del fatto che il ricevitore riceve correttamente un frame di dati. Pertanto, il mittente può identificare se è ancora accoppiato almeno a una parte della rete. Per esempio, il contatore degli errori di trasmissione del mittente è incrementato come risultato del fatto che non è ricevuto dal mittente alcun bit di ACK.
Per esempio, in una o più forme di attuazione come qui esemplificate, il master 10 invierà messaggi in un periodo di tempo regolare che possono essere usati come “trigger del watchdog” e/o “heartbeat” della rete. Perciò, gli slave destinatari 201, 202, …, 20n possono riconoscere se il master 10 sta comunicando. Il master 10 può richiedere periodicamente informazioni di stato da ciascuno slave 20 in connessione. Nel caso in cui uno slave 20i tra gli slave 201, 202, …, 20n non risponda alla richiesta di informazioni di stato emessa dal master 10, l‘“assenza” (per es., malfunzionamento) dello slave 20i può essere rilevata.
Per esempio, in una o più forme di attuazione come qui esemplificate, qualsiasi mittente può essere configurato per confrontare i bit che esso invia sul bus di comunicazione 30 con i bit ricevuti sul bus 30. Come risultato del fatto che i bit inviati e quelli ricevuti sono trovati non essere uguali, si può assumere la presenza di un errore e perciò il contatore degli errori di trasmissione del mittente può essere incrementato. Il nodo mittente può smettere di trasmettere dati come risultato del fatto che il TEC corrispondente raggiunge una certa soglia, facendo sì che il mittente entri in uno stato passivo.
Per esempio, in una o più forme di attuazione come qui esemplificate, può essere verificata la correttezza dei frame ricevuti, per es., verificando una o più delle caratteristiche seguenti:
- la correttezza del CRC ricevuto,
- la ricezione di un bit recessivo come delimitatore di CRC successivamente al campo di CRC,
- la correttezza del riempimento di bit del frame ricevuto.
In una o più forme di attuazione, come risultato del fatto che il CRC ricevuto non concorda con il frame ricevuto, il frame ricevuto può essere scartato e il REC del ricevitore può essere incrementato.
In una o più forme di attuazione, come risultato del fatto che il riempimento di bit del frame ricevuto è scorretto, il frame ricevuto può essere scartato e il REC del ricevitore può essere incrementato.
In una o più forme di attuazione, può essere verificata la correttezza dei frame trasmessi, per es., verificando una o più delle caratteristiche seguenti:
- l’uguaglianza tra i bit inviati e i bit ricevuti, siccome i bit inviati sono anche ricevuti dal circuito ricetrasmettitore;
- l’acknowledgment dei frame trasmessi da parte di almeno un circuito ricevitore, emettendo un bit di ACK da almeno un ricevitore.
In una o più forme di attuazione, come risultato del fatto che i bit inviati e i bit ricevuti sono trovati non essere identici, il frame trasmesso può essere considerato invalido, con la trasmissione che è annullata e il TEC del trasmettitore che è incrementato.
In una o più forme di attuazione, come risultato del fatto che il circuito trasmettitore non riesce a ricevere alcun bit di ACK dai ricevitori, il frame trasmesso può essere considerato come non ricevuto da nessuno dei ricevitori, il TEC del trasmettitore può essere incrementato e il frame trasmesso può non essere inviato di nuovo.
In una o più forme di attuazione, gli oscillatori 2016 dei dispositivi slave 201, 202, …, 20n possono avere una deviazione massima consentita della loro frequenza di oscillazione, per esempio ±2% del valore atteso. Perciò, lo scostamento (“offset”) massimo di frequenza tra due slave in una o più forme di attuazione può raggiungere un valore massimo, per esempio fino al ±4% della frequenza di oscillazione.
In una o più forme di attuazione, può non essere previsto che i frame inviati da uno slave siano decodificati da un altro slave sullo stesso bus di comunicazione 30. Come risultato del fatto che uno slave riceve un frame inviato da un altro slave, il contatore degli errori di ricezione del primo slave può incrementare. Frame di errore non sono trasmessi dagli slave, così la comunicazione non è distorta.
Perciò, in una o più forme di attuazione, il REC di un ricevitore può essere diminuito come risultato della ricezione di un frame privo di errori, secondo la lunghezza di tale frame ricevuto, come esemplificato nella Tabella 1 in seguito.
In una o più forme di attuazione, il REC di un ricevitore può essere diminuito di una unità per codici di lunghezza di dati (DLC “Data Length Code”) fino a 8, per es. secondo un CAN Partial Networking (CAN PN), che funziona con il formato di frame esteso CAN (CEFF “CAN Extended Frame Format”) tradizionale. Nel caso di frame più lunghi, il REC può essere decrementato secondo il numero di carichi utili di dati (“data payloads”) del frame CAN tradizionale. In una o più forme di attuazione, si può tenere conto di tale comportamento nel controllore di comunicazione 2010, siccome molti frame che hanno origine dagli slave possono non essere riconosciuti dagli altri slave nel bus di comunicazione 30. Nel caso peggiore, (tutti) i frame che hanno origine da slave possono non essere riconosciuti dagli altri slave nel bus di comunicazione 30. Inoltre, il REC dei ricevitori può essere incrementato di più di una unità per frame ricevuto, siccome gli errori di riempimento, gli errori di CRC e gli errori di delimitatore di CRC possono sommarsi tra loro.
In una o più forme di attuazione, il master invierà più pacchetti di dati da 8-byte rispetto allo slave per ogni risposta di uno slave. In effetti, in una o più forme di attuazione, le risposte degli slave possono essere più corte (per es., possono trasportare un numero inferiore di byte di dati) dei frame inviati dal master.
Al fine di “compensare” le risposte degli slave inviate da uno slave sul bus 30 che portano altri slave accoppiati al bus 30 ad aumentare il loro REC, frame lunghi inviati da un master che sono ricevuti correttamente dagli slave possono diminuire il REC degli slave di un ammontare secondo la lunghezza del frame inviato dal master, come esemplificato nella Tabella 1.
Tabella 1 - DLC e aggiornamento del REC
La Figura 5 è uno schema a blocchi esemplificativo di un possibile flusso logico che descrive il protocollo di frame “broadcast” implementato in una o più forme di attuazione, per es. per un master che invia un “primo” messaggio e uno slave che riceve tale messaggio.
Nella Figura 5, i blocchi logici che si trovano a sinistra della linea spessa verticale sono indicativi di operazioni implementate nel dispositivo master 10, e i blocchi logici che si trovano a destra della linea spessa verticale sono indicativi di operazioni implementate in un qualsiasi dispositivo slave 20i tra i dispositivi slave 201, 202, …, 20n.
Il significato dei blocchi logici nella Figura 5 è il seguente:
- 300: inviare un “primo” messaggio con ID di broadcast,
- 301: ricevere un “primo” messaggio,
- 302: rilevare un errore in un “primo” messaggio ricevuto (Y = errore rilevato, N = errore non rilevato), - 303: incrementare il REC dello slave dato un esito positivo (Y) del blocco 302,
- 304: terminare la trasmissione,
- 305: inviare un bit di ACK dato un esito negativo (N) del blocco 302,
- 306: diminuire il REC dello slave,
- 307: terminare con uno stato “ricezione riuscita”, - 308: ricevere un bit di ACK,
- 309: rilevare un errore nel bit di ACK ricevuto (Y = errore rilevato, N = errore non rilevato),
- 310: terminare con uno stato “trasmissione riuscita” dato un esito negativo (N) del blocco 309,
- 311: incrementare opzionalmente il TEC del master, e inviare un frame di errore dato un esito positivo (Y) del blocco 309,
- 312: terminare la trasmissione,
- 313: ricevere un frame di errore,
- 314: incrementare il REC dello slave,
- 315: terminare la trasmissione.
Il funzionamento descritto dallo schema a blocchi della Figura 5 è discusso anche brevemente qui di seguito per facilità di comprensione.
Come esemplificato nella Figura 5, in una o più forme di attuazione un “primo” messaggio può essere trasmesso dal master 10 agli slave 201, 202, …, 20n per impostare valori operativi, per esempio per impostare valori di attuatori.
In una forma di attuazione, un “primo” messaggio può contenere i valori di impostazione per tutti gli slave 201, 202, …, 20n connessi al bus di comunicazione 30.
In un’altra forma di attuazione, un “primo” messaggio può contenere i valori di impostazione per un sottoinsieme di slave tra tutti gli slave 201, 202, …, 20n connessi al bus di comunicazione 30, per es. anche per un singolo slave tra gli slave 201, 202, …, 20n.
In una o più forme di attuazione, il master 10 può non aspettarsi una risposta dagli slave 201, 202, …, 20n dopo l’invio di un “primo” messaggio, ma può aspettarsi almeno un bit di acknowledge da almeno uno slave, per es. nello slot di acknowledge del CAN.
In una o più forme di attuazione come qui esemplificate, come risultato del fatto che il master 10 non riesce a ricevere alcun bit di acknowledge da almeno uno slave per es. nello slot di acknowledge del CAN, il master 10 incrementerà il valore del suo contatore degli errori di trasmissione. In una o più forme di attuazione, il master 10 può anche inviare un frame di errore sul bus di comunicazione 30.
In una o più forme di attuazione come qui esemplificate, gli slave 201, 202, …, 20n possono verificare l’integrità di un “primo” messaggio ricevuto e possono inviare un bit di acknowledge se il “primo” messaggio ricevuto è privo di errori, con il “primo” messaggio considerato valido in tal caso. In una o più forme di attuazione, la ricezione di un frame di errore aggiuntivo avrà come risultato che il contatore degli errori di ricezione è incrementato senza alcuna reazione aggiuntiva.
In una o più forme di attuazione, gli slave 201, 202, …, 20n possono prendere i dati dal “primo” messaggio che sono validi per loro. In una o più forme di attuazione, i “primi” messaggi possono trasportare un ID di broadcast, per es. nel campo di ID standard di un messaggio CAN.
La Figura 6 è uno schema a blocchi esemplificativo di un possibile flusso logico che descrive il protocollo di frame di diagnosi implementato in una o più forme di attuazione, per es., per un master che invia un “secondo” messaggio e uno slave che riceve tale messaggio e reagisce a esso.
Come nella Figura 5, i blocchi logici che si trovano a sinistra della linea spessa verticale nella Figura 6 sono indicativi di operazioni implementate nel dispositivo master 10, e blocchi logici che si trovano a destra della linea spessa verticale sono indicativi di operazioni implementate in un qualsiasi dispositivo slave 20i tra i dispositivi slave 201, 202, …, 20n.
Il significato dei blocchi logici nella Figura 6 è il seguente:
- 400: inviare un “secondo” messaggio con un ID dello slave (bersaglio),
- 401: ricevere il “secondo” messaggio,
- 402: rilevare un errore nel “secondo” messaggio ricevuto (Y = errore rilevato, N = errore non rilevato), - 403: incrementare il REC dello slave dato un esito positivo (Y) del blocco 402,
- 404: terminare la trasmissione,
- 405: inviare un bit di ACK dato un esito negativo (N) del blocco 402,
- 406: decrementare il REC dello slave,
- 407: attendere una inattività del bus per 10 bit, - 408: rilevare un errore (Y = errore rilevato, N = errore non rilevato),
- 409: inviare un messaggio di reazione con l’ID dello slave,
- 410: ricevere un bit di ACK,
- 411: rilevare un errore nel bit di ACK ricevuto (Y = errore rilevato, N = errore non rilevato),
- 412: incrementare il TEC del master e inviare un frame di errore dato un esito positivo (Y) del blocco 411, - 413: ricevere il frame di errore,
- 414: incrementare il REC dello slave,
- 415: terminare la trasmissione,
- 416: attendere TREC,
- 417: verificare se è raggiunto un timeout di TREC (Y = timeout di TREC raggiunto, N = timeout di TREC non raggiunto),
- 418: innescare un fallimento del watchdog dato un esito positivo (Y) del blocco 417,
- 419: ricevere un messaggio di reazione dato un esito negativo (N) del blocco 417,
- 420: rilevare un errore nel messaggio di reazione ricevuto (Y = errore rilevato, N = errore non rilevato), - 421: incrementare il REC del master e inviare un frame di errore dato un esito positivo (Y) del blocco 420, - 422: ricevere il frame di errore,
- 423: incrementare il TEC e il REC dello slave,
- 424: terminare la trasmissione,
- 425: inviare un bit di ACK dato un esito negativo (N) del blocco 420,
- 426: decrementare il REC del master,
- 427: terminare con uno stato “ricezione riuscita”, - 428: ricevere il bit di ACK,
- 429: rilevare un errore nel bit di ACK ricevuto (Y = errore rilevato, N = errore non rilevato),
- 430: incrementare il TEC dello slave dato un esito positivo (Y) del blocco 429,
- 431: terminare la trasmissione,
- 432: decrementare il TEC dello slave dato un esito negativo (N) del blocco 429,
- 433: terminare con uno stato “trasmissione riuscita”.
Il funzionamento descritto dallo schema a blocchi della Figura 6 è discusso anche brevemente in seguito per facilità di comprensione.
Come esemplificato nella Figura 6, in una o più forme di attuazione, il master 10 può inviare un “secondo” messaggio per richiedere dati di diagnosi da un certo slave 20i tra gli slave 201, 202, …, 20n connessi al bus di comunicazione 30 includendo l’ID dello slave di identificazione dello slave 20i nell’ID del messaggio, per es. nel campo ID standard di un messaggio CAN. Il master 10 può attendere la risposta, per es. un messaggio di reazione, dallo slave indirizzato entro una specifica finestra di tempo TREC. Come risultato del fatto che il master 10 non riceve una risposta entro quella finestra di tempo TREC, può essere innescato un errore di watchdog.
In una o più forme di attuazione, come risultato di una ricezione corretta di un “secondo” messaggio inviato dal master 10 sul bus 30, lo slave 20i replica con un bit di ACK nell’intervallo di ACK e invia un suo messaggio di reazione dopo avere atteso per un certo intervallo di tempo, per es. almeno 10 bit di inattività del bus.
In una o più forme di attuazione, altri slave tra gli slave 201, 202, …, 20n possono ricevere in maniera errata messaggi di reazione (per es., a causa dell’offset di frequenza dei rispettivi oscillatori rispetto alla frequenza del master 10). Come risultato di una ricezione errata di tali messaggi di reazione, i REC degli slave destinatari 201, 202, …, 20n possono essere incrementati.
In una o più forme di attuazione come qui esemplificate, gli slave non indirizzati dai “secondi” messaggi emessi dal master 10 non risponderanno e ignoreranno i messaggi di reazione inviati dagli slave indirizzati.
In una o più forme di attuazione come qui esemplificate, frame saranno trasmessi dagli slave 201, 202, …, 20n (soltanto) su richiesta del master 10. Perciò, gli slave 201, 202, …, 20n non ritrasmetteranno alcun frame nel caso in cui si verifichi un errore.
In una o più forme di attuazione come qui esemplificate, i “secondi” messaggi possono essere etichettati con l’ID dello slave indirizzato. Opzionalmente, i “secondi” messaggi possono essere etichettati come frame broadcast usando i bit di ID inutilizzati nel campo di ID standard (per es., i 10 bit inferiori del campo di ID standard possono indicare lo slave indirizzato, mentre l’11° bit può contrassegnare il frame come un frame broadcast).
La Figura 7 è uno schema a blocchi esemplificativo di un possibile flusso logico che descrive il protocollo dei frame di errore e di sovraccarico implementato in una o più forme di attuazione.
Come nelle Figure 5 e 6, i blocchi logici che si trovano a sinistra della linea spessa verticale nella Figura 7 sono indicativi di operazioni implementate nel dispositivo master 10, e i blocchi logici che si trovano a destra della linea spessa verticale sono indicativi di operazioni implementate in un qualsiasi dispositivo slave 20i tra i dispositivi slave 201, 202, …, 20n.
Il significato dei blocchi logici nella Figura 7 è il seguente:
- 500: rilevare un errore (Y = errore rilevato, N = errore non rilevato),
- 501: terminare con uno stato “trasmissione riuscita” dato un esito negativo (N) del blocco 500,
- 502: incrementare il TEC del master e inviare un frame di errore dato un esito positivo (Y) del blocco 500, - 503: terminare la trasmissione,
- 504: ricevere il frame di errore,
- 505: incrementare il REC dello slave,
- 506: terminare la trasmissione.
Il funzionamento descritto dallo schema a blocchi della Figura 7 è discusso anche brevemente in seguito per facilità di comprensione.
In una o più forme di attuazione, frame di errore sono inviati (soltanto) dal master 10, non dagli slave 201, 202, …, 20n. Il fatto di ricevere un frame di errore può condurre a incrementare di uno i REC degli slave. Lo stesso comportamento può essere applicato nel caso di frame di sovraccarico, che sono trattati come frame di errore.
In una o più forme di attuazione, i partecipanti del bus (gli slave 201, 202, …, 20n) possono non arbitrare la comunicazione sul bus 30, siccome la comunicazione può essere iniziata e/o controllata (soltanto) dal master 10.
In una o più forme di attuazione come qui esemplificate, qualsiasi collisione sul bus 30 condurrà a un incremento di un contatore degli errori associato. Il master 10 può rilevare collisioni come errori e può incrementare il suo contatore degli errori di trasmissione, senza inviare necessariamente di nuovo il frame. Uno slave tra gli slave 201, 202, …, 20n può rilevare bit errati sul bus 30 (per es., un bit dominante invece di uno recessivo atteso) e può incrementare il suo contatore degli errori di trasmissione.
Si può notare che i messaggi di errore sono, per così dire, un errore essi stessi, vale a dire che possono non essere conformi ai requisiti del protocollo CAN. Essi possono essere semplicemente un insieme di, per es. sei, bit dominanti di fila. Così, possono essere visti come un errore e scartati, senza alcuna reazione a questi da parte dello slave.
Un concetto alla base di una o più forme di attuazione è di resettare il timer di watchdog (soltanto) a una ricezione corretta di un “primo” messaggio e/o di un “secondo” messaggio, nella misura in cui i “primi” messaggi e i “secondi” messaggi sono i (soli) messaggi che sono inviati dal master.
La Figura 8 è uno schema a blocchi indicativo di una possibile implementazione di un ciclo di comunicazione di un’unità master 10 in una o più forme di attuazione.
Il significato dei blocchi logici nella Figura 8 è il seguente:
- 600: iniziare la comunicazione,
- 601: decidere se dovrebbe essere emessa una richiesta di dati di diagnosi a uno slave 20i (Y = emettere una richiesta di dati di diagnosi allo slave 20i, N = non emettere una richiesta di dati di diagnosi allo slave 20i), - 602: inviare un “secondo” messaggio allo slave 20i dato un esito positivo (Y) del blocco 601,
- 603: resettare il timer di watchdog dello slave 20i, - 604: verificare se è ricevuto un messaggio di reazione con dati di diagnosi dallo slave 20i (Y = dati di diagnosi ricevuti, N = dati di diagnosi non ricevuti),
- 605: verificare se il timer di watchdog dello slave 20i è scaduto (Y = watchdog scaduto, N = watchdog non scaduto),
- 606: rilevare un timeout del watchdog per lo slave 20i, dato un esito positivo (Y) del blocco 605,
- 607: inviare un “primo messaggio”, dato un esito negativo (N) del blocco 601,
- 608: attendere opzionalmente per Twait.
In una o più forme di attuazione, il master 10 può inviare “primi” messaggi, per es. per l’impostazione degli attuatori, (per es., ciclicamente) agli slave 201, 202, …, 20n, che possono usare un tale ciclo come un innesco del watchdog. Come risultato del fatto che un “primo” messaggio non è ricevuto da uno slave 20i entro il tempo di watchdog, può essere rilevato un timeout del watchdog. Come risultato del fatto che è rilevato un timeout del watchdog, lo slave 20i può entrare in uno stato di sicurezza (fail-safe).
In una o più forme di attuazione, il master 10 può richiedere dati di diagnosi da un certo slave 20i indirizzato. Come risultato del fatto che lo slave 20i indirizzato non risponde entro un certo ammontare di tempo, può essere innescato un timeout del watchdog, così il master può agire in merito a una perdita di comunicazione con lo slave 20i.
In una o più forme di attuazione come qui esemplificate, possono essere inviati dati agli slave 201, 202, …, 20n in almeno due modi differenti.
In un primo caso, un “primo” messaggio può essere inviato dal master 10 a tutti gli slave 201, 202, …, 20n. In tal caso, il dispositivo master 10 può non aspettarsi una risposta dagli slave 201, 202, …, 20n.
In un secondo caso, un “secondo” messaggio può essere inviato dal master 10 a uno specifico slave 20i. Gli slave 201, 202, …, 20n possono trattare un “secondo” messaggio come un frame broadcast, per es. per l’impostazione degli attuatori. (Soltanto) lo slave indirizzato può così reagire a un “secondo” messaggio inviando indietro i suoi dati di diagnosi in un messaggio di reazione. Tali dati di diagnosi saranno ignorati dagli altri slave sul bus 30. A causa dell’offset di frequenza tra gli slave, il messaggio di reazione inviato da uno degli slave può essere visto come un frame erroneo dagli altri slave e può condurre a un incremento dei loro rispettivi REC.
In una o più forme di attuazione, il “secondo” messaggio può anche essere un frame dedicato che può essere ignorato dagli altri slave.
In una o più forme di attuazione, i “primi” messaggi possono usare un ID di broadcast specificato e i “secondi” messaggi possono contenere l’ID dello slave indirizzato.
In una o più forme di attuazione, i bit rimanenti disponibili nel campo di ID standard possono essere usati per distinguere tra una richiesta di diagnosi con l’invio di dati agli slave e una richiesta specifica soltanto per lo slave indirizzato.
La Figura 9 è uno schema a blocchi indicativo di una possibile implementazione di un ciclo di comunicazione delle unità slave 201, 202, …, 20n in una o più forme di attuazione.
Il significato dei blocchi logici nella Figura 9 è il seguente:
- 700: iniziare una comunicazione,
- 701: resettare il timer di watchdog,
- 702: rilevare se è ricevuto un messaggio valido (Y = messaggio valido ricevuto, N = nessun messaggio valido ricevuto),
- 703: determinare se il messaggio valido ricevuto è un “primo” messaggio o un “secondo” messaggio, dato un esito positivo (Y) del blocco 702 (Y = “primo” messaggio ricevuto, N = “secondo” messaggio ricevuto),
- 704: inviare un messaggio di reazione con dati di diagnosi dato un esito negativo (N) del blocco 703,
- 705: verificare se il watchdog è scaduto, dato un esito negativo (N) del blocco 702 (Y = watchdog scaduto, N = watchdog non scaduto),
- 706: emettere un errore di watchdog, dato un esito positivo (Y) del blocco 705.
In una o più forme di attuazione, il master 10 invia dati agli slave 201, 202, …, 20n (per es., ciclicamente). Tali dati possono essere usati dagli slave per resettare rispettivi watchdog. Nel caso in cui non sia ricevuto da uno slave alcun frame capace di resettare il rispettivo watchdog prima che il watchdog scada, può essere impostato un errore di watchdog. Tale errore di watchdog può essere usato dallo slave per entrare in uno stato di sicurezza.
In una o più forme di attuazione, come risultato del fatto che uno slave 20i riceve un “secondo” messaggio indirizzato a esso, uno slave 20i destinatario risponderà inviando un messaggio di reazione che contiene i dati di diagnosi richiesti.
In una o più forme di attuazione, un master 10 può inviare per es. 64 byte (cioè, 512 bit, un byte essendo uguale a 8 bit) di dati in un singolo frame di dati. I partecipanti del bus, per es. gli slave 201, 202, …, 20n, riceveranno tali dati inviati dal master 10. Perciò, uno slave può “prendere” le informazioni di cui ha necessità da un qualsiasi insieme dei 512 bit di dati ricevuti dal master 10. Questo genere di frame è chiamato un “primo” messaggio.
Il numero dei bit che uno slave può leggere in un certo “primo” messaggio può variare a seconda della specifica forma di attuazione del bus di comunicazione. La posizione dei dati di un certo slave può essere determinata durante una sequenza di inizializzazione.
Per esempio, ciascuno slave può leggere 8 bit di dati in un “primo” messaggio. Se l’ammontare totale dei dati inviati dal master 10 in un certo “primo” messaggio è uguale, per es., a 64 byte (cioè, 512 bit), possono essere forniti dati a fino a 64 slave per “primo” messaggio. Una volta che l’ammontare di dati inviati dal master 10 in un “primo” messaggio così come l’ammontare di dati letti dagli slave in un “primo” messaggio sono definiti, un numero massimo di slave indirizzabili con un “primo” messaggio può essere definito in modo corrispondente.
In una o più forme di attuazione, il numero dei possibili partecipanti del bus (cioè, il numero degli slave) può essere aumentato fornendo “catene” di slave. In tal caso, un primo “primo” messaggio può indirizzare una prima catena di slave (che comprende, per es., 64 slave), un secondo “primo” messaggio può indirizzare una seconda catena di slave, e così via. Le catene di slave possono essere indirizzate con un ID dedicato nel campo di ID del messaggio, per es. un campo di ID CAN FD.
In una o più forme di attuazione, uno slave può essere indirizzato individualmente usando il suo indirizzo di slave e lo slave indirizzato reagirà a questo frame di richiesta di diagnosi.
In una o più forme di attuazione, il fatto di integrare un protocollo come, per es., il protocollo ST SPI (Serial Peripheral Interface) 4.1 sviluppato da aziende del Gruppo ST nei dati dei “secondi” messaggi inviati dal master 10 e dei messaggi di reazione inviati dagli slave 201, 202, …, 20n faciliterà la lettura e la scrittura di certi dati a certi indirizzi.
In una o più forme di attuazione, un comando SPI secondo il protocollo ST SPI integrato nei dati del “secondo” messaggio dal master può consistere in un indirizzo della memoria e un numero di byte di dati per la richiesta (lettura/scrittura). Lo slave può rispondere secondo il protocollo ST SPI con uno specifico byte in luogo dell’indirizzo, e con i byte di dati dell’indirizzo di memoria richiesto. Tale specifico byte è chiamato il “byte di stato globale” (GSB, “Global Status Byte”) e contiene bit di stato importanti, tali bit di stato essendo indicativi, per es., di un errore che si è verificato, di un reset che si è verificato, ecc. Pertanto, il registro di stato globale può essere inviato indietro con ogni risposta di diagnosi.
In una o più forme di attuazione, “primi” messaggi sono trasmessi dal master 10 a (tutti) gli slave 201, 202, …, 20n nella rete di bus 30. Il campo di ID di un “primo” messaggio può contenere il numero di identificazione di una catena che è indirizzata dal “primo” messaggio. Gli slave che appartengono alla catena indirizzata possono prendere i loro dati dai dati trasferiti dal frame (per es., un massimo di 64 byte di dati). Il numero dei bit di dati letti da uno slave sarà definito all’implementazione della funzione (per es., essendo un cosiddetto valore codificato in hardware (“hard-coded”)). La posizione dei dati diretti a un certo slave di una catena indirizzata nel campo di dati complessivo di un “primo” messaggio può essere determinata durante l’inizializzazione della catena.
In una o più forme di attuazione, un “primo” messaggio può usare, per esempio, un frame ID di 11 bit che parte con un ‘1’ seguito da tre ‘1’ e dal numero di identificazione della catena indirizzata, per es. un numero di 7 bit. Per esempio, il fatto di usare numeri di identificazione delle catene codificati, per es., con cinque bit consente l’identificazione e l’assegnazione di fino a 64 catene di slave, con ciascuna catena che comprende, per es., fino a 63 slave.
In una o più forme di attuazione, un “primo” messaggio specifico, chiamato qui “frame di inizializzazione”, può essere inviato agli slave 201, 202, …, 20n nel bus di comunicazione 30 per impostare la loro “appartenenza” a una certa catena e le loro posizioni relative all’interno della catena. Come risultato della ricezione di un frame di inizializzazione, gli slave saranno messi in condizione di leggere i dati previsti per loro dai frame broadcast ricevuti sul bus di comunicazione 30. Per esempio, il numero dei bit letti da uno slave in un certo “primo” messaggio può essere lo stesso per tutti gli slave e può essere definito all’implementazione del bus (per es., un valore hard-coded).
In una o più forme di attuazione, l’ID per un frame di inizializzazione della catena può essere, per es., “1_0110_0000_00”.
In una o più forme di attuazione, uno slave può leggere per es. tre byte di dati da un frame di inizializzazione, per esempio il primo byte essendo indicativo della catena alla quale appartiene, il secondo byte essendo indicativo della sua posizione all’interno della catena, e il terzo byte essendo indicativo dello slave indirizzato. Perciò, un singolo frame di inizializzazione può essere usato per inizializzare un numero limitato di slave, a seconda della dimensione in byte del campo di dati del frame di inizializzazione e dell’ammontare di dati necessario per inizializzare in modo appropriato uno slave. Per esempio, se il campo di dati del frame di inizializzazione è lungo, per es., 64 byte e uno slave ha necessità, per es., di 3 byte di dati per essere inizializzato correttamente, fino a 21 slave possono essere inizializzati con un frame CAN FD.
In una o più forme di attuazione, uno schema di wakeup (WUP) può essere implementato come un “primo” messaggio specifico. L’ID di uno schema di wake-up può essere selezionato in modo da soddisfare i requisiti dello schema di wake-up di ISO11898-2, per es. con TFilter(breve) a 1 Mbit/s. Nel caso in cui il bus di comunicazione sia fatto funzionare a bit rate più bassi, può essere usato TFilter(lungo).
In una o più forme di attuazione, l’ID di WUP riservato può essere “1_000_111_0000”. Lo schema di wake-up può essere ripetuto o ribadito nei byte di dati opzionali del frame di wake-up.
In una o più forme di attuazione, un master 10 può richiedere dati da un particolare slave 20i inviando un “secondo” messaggio, che può essere selezionato in modo da essere un frame CAN FD. L’ID di CAN FD di un “secondo” messaggio può contenere l’ID dello slave, per es. un ID dello slave a 9 bit, così come un bit che identifica tale frame come un “secondo” messaggio e un bit che identifica tale frame come un frame unicast.
In una o più forme di attuazione, il bit più significativo (MSB, “Most Significant Bit”) degli ID di CAN FD usati nel bus 30 può essere uguale a “0” se è identificato un cosiddetto frame “unicast”, cioè un frame indirizzato soltanto a un certo slave, e può essere uguale a “1” se è identificato un cosiddetto frame “broadcast”, cioè un frame indirizzato a tutti gli slave, ivi comprendendo anche frame di inizializzazione della catena e frame di wake-up. Si apprezzerà che un riferimento rispettivamente a valori di “1” e di “0”, è puramente a titolo di esempio: una o più forme di attuazione possono adottare in effetti una scelta complementare (per es., rispettivamente valori di “0” e di “1”).
In una o più forme di attuazione, come risultato del fatto che un frame unicast non contiene alcun dato, lo slave indirizzato può trasmettere i dati di diagnosi di default, come definiti all’implementazione. Altrimenti, nel caso in cui un frame unicast contenga dati, tali dati saranno un comando SPI secondo il protocollo ST SPI 4.1.
In una o più forme di attuazione, uno slave che riceve un frame unicast che contiene un comando SPI come definito in precedenza replicherà con i dati richiesti dal “secondo” messaggio codificati con il protocollo ST SPI 4.1.
In una o più forme di attuazione, un master 10 può indirizzare uno slave 20i inviando un frame che contiene l’ID dello slave nel campo di ID CAN FD. I byte di dati opzionali possono contenere un frame ST SPI SDI (ST Serial Peripheral Interface Serial Data Input).
In una o più forme di attuazione, uno slave 20i può rispondere a un “secondo” messaggio ricevuto inviando un messaggio di reazione, per es. un frame di risposta di diagnosi, sul bus di comunicazione 30. Il messaggio di reazione può essere selezionato in modo da essere un frame CAN FD. L’ID di CAN FD di un messaggio di reazione può contenere l’ID dello slave, per es. un ID dello slave a 9 bit, così come un bit che identifica tale frame come un messaggio di reazione e un bit che identifica tale frame come un frame unicast.
In una o più forme di attuazione, i byte di dati di un messaggio di reazione possono contenere un frame ST SPI SDO (Serial Peripheral Interface Serial Data Output come sviluppato da società del gruppo ST). Nel caso in cui il “secondo” messaggio ricevuto da uno slave non contenga dati nel campo di dati del frame, lo slave può rispondere al “secondo” messaggio ricevuto con un frame CAN FD, i cui byte di dati possono contenere soltanto il GSB (Global Status Byte).
In una o più forme di attuazione, nel manuale del dispositivo possono essere usate e specificate differenti risposte di default.
Usi possibili del frame ID, per es. un frame ID standard CAN FD, in forme di attuazione sono rappresentati a titolo esemplificativo nella Tabella 2 qui di seguito.
Tabella 2 - Panoramica dei frame ID
In una o più forme di attuazione, un controllore di protocollo può implementare il protocollo CAN FD come descritto precedentemente.
In una o più forme di attuazione, possono essere usati blocchi elementari per implementare una rilevazione di un frame di Wake-Up CAN FD che possono essere modificati per facilitare l’implementazione di una struttura di comunicazione master/slave semplificata, in cui gli slave rispondono (soltanto) su richiesta del master.
Come già indicato:
- i “primi” messaggi discussi in tutta questa descrizione corrispondono sostanzialmente a messaggi broadcast come trasmessi tradizionalmente in un protocollo basato su messaggi come, per es., un protocollo di bus CAN dove i messaggi trasmessi sul bus da un dispositivo sono ricevuti (simultaneamente) da (tutti) gli altri dispositivi, con questi ultimi dispositivi atti a implementare rispettive operazioni in funzione di porzioni di dati operativi convogliati da tali messaggi broadcast, - similmente, sebbene inviati per così dire “fisicamente” in modalità broadcast sul bus da un dispositivo (master), i secondi messaggi discussi in tutta questa descrizione sono in effetti indirizzati “logicamente” a singoli altri dispositivi (slave) sostanzialmente come messaggi di richiesta per cui ai dispositivi slave è richiesto di reagire inviando verso il dispositivo master – entro un certo intervallo di tempo – una rispettiva risposta come per es. un messaggio di diagnostica, con possibili collisioni di tali risposte evitate nella misura in cui il dispositivo master alloca rispettivi intervalli di risposta, non in collisione, ai dispositivi slave.
I primi messaggi possono così essere considerati come veri messaggi “broadcast”; per contro, sebbene inviati fisicamente in modalità broadcast sul bus 30 da un dispositivo (master), i secondi messaggi possono essere considerati sostanzialmente come messaggi “unicast”, nella misura in cui sono indirizzati logicamente a singoli dispositivi slave.
In una o più forme di attuazione, un procedimento può comprendere:
- accoppiare un primo dispositivo (per es., 10) e un insieme di secondi dispositivi (per es., 201, 202, …, 20n) tramite un bus (per es., 30),
- configurare il primo dispositivo come un dispositivo master per trasmettere sul bus:
- a) primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative di operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi, e
- b) secondi messaggi indirizzati a secondi dispositivi nell’insieme di secondi dispositivi, i secondi messaggi convogliando identificatori che identificano i rispettivi secondi dispositivi ai quali sono indirizzati i secondi messaggi che richiedono rispettive reazioni verso il primo dispositivo entro rispettivi intervalli di reazione attesi, e
- configurare i secondi dispositivi come dispositivi slave:
- c) per ricevere sul bus i primi messaggi trasmessi dal primo dispositivo configurato come dispositivo master, leggere rispettive porzioni di messaggio di dati operativi nell’insieme di porzioni di messaggio di dati operativi e implementare rispettive operazioni in funzione delle rispettive porzioni di messaggio di dati operativi lette, - d) per ricevere sul bus i secondi messaggi trasmessi dal primo dispositivo configurato come dispositivo master e reagire a essi entro i rispettivi intervalli di reazione attesi trasmettendo sul bus messaggi di reazione verso il primo dispositivo configurato come dispositivo master.
In una o più forme di attuazione, un primo dispositivo configurato come dispositivo master può trasmettere su un bus messaggi di inizializzazione che comprendono dati di inizializzazione indicativi di quali porzioni di messaggio di dati operativi nei primi messaggi trasmessi sul bus dal primo dispositivo configurato come dispositivo master sono dedicate ai rispettivi secondi dispositivi configurati come dispositivi slave, e secondi dispositivi configurati come dispositivi slave possono ricevere i messaggi di inizializzazione trasmessi sul bus dal primo dispositivo configurato come dispositivo master e possono eseguire una inizializzazione in funzione dei dati di inizializzazione per leggere rispettive porzioni di messaggio di dati operativi dedicate a essi nell’insieme di porzioni di messaggio di dati operativi.
In una o più forme di attuazione, un procedimento può comprendere disporre secondi dispositivi in un insieme di secondi dispositivi configurati come dispositivi slave in sottoinsiemi di secondi dispositivi, in cui un primo dispositivo configurato come dispositivo master può trasmettere su un bus primi messaggi che comprendono indici di identificazione dei sottoinsiemi che identificano i sottoinsiemi dei secondi dispositivi ai quali sono dedicati primi messaggi operativi.
In una o più forme di attuazione, un primo dispositivo configurato come dispositivo master può trasmettere primi messaggi su un bus a una cadenza (“rate”) costante.
In una o più forme di attuazione, secondi dispositivi in un insieme di secondi dispositivi possono commutare a uno stato di sicurezza come risultato dello scadere di rispettivi timer di watchdog.
In una o più forme di attuazione, secondi dispositivi in un insieme di secondi dispositivi possono resettare rispettivi timer di watchdog come risultato della ricezione da un primo dispositivo configurato come dispositivo master di messaggi selezionati tra primi messaggi e secondi messaggi.
In una o più forme di attuazione, un primo dispositivo può essere sensibile a rispettive reazioni da secondi dispositivi in un insieme di secondi dispositivi richieste che non riescono a raggiungere il primo dispositivo entro rispettivi intervalli di reazione attesi, e/o può innescare rispettivi segnali di errore di watchdog indicativi di secondi dispositivi in un insieme di secondi dispositivi da cui rispettive reazioni non riescono a raggiungere il primo dispositivo entro rispettivi intervalli di reazione attesi.
In una o più forme di attuazione, un bus può comprendere un bus con cablaggio differenziale.
In una o più forme di attuazione, un sistema può comprendere un primo dispositivo (per es., 10) e un insieme di secondi dispositivi (per es., 201, 202, …, 20n) accoppiati tramite un bus (per es., 30), in cui il primo dispositivo e i secondi dispositivi possono essere configurati rispettivamente come un dispositivo master e dispositivi slave, e il dispositivo master e i dispositivi slave possono essere configurati per funzionare con il procedimento secondo una o più forme di attuazione.
In una o più forme di attuazione, un dispositivo (per es., 10) per l’accoppiamento come un primo dispositivo a un insieme di secondi dispositivi (per es., 201, 202, …, 20n) tramite un bus (per es., 30) può essere configurato per trasmettere sul bus:
- primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative delle operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi, e
- secondi messaggi indirizzati a secondi dispositivi nell’insieme di secondi dispositivi, i secondi messaggi richiedendo rispettive reazioni verso il primo dispositivo entro rispettivi intervalli di reazione attesi, i secondi messaggi convogliando identificatori che identificano i rispettivi secondi dispositivi ai quali sono indirizzati i secondi messaggi.
In una o più forme di attuazione, un dispositivo per l’accoppiamento come un primo dispositivo a un insieme di secondi dispositivi tramite un bus può essere sensibile a rispettive reazioni da secondi dispositivi nell’insieme di secondi dispositivi richieste che non riescono a raggiungere il primo dispositivo entro rispettivi intervalli di reazione attesi, e/o può essere configurato per innescare rispettivi segnali di errore di watchdog indicativi di secondi dispositivi nell’insieme di secondi dispositivi dai quali rispettive reazioni non riescono a raggiungere il primo dispositivo entro rispettivi intervalli di reazione attesi.
In una o più forme di attuazione, un dispositivo (per es., 20i) per l’inclusione in un insieme di secondi dispositivi (per es., 201, 202, …, 20n) accoppiati a un primo dispositivo (per es., 10) tramite un bus (per es., 30) può essere configurato per:
- ricevere sul bus primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative di operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi, leggere almeno una rispettiva porzione di messaggio di dati operativi nell’insieme di porzioni di messaggio di dati operativi e implementare almeno una rispettiva operazione in funzione dell’almeno una rispettiva porzione di messaggio di dati operativi letta,
- ricevere sul bus rispettivi secondi messaggi che convogliano identificatori che identificano il dispositivo come quello dei secondi dispositivi a cui sono indirizzati i rispettivi secondi messaggi, i rispettivi secondi messaggi richiedendo al dispositivo rispettive reazioni verso il primo dispositivo entro rispettivi intervalli di reazione attesi, e reagire a essi entro i rispettivi intervalli di reazione attesi, in cui i messaggi di reazione dal dispositivo sono trasmessi sul bus verso il primo dispositivo configurato come dispositivo master.
In una o più forme di attuazione, un dispositivo per l’inclusione in un insieme di secondi dispositivi accoppiati a un primo dispositivo tramite un bus può essere configurato per commutare a uno stato di sicurezza come risultato dello scadere di un rispettivo timer di watchdog.
In una o più forme di attuazione, un dispositivo per l’inclusione in un insieme di secondi dispositivi accoppiati a un primo dispositivo tramite un bus può essere configurato per resettare un rispettivo timer di watchdog come risultato di messaggi dal primo dispositivo ricevuti tramite il bus.
In una o più forme di attuazione, un dispositivo per l'inclusione in un insieme di secondi dispositivi accoppiati a un primo dispositivo tramite un bus può comprendere un controllore di protocollo e di comunicazione HW (per es., 201) che comprende un hardware specifico per l’applicazione implementato in esso.
In una o più forme di attuazione, un dispositivo per l’inclusione in un insieme di secondi dispositivi accoppiati a un primo dispositivo tramite un bus può comprendere un dispositivo di pilotaggio di sorgenti di radiazione luminosa, preferibilmente un dispositivo di pilotaggio delle luci di un veicolo.
In una o più forme di attuazione, un veicolo (per es., V) può essere equipaggiato con un sistema secondo una o più forme di attuazione.
In una o più forme di attuazione, un segnale trasmissibile su un bus (per es., 30) per trasmettere messaggi da un primo dispositivo (per es., 10) a un insieme di secondi dispositivi (per es., 201, 202, …, 20n) in un sistema secondo una o più forme di attuazione può comprendere:
- primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative di operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi, e
- secondi messaggi indirizzati a secondi dispositivi nell’insieme di secondi dispositivi, i secondi messaggi richiedendo rispettive reazioni verso il primo dispositivo entro rispettivi intervalli di reazione attesi, i secondi messaggi convogliando identificatori che identificano i rispettivi secondi dispositivi ai quali sono indirizzati i secondi messaggi.
In una o più forme di attuazione, un segnale che trasmette primi messaggi che trasportano un insieme di porzioni di dati operativi dedicate a secondi dispositivi configurati come dispositivi slave può verificarsi con cadenza (“rate”) costante.
Fermi restando i principi di fondo, i dettagli e le forme di attuazione possono variare, anche in modo apprezzabile, rispetto a quanto è stato descritto, puramente a titolo di esempio, senza uscire dall’ambito di protezione.
L’ambito di protezione è definito dalle rivendicazioni annesse.

Claims (19)

  1. RIVENDICAZIONI 1. Procedimento, comprendente: - accoppiare un primo dispositivo (10) e un insieme di secondi dispositivi (201, 202, …, 20n) tramite un bus (30), - configurare il primo dispositivo (10) come un dispositivo master per trasmettere sul bus (30): - a) primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative di operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n), e - b) secondi messaggi indirizzati a secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n), i secondi messaggi convogliando identificatori che identificano i rispettivi secondi dispositivi (201, 202, …, 20n) ai quali sono indirizzati i secondi messaggi che richiedono rispettive reazioni verso il primo dispositivo (10) entro rispettivi intervalli di reazione attesi, e - configurare i secondi dispositivi (201, 202, …, 20n) come dispositivi slave: - c) per ricevere sul bus (30) i primi messaggi trasmessi dal primo dispositivo (10) configurato come dispositivo master, leggere rispettive porzioni di messaggio di dati operativi in detto insieme di porzioni di messaggio di dati operativi e implementare rispettive operazioni in funzione delle rispettive porzioni di messaggio di dati operativi lette, - d) per ricevere sul bus (30) i secondi messaggi trasmessi dal primo dispositivo (10) configurato come dispositivo master e reagire a essi entro detti rispettivi intervalli di reazione attesi trasmettendo sul bus (30) messaggi di reazione verso il primo dispositivo (10) configurato come dispositivo master.
  2. 2. Procedimento secondo la rivendicazione 1, in cui: - il primo dispositivo (10) configurato come dispositivo master trasmette sul bus (30) messaggi di inizializzazione che comprendono dati di inizializzazione indicativi di quali porzioni di messaggio di dati operativi nei primi messaggi trasmessi sul bus (30) dal primo dispositivo (10) configurato come dispositivo master sono dedicate a rispettivi secondi dispositivi (201, 202, …, 20n) configurati come dispositivi slave, - i secondi dispositivi (201, 202, …, 20n) configurati come dispositivi slave ricevono i messaggi di inizializzazione trasmessi sul bus (30) dal primo dispositivo (10) configurato come dispositivo master ed eseguono una inizializzazione in funzione di detti dati di inizializzazione per leggere rispettive porzioni di messaggio di dati operativi dedicate a essi in detto insieme di porzioni di messaggio di dati operativi.
  3. 3. Procedimento secondo la rivendicazione 1 o la rivendicazione 2, comprendente disporre detti secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n) configurati come dispositivi slave in sottoinsiemi di secondi dispositivi, in cui il primo dispositivo (10) configurato come dispositivo master trasmette sul bus (30) primi messaggi che comprendono indici di identificazione dei sottoinsiemi che identificano i sottoinsiemi di detti secondi dispositivi a cui sono dedicati i primi messaggi operativi.
  4. 4. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, in cui il primo dispositivo (10) configurato come dispositivo master trasmette detti primi messaggi sul bus (30) a una cadenza (“rate”) costante.
  5. 5. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, in cui secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n) commutano a uno stato di sicurezza (“fail-safe”) come risultato dello scadere di rispettivi timer di watchdog.
  6. 6. Procedimento secondo la rivendicazione 5, in cui secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n) resettano detti rispettivi timer di watchdog come risultato della ricezione dal primo dispositivo (10) configurato come dispositivo master di messaggi selezionati tra detti primi messaggi e detti secondi messaggi.
  7. 7. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, in cui il primo dispositivo (10): - è sensibile a rispettive reazioni da secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n) richieste che non riescono a raggiungere il primo dispositivo (10) entro detti rispettivi intervalli di reazione attesi, e/o - innesca rispettivi segnali di errore di watchdog indicativi di secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n) dai quali rispettive reazioni non riescono a raggiungere il primo dispositivo (10) entro detti rispettivi intervalli di reazione attesi.
  8. 8. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, in cui detto bus (30) comprende un bus con cablaggio differenziale.
  9. 9. Sistema comprendente un primo dispositivo (10) e un insieme di secondi dispositivi (201, 202, …, 20n) accoppiati tramite un bus (30), in cui il primo dispositivo (10) e i secondi dispositivi (201, 202, …, 20n) sono configurati rispettivamente come dispositivo master e dispositivi slave, il dispositivo master e i dispositivi slave configurati per funzionare con il procedimento secondo una qualsiasi delle rivendicazioni da 1 a 8.
  10. 10. Dispositivo (10) per l’accoppiamento come un primo dispositivo a un insieme di secondi dispositivi (201, 202, …, 20n) tramite un bus (30), il primo dispositivo configurato per trasmettere sul bus (30): - primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative di operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n), e - secondi messaggi indirizzati a secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n), i secondi messaggi richiedendo rispettive reazioni verso il primo dispositivo (10) entro rispettivi intervalli di reazione attesi, i secondi messaggi convogliando identificatori che identificano i rispettivi secondi dispositivi (201, 202, …, 20n) ai quali sono indirizzati i secondi messaggi.
  11. 11. Dispositivo (10) secondo la rivendicazione 10, in cui il dispositivo: - è sensibile a rispettive reazioni da secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n) richieste che non riescono a raggiungere il primo dispositivo (10) entro detti rispettivi intervalli di reazione attesi, e/o - è configurato per innescare rispettivi segnali di errore di watchdog indicativi di secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n) dai quali rispettive reazioni non riescono a raggiungere il primo dispositivo (10) entro detti rispettivi intervalli di reazione attesi.
  12. 12. Dispositivo (20i) per l’inclusione in un insieme di secondi dispositivi (201, 202, …, 20n) accoppiati a un primo dispositivo (10) tramite un bus (30), il dispositivo configurato per: - ricevere sul bus (30) primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative di operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n), leggere almeno una rispettiva porzione di messaggio di dati operativi in detto insieme di porzioni di messaggio di dati operativi e implementare almeno una rispettiva operazione in funzione dell’almeno una rispettiva porzione di messaggio di dati operativi letta, - ricevere sul bus (30) rispettivi secondi messaggi che convogliano identificatori che identificano il dispositivo come quello dei secondi dispositivi (201, 202, …, 20n) al quale sono indirizzati detti rispettivi secondi messaggi, i rispettivi secondi messaggi richiedendo al dispositivo rispettive reazioni verso il primo dispositivo (10) entro rispettivi intervalli di reazione attesi, e reagire a essi entro detti rispettivi intervalli di reazione attesi, in cui messaggi di reazione da detto dispositivo sono trasmessi sul bus (30) verso il primo dispositivo (10) configurato come dispositivo master.
  13. 13. Dispositivo (20i) secondo la rivendicazione 12, configurato per commutare a uno stato di sicurezza (“failsafe”) come risultato dello scadere di un rispettivo timer di watchdog.
  14. 14. Dispositivo (20i) secondo la rivendicazione 13, configurato per resettare detto rispettivo timer di watchdog come risultato di messaggi da detto primo dispositivo (10) ricevuti tramite detto bus (30).
  15. 15. Dispositivo (20i) secondo una qualsiasi delle rivendicazioni da 12 a 14, comprendente un controllore di protocollo e di comunicazione HW (201) che comprende un hardware specifico per l’applicazione implementato in esso.
  16. 16. Dispositivo (20i) secondo una qualsiasi delle rivendicazioni da 12 a 15, comprendente un dispositivo di pilotaggio di sorgenti di radiazione luminosa, preferibilmente un dispositivo di pilotaggio delle luci di un veicolo (201, 202, …, 20n).
  17. 17. Veicolo (V) equipaggiato con un sistema secondo la rivendicazione 9.
  18. 18. Segnale trasmissibile su un bus (30) per trasmettere messaggi da un primo dispositivo (10) a un insieme di secondi dispositivi (201, 202, …, 20n) in un sistema secondo la rivendicazione 9, in cui il segnale comprende: - a) primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi indicative di operazioni per l’implementazione da parte di secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n), e - b) secondi messaggi indirizzati a secondi dispositivi nell’insieme di secondi dispositivi (201, 202, …, 20n), i secondi messaggi richiedendo rispettive reazioni verso il primo dispositivo (10) entro rispettivi intervalli di reazione attesi, i secondi messaggi convogliando identificatori che identificano i rispettivi secondi dispositivi (201, 202, …, 20n) ai quali sono indirizzati i secondi messaggi.
  19. 19. Segnale secondo la rivendicazione 18, in cui detti primi messaggi che trasportano un insieme di porzioni di messaggio di dati operativi dedicate ai secondi dispositivi (201, 202, …, 20n) configurati come dispositivi slave si verificano a una cadenza (“rate”) costante.
IT102018000003980A 2018-03-26 2018-03-26 Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti IT201800003980A1 (it)

Priority Applications (12)

Application Number Priority Date Filing Date Title
IT102018000003980A IT201800003980A1 (it) 2018-03-26 2018-03-26 Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti
EP19162919.5A EP3547620B1 (en) 2018-03-26 2019-03-14 A communication method, corresponding system, devices, signal and vehicle
US16/360,229 US10678726B2 (en) 2018-03-26 2019-03-21 System and method for communication between a master device and a slave device
CN201910221331.0A CN110365564B (zh) 2018-03-26 2019-03-22 通信方法及对应的系统和设备
CN202210298149.7A CN114666183A (zh) 2018-03-26 2019-03-22 通信方法及对应的系统和设备
CN201920370576.5U CN209642692U (zh) 2018-03-26 2019-03-22 设备、主设备及从设备
JP2019057403A JP7253950B2 (ja) 2018-03-26 2019-03-25 通信方法、対応するシステム、装置、信号及び乗物
KR1020190033439A KR102370862B1 (ko) 2018-03-26 2019-03-25 통신 방법, 대응되는 시스템, 디바이스, 신호 및 자동차
US16/874,055 US11366778B2 (en) 2018-03-26 2020-05-14 System and method for communication between a master device and a slave device
US17/806,587 US11675721B2 (en) 2018-03-26 2022-06-13 System and method for communication between a master device and a slave device
JP2022185693A JP2023018057A (ja) 2018-03-26 2022-11-21 通信方法、対応するシステム、装置、信号及び乗物
US18/309,103 US20230267087A1 (en) 2018-03-26 2023-04-28 System and method for communication between a master device and a slave device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT102018000003980A IT201800003980A1 (it) 2018-03-26 2018-03-26 Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti

Publications (1)

Publication Number Publication Date
IT201800003980A1 true IT201800003980A1 (it) 2019-09-26

Family

ID=62530505

Family Applications (1)

Application Number Title Priority Date Filing Date
IT102018000003980A IT201800003980A1 (it) 2018-03-26 2018-03-26 Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti

Country Status (6)

Country Link
US (4) US10678726B2 (it)
EP (1) EP3547620B1 (it)
JP (2) JP7253950B2 (it)
KR (1) KR102370862B1 (it)
CN (3) CN110365564B (it)
IT (1) IT201800003980A1 (it)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3100629A1 (fr) 2019-09-10 2021-03-12 Stmicroelectronics (Grenoble 2) Sas Communication par bus CAN
FR3100628A1 (fr) 2019-09-10 2021-03-12 Stmicroelectronics (Grenoble 2) Sas Communication par bus CAN
FR3102584A1 (fr) 2019-10-28 2021-04-30 Stmicroelectronics (Grenoble 2) Sas Procédé d'acquittement de communication par bus

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT201800003980A1 (it) 2018-03-26 2019-09-26 Stmicroelectronics Application Gmbh Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti
TWI735928B (zh) * 2019-08-02 2021-08-11 新唐科技股份有限公司 控制裝置及調整方法
JP7215381B2 (ja) * 2019-09-20 2023-01-31 トヨタ自動車株式会社 制御装置及び通信方法
US11422962B2 (en) * 2019-12-09 2022-08-23 Thales Canada Inc. Method and system for high integrity can bus traffic supervision in safety critical application
EP3869742B1 (en) * 2020-02-20 2023-06-07 Nxp B.V. Network node
IT202000004978A1 (it) 2020-03-09 2021-09-09 Stmicroelectronics Application Gmbh Dispositivo elettronico, sistema e veicolo corrispondenti
US11526458B2 (en) 2020-05-18 2022-12-13 Stmicroelectronics Application Gmbh Method of operating a communication bus, corresponding system, devices and vehicle
DE102020121316A1 (de) * 2020-08-13 2022-02-17 Ebm-Papst Mulfingen Gmbh & Co. Kg Einheit für ein Bussystem, Master-Slave-Bussystem mit einer Vielzahl von Einheiten und Verfahren zur Adressierung von Einheiten eines Bussystems
EP4142189B1 (en) * 2020-09-23 2024-03-27 Bayerische Motoren Werke Aktiengesellschaft Determining correctness of actually received timestamp
EP3975493A1 (en) 2020-09-25 2022-03-30 STMicroelectronics S.r.l. Communication method, corresponding system and device
US11418362B2 (en) * 2020-11-25 2022-08-16 Schneider Electric It Corporation Systems and methods for group control using service data objects
CN112817886B (zh) * 2021-02-04 2023-01-24 珠海全志科技股份有限公司 基于spi的主从通信方法及装置
KR20220125897A (ko) 2021-03-05 2022-09-15 삼성전자주식회사 시스템 온 칩 및 시스템 온 칩에 포함된 연결 버스
IT202100005354A1 (it) * 2021-03-08 2022-09-08 Stmicroelectronics Application Gmbh Circuito microcontrollore, dispositivo, sistema e procedimento di funzionamento corrispondenti
DE102021106379A1 (de) * 2021-03-16 2022-09-22 Infineon Technologies Ag Master, Slave, Master-Slave-Kommunikations-System, On-Chip-Interconnect-System, Verfahren zum Betreiben eines Masters, Verfahren zum Betreiben eines Slaves, Verfahren zum Betreiben eines Master-Slave-Kommunikations-Systems und Verfahren zum Betreiben eines On-Chip-Interconnect-Systems
EP4138343B1 (en) 2021-08-20 2024-02-21 STMicroelectronics Application GmbH Processing system, related integrated circuit, device and method
CN114035524A (zh) * 2021-11-11 2022-02-11 成都卡诺普机器人技术股份有限公司 控制方法和自动控制系统
US20240025427A1 (en) * 2022-07-25 2024-01-25 Abhilash Gudapati Robust techniques for managing primary and secondary controllers on can-fd networks
US20240048404A1 (en) 2022-08-02 2024-02-08 Stmicroelectronics Application Gmbh Electronic device, corresponding bus communication system and method of configuring a bus communication system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6240478B1 (en) * 1998-10-30 2001-05-29 Eaton Corporation Apparatus and method for addressing electronic modules
EP1158718A2 (en) * 2000-05-24 2001-11-28 General Motors Corporation In-vehicle network management using virtual networks
WO2013052886A2 (en) * 2011-10-05 2013-04-11 Analog Devices, Inc. Two-wire communication system for high-speed data and power distribution

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5509122A (en) * 1992-02-20 1996-04-16 International Business Machines Corporation Configurable, recoverable parallel bus
US6467065B1 (en) * 1999-07-09 2002-10-15 Delphi Technologies, Inc. Master/slave control system and method
US20030167345A1 (en) * 2002-02-25 2003-09-04 Knight Alexander N. Communications bridge between a vehicle information network and a remote system
KR100440969B1 (ko) * 2002-05-23 2004-07-21 삼성전자주식회사 네트워킹 방법 및 그 장치
JP2004280304A (ja) 2003-03-13 2004-10-07 Omron Corp フィールドバスシステム及び通信方法並びにマスタ及びスレーブ
US7631110B2 (en) * 2006-05-03 2009-12-08 Standard Microsystems Corporation Address assignment through device ID broadcast
US8400061B2 (en) * 2007-07-17 2013-03-19 I/O Controls Corporation Control network for LED-based lighting system in a transit vehicle
US7707339B2 (en) * 2007-12-18 2010-04-27 Freescale Semiconductor, Inc. Data arbitration on a bus to determine an extreme value
JP5607219B2 (ja) * 2009-05-20 2014-10-15 ルネサスエレクトロニクス株式会社 自動車用通信システム
US8225021B2 (en) * 2009-05-28 2012-07-17 Lexmark International, Inc. Dynamic address change for slave devices on a shared bus
CN102253906B (zh) * 2010-05-18 2014-05-07 凹凸电子（武汉）有限公司 地址分配方法和地址分配系统
US20120083902A1 (en) * 2010-09-30 2012-04-05 Wolf Daum Communication system and method for communicating between master and slave devices
WO2012116802A2 (de) * 2011-03-01 2012-09-07 As-International Association E.V. Neuartige kombination von fehlerkorrektur und fehlererkennung für die übertragung digitaler daten
US9338035B2 (en) * 2011-03-07 2016-05-10 Microchip Technology Incorporated Microcontroller with can bus module and auto speed detect
US8700747B2 (en) * 2011-04-19 2014-04-15 Schneider Electric It Corporation System and method for automatically addressing devices in a multi-drop network
US8645580B2 (en) * 2011-09-06 2014-02-04 Semiconductor Components Industries, Llc Circuit and electronic module for automatic addressing
DE102014000248B3 (de) * 2014-01-08 2015-03-05 Stmicroelectronics Application Gmbh Bus-Microcontroller und Bus-Knoten-Schaltung, sowie elektronische Steuereinheit für ein Fahrzeug
KR101590272B1 (ko) * 2014-12-31 2016-01-29 엘에스산전 주식회사 Plc 시스템의 메시지 처리장치
JP6383348B2 (ja) * 2015-12-22 2018-08-29 矢崎総業株式会社 制御装置および制御システム
US10063389B2 (en) * 2016-07-07 2018-08-28 Caterpillar Inc. Identifying and configuring multiple smart devices on a CAN bus
US10382191B2 (en) * 2016-11-30 2019-08-13 Juniper Networks, Inc. Efficient unicast signaling in a precision time protocol enabled packet network
KR101866093B1 (ko) * 2016-12-06 2018-06-11 현대오트론 주식회사 슬레이브 제어기의 동작 제어 장치 및 방법
DE102018201433A1 (de) * 2018-01-31 2019-08-14 Zf Friedrichshafen Ag Übertragungssystem für Steuerdaten
IT201800003980A1 (it) * 2018-03-26 2019-09-26 Stmicroelectronics Application Gmbh Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti
JP7384705B2 (ja) 2020-02-28 2023-11-21 株式会社日立製作所 分析装置、分析方法、および分析プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6240478B1 (en) * 1998-10-30 2001-05-29 Eaton Corporation Apparatus and method for addressing electronic modules
EP1158718A2 (en) * 2000-05-24 2001-11-28 General Motors Corporation In-vehicle network management using virtual networks
WO2013052886A2 (en) * 2011-10-05 2013-04-11 Analog Devices, Inc. Two-wire communication system for high-speed data and power distribution

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3100629A1 (fr) 2019-09-10 2021-03-12 Stmicroelectronics (Grenoble 2) Sas Communication par bus CAN
FR3100628A1 (fr) 2019-09-10 2021-03-12 Stmicroelectronics (Grenoble 2) Sas Communication par bus CAN
EP3793142A1 (fr) 2019-09-10 2021-03-17 STMicroelectronics (Grenoble 2) SAS Communication par bus can
EP3793132A1 (fr) 2019-09-10 2021-03-17 STMicroelectronics (Grenoble 2) SAS Communication par bus can
FR3102584A1 (fr) 2019-10-28 2021-04-30 Stmicroelectronics (Grenoble 2) Sas Procédé d'acquittement de communication par bus
EP3816808A1 (fr) 2019-10-28 2021-05-05 Stmicroelectronics (Grenoble 2) Sas Procédé d'acquittement de communication par bus

Also Published As

Publication number Publication date
CN114666183A (zh) 2022-06-24
JP7253950B2 (ja) 2023-04-07
US11366778B2 (en) 2022-06-21
JP2023018057A (ja) 2023-02-07
JP2019176474A (ja) 2019-10-10
US20190294572A1 (en) 2019-09-26
US20220318173A1 (en) 2022-10-06
EP3547620B1 (en) 2020-11-25
KR20190112663A (ko) 2019-10-07
US10678726B2 (en) 2020-06-09
US20230267087A1 (en) 2023-08-24
CN209642692U (zh) 2019-11-15
CN110365564B (zh) 2022-04-12
KR102370862B1 (ko) 2022-03-04
US11675721B2 (en) 2023-06-13
CN110365564A (zh) 2019-10-22
US20200272589A1 (en) 2020-08-27
EP3547620A1 (en) 2019-10-02

Similar Documents

Publication Publication Date Title
IT201800003980A1 (it) Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti
CN113691430B (zh) 操作通信总线的方法、对应系统、设备以及车辆
JP5814474B2 (ja) 通信システムを駆動する方法
US8306004B2 (en) Communication network system having high-ranking network and low-ranking networks, interchange terminal connecting high-ranking network and low-ranking network, microcomputer controlling connection between transmission line of low-ranking network and transmission line of high-ranking network, and communication transmitter-receiver connected with transmission line of low-ranking network and transmission line of high-ranking network
JP5444207B2 (ja) 巡回伝送すべき処理データの安全な伝送のための方法およびシステム
CN111200844A (zh) 一种多从机双向通讯方法
US11729021B2 (en) User station for a serial bus system and method for communication in a serial bus system
CN101106438B (zh) 通信网络系统和错误验证方法
US10541830B2 (en) Serial communication system
IT202000004978A1 (it) Dispositivo elettronico, sistema e veicolo corrispondenti
KR20210143288A (ko) 직렬 버스 시스템용 가입자국 및 직렬 버스 시스템에서의 통신 방법
Umair et al. Communication technologies and network protocols of automotive systems
US11106619B2 (en) Transmission of synchronous data via a serial data bus, in particular a SPI bus
CN113542265B (zh) 局部网络安全管理、装置、计算机设备及存储介质
Bell Network protocols used in the automotive industry
Li et al. Design and application of communication gateway based on FlexRay and CAN
EP4231595A1 (en) Relay device, communication network system, and communication control method
CN116946047A (zh) 车辆的控制方法、装置及车辆
Dsouza et al. Diagnostic Protocol Stack on LIN Interface