white space

Safetybus

1 Inleiding

Dit verslag gaat over SafetyBUS p, of gewoon SafetyBUS. Ik heb dit onderwerp gekozen omdat ik dit systeem in de praktijk heb gezien tijdens mijn stage, en ik wilde graag meer weten over de werking ervan.

SafetyBUS is afgeleid van de techniek en het communicatieprotocol CAN-Bus. Can-Bus zelf is zeer ongevoelig voor storingen maar dit betekend niet automatisch dat het systeem dan ook veilig is. CAN beschikt over mechanismen die zorgen voor de foutcorrectie. Daarom juist is bij SafetyBUS, de veilige functie pas in tweede instantie nodig. SafetyBUS vangt de fouten op, die door de detectie en correctie van het CAN systeem heen komen. Op deze manier kan de betrouwbaarheid, beschikbaarheid en bovendien veiligheid van machines en installaties verhoogt worden.

Een veilig protocol voor de overdracht van gegevens zorgt in de eerste plaats voor de veiligheid die SafetyBUS biedt. Ook vereist het veiligheidsconcept van SafetyBUS dat de busdeelnemers op zich uiteraard ook veilig zijn. Dit houdt o.a. in dat elke module alle tests en bewakingen, die nodig zijn om de vereiste veiligheidscategorie te bereiken, zelf uit kan voeren. Als een module van SafetyBUS een fout detecteert gaat deze in de veilige toestand en schakelt alle uitgangen veilig uit. Ook wordt er een speciaal errortelegram met de foutmelding aan alle busdeelnemers verzonden. Vervolgens zullen alle busdeelnemers die tot dezelfde I/O groep behoren ook in de veilige toestand gaan en afschakelen. Ook als er een totale uitval van een busdeelnemer voorkomt, wordt dit via de veiligheidsmechanismen van het SafetyBUS protocol gedetecteerd. Het risico van een gevaarlijke machine uitval door een overdrachtsfout bij dit protocol is kleiner dan 10-13!

2 Topologie

2.1 Bustopologie

Met veldbussystemen (waaronder ook SafetyBUS) is er een vermindering van de bedradingskosten mogelijk, en ook zijn de kosten voor het aansluiten van een (nieuwe) busdeelnemer laag. Het grote voordeel zit in de zeer omvangrijke diagnose mogelijkeden, configuratie is mogelijk via de bus (Figuur 1) en er kan een groot aantal busdeelnemers worden aangesloten. Deze hoeven niet allemaal van dezelfde fabrikant te zijn, verschillende leveranciers voor de deelnemers hoeft geen enkel probleem op te leveren.

Bustopologie
Figuur 1: Bustopologie

2.2 Ringtoptologie

Een ander veldbussysteem is mogelijk met een ringtopologie (Figuur 2). Bij een ringtopologie vindt er signaalregeneratie (versterking) plaats in elke deelnemer, en daarom is dit systeem niet afhankelijk van het vermogen van de driver. Ook hier zijn een groot aantal busdeelnemers mogelijk. Het grote verschil is dat het bij een bustopologie mogelijk is om busdeelnemers in of uit te schakelen. Dit is absolut niet mogelijk bij een ring systeem en zal leiden tot een bedrijfsonderbreking. Ook een defecte deelnemer aan de bus zal leiden tot een totale uitval van het systeem. Een voorbeeld van een systeem met ringtopologie is INTERBUS.

Ringtopologie
Figuur 2: Ringtopologie

3 Gegevensoverdracht

SafetyBUS en CAN maken gebruik van zogenaamde synchrone gegevensoverdracht. Dit houdt kortgezegd in dat de synchronisatie per verzonden telegram eenmaal plaatsvindt. Na-synchronisatie is hierbij vereist. Asynchrone overdracht (ook wel start-stop principe genoemd) wordt metname gebruikt door PROFIBUS, INTERBUS en ASI. Dit systeem reduceert de overdrachtscapaciteit en de synchronisatie vindt plaats met het startbit per teken.

