CAN – C O N TR O L L ER A R E A N E T W OR K – Part 1

Istoria CAN începe acum mai bine de 20 de ani. La începutul anilor ’80 un grup de ingineri de la Bosch GmbH căutau un sistem de magistrală serială adecvat pentru folosirea în autovehicule cu pasageri. Cele mai populare soluții adoptate la acea vreme au fost considerate neadecvate pentru cerințele majorității aplicațiilor din industria auto. Sistemul de magistrală trebuia, de fapt, să prezinte un set nou de funcționalități și trăsături care cu greu puteau fi găsite în arhitecturile existente de magistrale de câmp. Proiectarea noii propuneri a implicat de asemenea câțiva parteneri academici și a avut sprijinul Intel.
Noul protocol de comunicație a fost prezentat oficial în 1986 cu numele Automotive Serial Controller Area Network cu prilejul congresului Societății Inginerilor Auto. Avea la bază o schemă multimaster de acces la mediul partajat ce se asemăna cu binecunoscuta abordare CSMA(carrier-sense multiple access). Particularitatea introdusă de CAN însă era un nou mecanism distribuit nedistructiv de rezolvare a conflictelor de pe magistrală prin intermediul unor priorități atribuite implicit mesajelor aflate în colizie.
În anii imediat următori, Intel și Philips au început să producă chip-uri controler pentru CAN, dar urmând două filozofii diferite. Soluția Intel(referită ca FullCAN în literatura de specialitate) necesita mai puțină putere de procesare din partea echipamentului gazdă, deoarece majoritatea funcțiilor de comunicație și management al rețelei erau executate direct de controlerul de rețea. În schimb, soluția Philips(BasicCAN) era mai simplă dar impunea o încărcare mai mare pe procesorul folosit pentru interfațarea cu controlerul CAN. Încă de la mijlocul anilor ’90 mai mult de 15 companii producătoare de semiconductoare, incluzând Siemens, Motorola și NEC, produc și livrează milioane de chip-uri CAN în principal către producătorii auto cum ar fi MercedesBenz, Volvo, Saab, Volkswagen, BMW, Renault și Fiat.
Specificația Bosch(versiunea CAN 2.0) a fost trimisă pentru standardizare internațională la începutul anilor ’90. Propunerea a fost acceptată și publicată drept ISO 11898 la sfârșitul anului 1993 și conținea descrierea protocolului de acces la rețea și arhitectura nivelului fizic. În 1995 un addendum la ISO 11898 a fost aprobat, care descria formatul extins al identificatorilor de mesaj. Specificația CAN este în momentul de față în proces de revizuire și a fost împărțită în patru părți separate: ISO 11898-1(Data Link Layer and Physical Signalling), ISO 11898-2(High Speed Medium Access Unit) și ISO 11898-4(Time-Triggered Communication) au fost deja aprobate ca standarde internaționale, în timp ce ISO 11898-3(Low-Speed, Fault-Tolerant, Medium Dependent Interface) a atins statusul stabil și se află în procesul de finalizare.
Deși inițial conceput pentru aplicații auto, la începutul anilor 1990 CAN a început să fie adoptat și pentru alte scenarii. Documentele standardizate ofereau specificații satisfăcător de detaliate pentru nivelurile de comunicație inferioare dar nu ofereau ghidaj sau recomandări pentru partea superioară a stivei de protocoale OSI, în general, și pentru nivelul de aplicație, în particular. Acesta este motivul pentru care aplicațiile inițiale ale CAN din afara scenariilor auto(mașini textile, sisteme medicale, ș.a.m.d.) au adoptat soluții monolitice ad-hoc. Grupul de utilizatori ai CAN în Automatizare(CAN in Automation – CiA) – fondat în 1992 – s-a ocupat inițial cu specificația pentru nivel de aplicație CAN standard. Efortul lor a dus la dezvoltarea specificației cu aplicații generale CAL(CAN Application Layer – Nivelul de Aplicație CAN). CAL era intenționat să umple spațiul liber dintre procesele de aplicație distribuite și suportul de comunicație de la baza acestora, dar în practică nu a avut succes, principalul motiv fiind independența față de aplicații a CAL și astfel fiecare utilizator fiind nevoit să-și dezvolte un profil convenabil bazat pe CAL pentru aplicația specifică nevoilor sale.
În aceeași perioadă, Allen-Bradley și Honeywell au început să lucreze la un proiect de control distribuit bazat pe CAN. Deși proiectul a fost abandonat ulterior, Allen-Bradley și Honeywell șiau continuat lucrul separat și s-au concentrat pe nivelurile superioare de protocoale. Rezultatele acestor activități au fost soluțiile DeviceNet de la Allen-Bradley și Smart Distributed System(SDS) de la Honeywell. SDS a rămas o soluție internă a Honeywell Microswitch, pe când DeviceNet a fost adoptat la scară largă devenind un competitor serios pentru soluții răspândite precum PROFIBUS-DP și INTERBUS.
În afară de DeviceNet și SDS, o serie de alte inițiative importante s-au concentrat pe CAN și scenariile sale de aplicare. CANOpen a fost conceput în cadrul unui proiect condus iarși de Bosch GmbH. Scopul CANOpen era de a defini un profil bazat pe CAL, care să suporte comunicația înăuntrul celulelor de producție. Specificațiile originale CANOpen au fost finisate de CiA și lansate în anul 1995. Ulterior, CANOpen cât și DeviceNet au devenit standarde europene și sunt acum folosite la scară largă în două arii diferite: automatizare și control distribuit.

CONCLUZII

CAN este ideal pentru aplicații care necesită un număr mare de mesaje scurte și o siguranță mare în medii de operare dificile. Deoarece CAN este bazat pe mesaje și nu pe adrese, se potrivește în mod special cazurile în care datele sunt cerute de mai mult de o locație și consistența la nivelul întregului sistem este necesară.
Limitarea defectelor este de asemenea un mare avantaj al rețelelor CAN. Nodurile defecte sunt în mod automat deconectate de la magistrală, ceea ce previne deturnarea rețelei de către un singur nod defect și asigură banda disponibilă pentru transmisia mesajelor critice. Această limitare a erorilor permite de asemenea adăugarea nodurilor la o magistrală în timp ce aceasta este operațională, tehnică altfel cunoscută sub numele de hot-plugging.
Arhitectura multi-master CAN dă posibilitatea nodurilor să notifice într-un mod foarte simplu evenimente asincrone critice, alarme, urgențe. Nu există un punct central de control (cum este de exemplu în cazul rețelelor FIP) ceea ce aduce un plus de fiabilitate, întrucât nu există un punct care poate opri funcționarea întregii rețele.
Datorită mecanismului de arbitraj, este cert că niciun mesaj nu va fi întârziat de schimburi de mesaje de prioritate redusă(fenomen cunoscut sub numele de inversia priorității). Un mesaj poate fi totuși întârziat de unul cu prioritate redusă a cărui transmisie a început deja. Acest lucru este de neocolit într-un astfel de sistem. Totuși, deoarece mărimea cadrului este foarte mică(cadrele standard au cel mult 135 de biți, incluzând biții dopați), timpul de blocaj experimentat de mesajele foarte urgente este destul de mic. Acest lucru face ca rețeaua CAN să aibă un timp de răspuns foarte bun, ceea ce explică de ce este folosită în aplicații de control în timp-real în ciuda lărgimii de bandă relativ mici.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.