Alle systemen maken ook gebruik van gegevensbeveiliging. Gebruikelijke methodes zijn herhaling door de zender bij foutdetectie. SafetyBUS, CAN en INTERBUS doen dit door middel van zogenaamde cyclische controlesequentie. Dus na elke cyclus een controle uitvoeren. Ook zijn er nog ander methodes voor foutdetectie zoals bitmonitoring. Dit wordt ook door SafetyBUS toegepast. Het principe voor foutdetectie is vrij simpel. De zender van een bericht wacht op de bevestiging van de ontvangende busdeelnemer(s). Dit kan alleen worden toegepast bij één op één communicatie. Deze foutdetectie en onmiddelijke foutsignalering worden beide toegepast in SafetyBUS.

4 Bustoegangsmethoden

4.1 Master - Slave

Bij het master-slave principe is er één busdeelnemer aangewezen als master en coördineert de bustoegang door cyclische gegevensuitwisseling met andere busdeelnemers (slaves). Deze methode wordt ook wel “pollen” genoemd. De latentietijd (wachttijd) staat in verhouding tot het aantal busdeelnemers. Dit wil zeggen dat wanneer er een korte latentietijd nodig is, het aantal busdeelnemers moet afnemen of een hogere datasnelheid nodig is. Voorbeelden van bussystemen die met het master-slave principe werken zijn PROFIBUS, ASI en DeviceNet.

Bericht georiënteerde overdracht bij het Master-Slave principe:

Master/Slave
Figuur 3: Master/Slave principe

Bustoegang bij het Master-Slave principe:

Bustoegang bij het Master/Slave principe
Figuur 4: Bustoegang bij het Master/Slave principe

4.2 Tokenpassing

Tokenpassing is een zogenaamd multimaster systeem. Het doorgeven van het bustoegangsrecht (de “token”) gebeurt van deelnemer tot deelnemer. De busdeelnemer met het toegangsrecht mag de bus gebruiken voor een vastgelegde tijd (tokenduur).De latentietijd wordt bepaald door de omlooptijd van het token en door het aantal busdeelnemers en hun eigen tokenduur. Voor een tokenpassing bus is een vrij ingewikkelde besturing nodig.
Onder andere PROFIBUS maakt gebruik van deze methode.

Bericht georiënteerde overdracht bij het tokenpassing principe:

Tokenpassing
Figuur 5: Tokenpassing (bron: rad.com)

Bustoegang bij het Tokenpassing principe:

Tokenpassing bustoegang
Figuur 6: Tokenpassing bustoegang

4.3 CSMA/CA

CSMA/CA staat voor Carrier Sense Multiple Access / Collision Avoidence en is een multimaster syteem. Iedere busdeelnemer die wil zenden, kan de bus bezetten zodra deze vrij is. Er is dus niet een bepaalde controle op wie de bustoegang krijgt. Als het voorkomt dat twee deelnemers tegelijk gaan zenden, onstaat er een botsing tussen de berichten. De detectie en oplossing van een botsing gebeurt op verschillende manieren. Een bepaalde wachttijd of het verlenen van prioriteit aan een bericht zijn hier voorbeelden van. Het risico tot een botsing neemt toe, naarmate het aantal busdeelnemers ook toeneemt. Daarom is deze methode het beste toe te passen bij een lage busbelasting. Een LAN of Ethernet maakt ook gebruik van CSMA/CA. Hier is de latentietijd afhankelijk van de actuele busbelasting. Bij SafetyBUS wordt een botsing vermeden door de bericht identifier per bit te verzenden. De maximale latentietijd van het bericht met de hoogste prioriteit wordt bepaald door de maximale lengte van het bericht. Op deze manier is een zeer korte latentietijd mogelijk voor berichten met een hoge prioriteit.

Bustoegang bij het CSMA/CA:

CSMA/CA bustoegang
Figuur 7: CSMA/CA bustoegang

4.4 Ringschuifprincipe

Bij het ringschuifprincipe verloopt de complete gegevensuitwisseling en bustoegang via één busdeelnemer (de master) die alles regelt. De onderlinge gegevensuitwisseling tussen de busdeelnemers gebeurt met een enkel telegram. Een voorbeeld van het ringschuifprincipe is INTERBUS.

De “totaalberichtoverdracht” bij het ringschuifprincipe:

Ringschuifprincipe
Figuur 8: Ringschuifprincipe

Bustoegang bij het ringschuifprincipe:

Ringschuifprincipe bustoegang
Figuur 9: Rinschuifprincipe bustoegang

5 OSI model

Het OSI-referentie model geeft een standaard aan voor alle communicatiesystemen. In het model worden alle functiegebieden van de datacommunicatie beschreven voor communicatiesystemen in de gegevensverwerking. Het model is ingedeeld in zeven lagen, op volgorde van functie. De veldbus communicatie (waaronder dus SafetyBUS) wordt door de lagen 1, 2 en 7 beschreven.

Hieronder het model :

OSI-model
Figuur 10: OSI-model

6 Veiligheid

6.1 Busarbitrage

Om te zorgen voor een goede doorstroming van data, moeten hiervoor regels worden opgesteld. Dit noemt men busarbitrage. Aan deze regels moeten de busdeelnemers voldoen om een bericht te mogen zenden of te ontvangen.

De omschrijving van het arbitrageproces (de spelregels) in het kort:

  • Tijdens het arbitrageproces is de zendende busdeelnemer de busmaster, terwijl de overige busdeelnemers voordurend het busverkeer afluisteren.
  • Een busdeelnemer kan gaan zenden als de bus vrij is. Dit gebeurd als de deelnemer het “Intermission-Bit-Veld” heeft gedetecteerd.
  • Als een busdeelnemer de laatste ontvanger is van een foutief bericht, krijgt deze als eerste bustoegang zodra de bus weer vrij is. De laatste zender van een foutief bericht moet vervolgens een extra wachttijd aanhouden nadat de bus vrijgekomen is, en krijgt weer toegangsrecht nadat de tijd is verlopen. Dit heet een “Suspended-Transmission-Veld”.
  • Als meerdere busdeelnemers tegelijk de bus bezetten, krijgt de zender van het bericht met de hoogste prioriteit bustoegang, de andere zenders gaan standby staan voor ontvangst van het bericht. Prioriteit is te zien aan de “Identifier”, hierdoor kan dus voorrang op andere busdeelnemers verkregen worden.
  • Elke busdeelnemer die bezig is met de arbitrage vergelijkt zijn bitniveau, met het niveau op de bus. Als dit gelijk is zal het proces doorgaan, als hierin een verschil zit zal het zenden onmiddellijk worden gestopt.

Diagram van het busarbitrageproces:

Busarbitrageproces
Figuur 11: Busarbitrageproces

6.2 Fouten

Foutsignalering en detectie

SafetyBUS heeft een aantal verschillende mechanismen voor de foutdetectie. Deze mechanismen zorgen voor een zeer grote waarschijnlijkheid dat een fout wordt gedetecteerd. Als een zendende busdeeldemer een foutief bericht heeft verstuurd, zullen de overige deelnemers dit signaleren. In dit geval zal het foutieve bericht verworpen en opnieuw verzonden worden. De tijd waarin de foutdectie gebeurd en een volgend bericht wordt verzonden is zeer kort ; maximaal 31 bit. In principe kunnen de (mogelijke) fouten in twee groepen worden verdeeld:

  • Fouten die worden gedetecteerd tijden de gegevensoverdracht op de bus.
  • Fouten of defecten die door een busdeelnemer worden gedetecteerd aan het apparaat.
    De foutreactie hangt af van de soort fout.

Foutbegrenzing en vermijding

Busdeelnemers van SafetyBUS kunnen verschil zien tussen kortdurige en langdurige fouten in een functie. Ook kunnen storingen gedetecteerd worden. Bij een hardwarestoring, bijvoorbeeld een defecte deelnemer, zal deze zichzelf veilig uitschakelen. Het bussysteem op zich en SafetyBUS garanderen een zeer hoge veiligheids standaard. Om het systeem dan ook te laten werken zoals het is bedoeld, zal er bij de installatie en tijdens gebruik aan een aantal punten gedacht moeten worden :

  • De installatie waarop het SafetyBUS systeem zal komen te werken, moet een zeer uitgebreide en ook zorgvuldige veiligheids- en gevarenanalyse krijgen.
  • Alle voorschriften over de toepassingen van de onderdelen moeten worden opgevolgd.
  • Er moet een zorgvuldige projectplanning opgesteld en natuurlijk ook zo uitgevoerd worden.
  • De bekabeling (soort bedrading en ook het verloop van de bekabeling) moet uitgevoerd worden zoals in de voorschriften staat.
  • Alleen op-zichzelf veilige componenten gebruiken.
  • Uiteraard moet ook de programmering zorgvuldig worden voorbereid en volgens de voorschriften uitgevoerd worden.

6.3 Tijdgedrag

Reactietijd

De reactietijd binnen SafetyBUS is natuurlijk zeer belangrijk. Bijvoorbeeld bij een noodstop is het van het grootste belang dat een proces (machine) zo snel mogelijk gecontroleerd tot stilstand komt. Kortgezegt is de reactietijd de tijd van de signaalwijziging aan de ingang van een busdeelnemer tot aan de uiteindelijke reactie aan de uitgang van dezelfde of een andere busdeelnemer (actuator). De reactietijd van SafetyBUS wordt door meerdere factoren beinvloed zoals het aantal busdeelnemers, de geconfigureerde overdrachtsnelheid, de cyclustijd van de PLC en de soort van het te verwerken signaal. De reactietijd is uit verschillende tijden samengesteld. Van ingang naar uitgang :

  • Filtertijd
  • Bustoegangstijd
  • Bustransfertijd
  • Cyclustijd (PLC)
  • Bustoegangstijd
  • Bustransfertijd
  • Schakeltijd (actuator / uitgang busdeelnemer)

IN-reactietijd

De zogenaamde IN-reactietijd is eigenlijk het filter en de eerste bustoegangstijd. Als er aan de ingang een signaalwijziging gebeurd, duurt het een poosje voordat de informatie op de bus kan en mag komen. De bustoegangstijd staat nooit vast, het hangt vooral erg af van de snelheid van de busdeelnemer en met name ook de processorbelasting. De filtertijd is wel een gegeven waarde. Toch nog enigszins afhankelijk van de inschakelvertraging van de ingang, maar altijd kleiner dan 1 ms. (voorbeeld de PSS SB DI808 van PILZ).

OUT-reactietijd

De out-reactietijd staat voor de tijd van het gereed staan van een telegram in de ingangsbuffer van het uitvoeraparaat tot de signaalwijziging aan de uitgang (Gelijk als bij de IN-reactietijd). De OUT-reactietijd is alleen afhankelijk van het gebruikte apparaat.

Bustransfertijd

De bustransfertijd is afhankelijk van de busarbitrage en de belasting op de bus, aangezien een telegram alleen verzonden kan worden als de bus vrij is. Ook speelt de overdrachtssnelheid een belangrijke rol bij de transfertijd.
De bustransfertijd komt twee keer voor in het proces: na de eerste filter- en bustoegangstijd en voor de uiteindelijke schakeltijd. Hiermee moet zeker rekening gehouden worden!

De tijd start met het klaar staan van een telegram in de uitgangsbuffer van de busdeelnemer. Deze is dus afhankelijk van de arbitrage- en de overdrachtssnelheid. Er is ook een time-out ingebouwd voor de maximaal toelaatbare transfertijd. Deze wordt bepaald door de geconfigureerde time-out tijd. Als deze tijd overschreden wordt, schakelen alle busdeelnemers veilig uit.

PLC cyclustijd

De cyclus tijd is afhankelijk van de lengte van het programma dat afgewerkt moet worden en van de processor belasting. Bij de PILZ PSS (veiligheidsbesturingen) is het mogelijk de exacte cyclustijd te achterhalen via de systeemdata bouwsteen DB000. Omdat deze tijd altijd schommelingen kent door zogenaamde dynamische programmaprocessen, is het mogelijk een minimale cyclustijd in te vullen. Deze tijd zorgt er dan vervolgens voor dat de PSS een constante cyclustijd doorloopt.

7 SafetyBUS

7.1 Devices

SafetyBUS kent eigenlijk drie verschillende soorten busdeelnemers :

  • Management-device (MD)
  • Logic-device (LD)
  • I/O-device (I/OD)

De SafetyBUS PSS heeft deze drie componenten ingebouwd. Ze kunnen door het gebruikersprogramma (I/O-device) of door de SafetyBUS configuratie ge(de)activeerd worden.

Opbouw PSS:

Opbouw PSS
Figuur 12: Opbouw PSS

Management Device (MD)

Het Managing-device is eigenlijk het hart van de SafetyBUS. Deze busdeelnemer is verantwoordelijk voor, zoals de naam al aangeeft, het bus management. Het transport van gebruiksgegevens is niet voor het MD bedoeld. Bij PILZ SafetyBUS is het MD altijd een besturing van de PSS familie (bijvoorbeeld PSS SB3000 serie). In elk SafetyBUS netwerk moet een MD aanwezig zijn. Wanneer er meerdere PSS systemen op de bus zijn aangesloten, moet er in de configuratie worden vastgelegd welke het MD wordt. De overige PSS deelnemers worden dan Logic-devices (LD’s).

De taken van het Managing-device bestaan ondermeer uit de opbouw van de buscommunicatie en het instellen van de overdrachtsnelheid. Er wordt ook een verbindingstest gedaan met alle busdeelnemers die op de bus zijn aangesloten en met alle actieve Logic-devices tijdens de werking. Overige taken die ook door het Managing-device worden uitgevoerd zijn onder andere adrestoekenning aan I/OD’s in geval van onderhoud of bij de eerste inbedrijfstelling. Een configuratie van alle busdeelnemers wordt gemaakt aan de hand van de configuratietabel. Diagnose-informatie wordt ook ter beschikking gesteld, en ook het vullen van de bus-fout-stack met alle fouten die die via het bussysteem binnenkomen wordt door het MD geregeld.

Logic Device (LD)

Het LD is een logische eenheid die van verschillende I/O-devices gegevens kan verwerken. Aan iedere LD is een I/O groep toegewezen. De logische verbindingen tussen de toegewezen I/O-devices en hun in- en uitgangen worden gemaakt door het LD, en vervolgens worden de reacties volgens het gebruikersprogramma uitgevoerd. Bij de PILZ PSS serie is het mogelijk om zelf het programma te schrijven (vrij programmeerbaar), maar er zijn ook voorgeprogrammeerde LD’s waarvan het programma dus niet gewijzigd kan worden. Er moet altijd minimaal één LD op de bus aanwezig zijn om besturingsfuncties uit te voeren.

Het Logic-device voert, net als het Managing-device, verbindingtests uit. Dit gebeurd dan met de toegewezen I/OD’s tijdens de werking. Ook worden de ingangen geëvalueerd en worden de logische signalen verwerkt van alle I/O groepen, en de uitgangen van deze groepen worden aangestuurd.

I/O Devices (I/OD’s)

I/OD’s zijn eigenlijk passieve busdeelnemers zonder eigen logische gegevensverwerking. Ze kunnen wel eenvoudige voorbereidende taken uitvoeren, zoals het omrekenen van analoge waarden. Alle in- en uitgangen van een I/OD moeten altijd aan een I/O groep toegewezen zijn. Toewijzingen aan meer dan één groep is niet mogelijk.

De taak van een I/OD komt neer op het opnemen van I/O signalen (die door het Logic-device worden ingelezen ), bewerken en weer uitgeven. Bij een I/OD kan er sprake zijn van een busdeelnemer met fysieke in- en uitgangen. Deze worden in het veld geplaatst en door een Logic-device met het fysieke busadres aangesproken. Ook zijn er virtuele I/OD’s, waar de in- en uitgangen niet werkelijk (fysiek) bestaan. Ze worden bestuurd door het gebruikersprogramma van de intelligente veiligheidsbesturing (PSS). Het enige wat er gebeurd, is het beschrijven en uitlezen van een geheugengedeelte. Bij bijvoorbeeld een PSS unit zijn dit de databouwstenen. De gegevensuitwisseling van de virtuele I/OD’s is alleen bedoeld voor snellegegevens uitwisseling van kleine informatieeenheden (1 woord) tussen twee of meerdere LD’s. De fysieke (werkelijke) I/OD’s zijn dan wel iets minder snel, maar ze zijn bedoeld om grotere hoeveelheden informatie te kunnen verwerken.

Onder fysieke I/OD’s vallen bijvoorbeeld digitale ingangsmodulen zoals een lichtscherm of fotocel. Een digitale uitgangsmodule is bijvoorbeeld een ventieleiland. Onder de virtuele I/OD’s vallen digitale in- en uitgangsmodulen zoals de PILZ PSS SB3000.

7.2 Adressen

Fysieke adressen

SafetyBUS kan maximaal 64 apparaten (busdeelnemers) beheren. Het fysieke busadres van elke deelnemer moet worden ingesteld tussen de 32 en 95. Deze nummering is willekeurig, er hoeft dus niet een bepaalde volgorde of verdeling aangehouden te worden. De voorwaarden voor de nummering zijn alleen dat elk fysiek busadres (nummer) binnen SafetyBUS maar één keer voor mag komen. Het wijzigen van een busadres tijdens werking niet is toegestaan en het MD heeft altijd het busadres 0. Daarom hoeft het MD ook niet een in een bepaalde I/O groep te worden ingedeeld.

Het instellen van de busadressen gaat normaal gesproken door middel van schakelaars op het apparaat zelf. Als een busdeelnemer deze instelmogelijkheid niet heeft, wordt het busadres automatisch toegewezen bij de inbedrijfstelling. Elk ingesteld adres (zowel hardware- als softwarematig) moet bij de configuratie worden ingevuld in de configuratietabel.

I/O Groepen

Bij de vorming van groepen worden de LD’s en de I/OD’s aan een bepaalde I/O groep van 0 tot 31 toegewezen. Ook hier is het toekennen van de groepsnummers willekeurig en gebeurd met de configurator in het programmeerapparaat. Dit is om de beschikbaarheid van het SafetyBUS netwerk (en de installatie) te vergroten. Als er bijvoorbeeld een busdeelnemer uitvalt van groep 1, worden alleen de overige busdeelnemers in dezelfde groep veilig uitgeschakeld. Dit heeft op de rest van de busdeelnemers in het SafetyBUS netwerk geen invloed.
Zoals gezegd moet elke busdeelnemer (LD, of I/OD) een I/O groep worden toegewezen (op het MD na). Er zijn ook enkele I/OD’s waarbij de in- en uitgangen gescheiden kunnen worden zodat ze aan verschillende I/O groepen kunnen worden toegewezen. Elke I/O groep heeft minimaal één of meerdere LD’s. Als er meerdere LD’s in een groep zitten, moet er een master-LD worden toegewezen.


Voorbeelden van busopbouw

In de onderstaande voorbeelden worden de logische systeemeenheden met een fysiek busadres, apparaten (MD, LD of I/OD) en de I/O groepen weergegeven :

Voorbeeld met 1 groep:

Busopbouw met 1 groep
Figuur 13: Busopbouw met 1 groep

In Figuur 13 is de busdeelnemer een PSS, die als MD en LD dienst doet. Deze is verantwoordelijk voor de verwerking van de gegevens van alle I/OD’s (in dit geval busadressen 40, 55 en 90). Alle I/OD’s en het LD behoren tot I/O groep 0.

Voorbeeld met 2 groepen:

Busopbouw met 2 groepen
Figuur 14: Busopbouw met 2 groepen

Bij dit voorbeeld is de busdeelnemer weer een PSS, die als MD en LD fungeert. Deze verwerkt de gegevens van alle I/OD’s (busadressen 40, 54, 55 en 90). De I/OD’s 40 en 90 horen bij groep 0, en 54 en 55 bij groep 1. Het LD is verantwoorelijk voor de logische bewerkingen van beide I/O groepen.

Voorbeeld met 3 groepen:

Busopbouw met 3 groepen
Figuur 15: Busopbouw met 3 groepen

In dit voorbeeld bestaan de busdeelnemers uit 4 PSS-systemen. De eerste PSS is de MD en master-LD (adres 32), en zorgt voor de logische verwerking van de gegevens in I/O groep 0. De tweede PSS is de slave-LD (adres 33) en dient als virtuele I/OD in I/O groep 0. De derde PSS is een LD (adres 44), en zorgt voor de logische verwerking van de gegevens in groep 1. De vierde PSS is ook een LD (adres 45) en is verantwoordelijk voor de gegevens verwerking in groep 2. Het I/OD met busadres 54 is verdeeld in twee I/O groepen. De ingangen behoren nu tot I/O groep 1 en de uitgangen tot groep 2.

7.3 Bustoegangsrechten

De bustoegangsrechten van MD’s en LD’s zijn heel verschillend. Hierbij is het MD alleen bedoeld voor busconfiguratie en de bewaking hiervan. De LD’s besturen de gegevens uitwisseling met de I/OD’s en omdat er meerdere LD’s in een I/O groep kunnen zitten moeten deze als master en slave benoemd worden. Uiteraard kan er per I/O groep maar één master geclaimd zijn.

De volgende toegang op het SafetyBUS netwerk kan alleen via het MD plaatsvinden:

  • Busconfiguratie
  • Onderhoud
  • Uitlezing van alle ontdekte busfouten
  • Uitlezing van de fabrikantcode van de busdeelnemers
  • Uitlezing van de configuratielijst
  • Online-monitoring van de bus
  • Ingreep in de actieve bus

LD’s hebben als enig device van het SafetyBUS netwerk schrijf- en leesrechten op de in en uitgangssignalen die door de I/OD’s worden opgenomen. Aangezien er meerdere I/O groepen toegewezen kunnen zijn, wordt een willekeurig LD (als dit nog niet is ingesteld) als zogenaamde master-LD toegewezen. De overige LD’s worden automatisch slave-LD’s. Door het vastleggen van de master en slave instellingen onstaan hier verschillen in de toegangsrechten. Master-LD’s hebben als enige apparaten schrijf-toegang op alle uitgangen van I/OD’s van de toegewezen I/O groepen. Deze is als enige in staat om deze uitgangen aan te sturen. Een slave-LD heeft helemaal geen schrijf-toegangsrechten. Zowel master- en slave-LD’s hebben lees-toegangsrechten op alle ingangen van de I/OD’s van de toegewezen I/O groep. Er is een uitzondering op deze regeling. Alleen bij virtuele I/OD’s kunnen er wel van meerdere groepen signalen worden gelezen.

In de volgende twee voorbeelden van schrijf- en leestoegang bevinden zich als busdeelnemers drie LD’s in een I/O groep.

Schrijftoegang:

Schrijftoegang
Figuur 16: Schrijftoegang

Leestoegang:

Leestoegang
Figuur 17: Leestoegang

7.4 Software diagnose

Voor diagnosedoeleinden met het safety programma zijn voor de gebruiker systeembouwstenen, merkers, functies en OB’s beschikbaar. Met deze gegevens kunnen gemakkelijk bus- of apparaatdiagnoses worden gesteld. Vervolgens kunnen deze met een aangesloten text- of grafischdisplay gevisualiseerd worden.

Foutmeldingen van elke busdeelnemer worden in een zogenaamde fout-stack geregistreerd. De meldingen worden naar een dataveld (dataveld 0) gestuurd, waarover ook elke busdeelnemer beschikt. Het gebruikersprogramma kan de fout-stack van afzonderlijke busdeelnemers opvragen en evalueren. De gegevens van dataveld 0 kunnen in een willekeurige databouwsteen in de PSS gekopieërd worden. In dataveld 1 worden belangrijke diagnosegegevens (18 woorden) opgeslagen. Ieder LD kan ook deze gegevens uitlezen.

Systeem merkers

De merkers M116.00 t/m M116.31 geven de toestand van de I/O groepen weer. Als er één of meerdere I/O groepen in de STOP toestand staan, worden de overeenkomende merkers van alle LD’s die in de bus aanwezig zijn op 0 gezet. Als een I/O groep in STOP toestand schakelt, door een bijvoorbeeld een apparaatfout of programmafout, roept het besturingssyteem OB130 op en werkt de inhoud hiervan af. Hiermee kan vervolgens de gebruiker bijvoorbeeld andere I/O groepen “handmatig” stoppen.

Foutstack

De fout-stack bij de PSS met SafetyBUS heeft in principe dezelfde functie als bij de standaard PSS (het opslaan van systeemfoutmeldingen). Er worden geen gedetaileerde foutmeldingen opgeslagen in deze fout-stack, alleen de foutklasse. In de locale fout-stack van de I/OD’s is wel gedetaileerde informatie te vinden over de fout. Bij de PSS met SafetyBUS is de fout-stack uitgebreid met de algemene foutmeldingen die binnen het gehele SafetyBUS netwerk voor kunnen komen. Wat gelijk is gebleven ten opzichte van de standaard PSS, is de manier om de fout-stack op te vragen. Dit gaat via het gebuikersprogramma of via het programmeerapparaat.
Als er iets in de fout-stack wordt ingevoerd, zal het display op de PSS-CPU de foutklasse van dit bericht weergeven.

Een aantal SafetyBUS fouten met klasse en beschrijving:

Klasse
Foutbeschrijving
F-30
Door de gebruiker geactiveerde stop van een I/O groep
F-31
Apparaatfout van een busdeelnemer
F-32
Bedradingfout van een busdeelnemer
F-33
Timeout fout binnen SafetyBUS
F-34
Foutieve configuratie van SafetyBUS
F-D6
Fout in de functionaliteit van de SafetyBUS PSS

 

Start - Stop I/O groepen

I/O groepen kunnen via het gebruikersprogramma gestopt en gestart worden. De actuele stand van de I/O groep kan via de systeemmerkers 116.00 t/m 116.31 worden opgevraagd. Het stoppen van I/O groepen (buiten het gebruikersprogramma om) kan alleen worden gedaan door de LD’s. Deze zijn in staat één of alle toegewezen groepen te stoppen.

Via OB130 moet een bepaalde hiërarchie worden opgebouwd. In het onderstaande voorbeeld is I/O groep 0 de hoogste signaal groep. Als er nu een apparaat binnen deze groep een fout geeft, moet de hele installatie worden stilgezet. Dit houdt in dat wanneer de I/O groep 0 in de STOP toestand schakeld, alle aanwezige I/O groepen ook in de STOP toestand moeten schakelen.

IO groep 0 als hoogste signaalgroep
Figuur 18: IO groep 0 als hoogste signaalgroep

Ook het starten van één of alle toegewezen I/O groepen kan (buiten het gebruikersprogramma om) alleen door LD’s gedaan worden (Figuur 19). Hiervoor is ondermeer het contact nodig van een sleutelschakelaar op de PSS.

Starten van alle IO groepen
Figuur 19: Starten van alle IO groepen

Bronvermelding

  • Cursusboeken / lesmateriaal PILZ SafetyBUS p cursus
  • Handboek / CD-ROM Producttraining SafetyBUS p
  • Personeel ETD SCA Hygiene Products te Hoogezand

Geschreven door: Wouter Hollander

Welkom op Engineering-online.nl
hier ben je nu: Bussystemen / SafetyBUS