Foundation Fieldbus is een bussysteem dat ontworpen is voor de proces industrie. Op deze pagina staan de werking en inhoud van dit bussysteem uitgelegd.
Foundation Fieldbus gebruikt maar 3 lagen van het OSI model:
- 7: Gebruikers laag
- 2: Communicatie laag
- 1: Fysieke laag
De functionaliteit van de lagen 3 t/m 6 zijn ondergebracht in de lagen 2 en 7.
Er zijn 2 verschillende soorten Foundation Fieldbus:
- H1 transmissie (31,25 Kbit/s)
- HSE High Speed Ethernet (100 Mbit/s)
1 Foundation Fieldbus H1
Allereerst wordt er over Foundation Fieldbus H1 gesproken.
De Foundation Fieldbus H1 bestaat uit 3 lagen:
- H1 Fysieke laag
- Communicatie laag
- Gebruikers laag
1.1 Fysieke laag
De fysieke laag ontvangt de berichten die verstuurd zijn door de communicatielaat. De berichten worden door de fysieke laag omgezet naar het juiste transmissie medium. De berichten die binnenkomen zullen over de kabel verzonden moeten worden, hiervoor is de vertalingsslag nodig.
In de fysieke laag worden de volgende aspecten omschreven:
- Snelheid van transmissie
- Vorm van de golven en hun amplitude
- Fysieke karakteristieken (bedrading)
Enkele eigenschappen van de fysieke laag:
- 50Ω + 15-20mA →0,75 tot 1 volt piek-piek
- Spanningsvoorziening tussen de 9 en 32 volt
- Berichten worden verzonden in pakketjes van 8 bits (octet)
- Kortste bericht is 11 Bytes = 88 bits
- Tussen berichten 4 bits stilte
- Totale kortste periode 92 bit tijden, bij 31,25 Kb/s 340 berichten per seconde
- Langste bericht is 276 Bytes = 2208 bits
- Tussen berichten 4 bits stilte
- Totale langste periode 2212 bit tijden, bij 31,25 Kb/s 14 berichten per seconde
Componenten kunnen in verschillende topologieën aangesloten worden op de Foundation Fieldbus.
- Ster topologie
- Spur of trunk topologie
- Daisy chain topologie
 Netwerkconfiguratie |
1.2 De communicatielaag
De communicatie laag is opgedeeld in 3 verschillende lagen:
- Data Link Laag (DLL)
- Fieldbus Access Sublayer (FAS)
- Fieldbus Message Specification (FMS)
1.2.1 Data Link Laag (DLL)
De functie van de DLL is het controleren van de transmissie van de berichten op de bus. Dit gebeurt door middel van de gecentraliseerde regelaar, de Link Active Scheduler (LAS)
1.2.1.1 Link Active Sheduler (LAS)
Er zijn verschillende manieren van communiceren op de bus, Foundation Fieldbus gebruikte echter de gecentraliseerde token passing. Gecentraliseerde token passing is een compromis tussen een central master en token passing communicatie. Er wordt dan een combinatie gemaakt tussen het cyclisch updaten en/of rapporteren van bijvoorbeeld alarmen en events die noodzakelijk zijn voor het controleren van het proces en elke deelnemer een voor een de beurt te geven om te communiceren. De central master noemt men de Link Active Sheduler (LAS).
De LAS verzorgd de volgende taken:
- Cyclisch communicatieschema aanstellen
- Bepaald overall cyclustijd
- Geeft de token aan degene die toegang wil tot de bus →compel data (CD)
- Houdt een lijst bij van alle actieve deelnemers, de zogenoemde Live List
- Auto detectie van nieuwe deelnemers
- Automatisch toewijzen van beschikbare adressen van nieuwe deelnemers
- Auto tag check gebruiken om dubbele tagnummers te detecteren en hierover te waarschuwen.
- Publisher-Subscriber communicatie
- Client-Server communicatie
- Report Distribution communicatie
- Uitsturen van tijddistributie, alle klokken van de deelnemende systemen dienen gelijk te lopen.
1.2.1.2 LAS Redundantie
De LAS functionaliteit zorgt ervoor dat de fabriek kan doordraaien wanneer het besturingssysteem uitvalt. De LAS wordt overgenomen door een apparaat in de fabriek (Secundaire LAS functionaliteit).
Er zijn 2 soorten veldapparaten:
- Basic devices
- Link Masters
Bij gebruik van secundaire LAS dient minimaal 1 device per segment een Link Master te zijn.
Een Link Master kan de LAS functionaliteit overnemen wanneer de primaire LAS uitvalt. Een basic device kan dit niet.
Wanneer het voor een device tijd is data op de bus te zetten geeft de LAS een signaal, ook wel de Compel Data (CD) genoemd. Alle subscribers ontvangen de CD berichten.
De DLL is verantwoordelijk voor het onderhouden van de tijd in de veldbus, dit wordt gedaan door de Time Master.
Het zenden van de CD heeft de hoogste prioriteit.
1.2.1.3 Cyclische communicatie
Een device kan berichten verzenden op vastgestelde tijden nadat hij de CD heft ontvangen van de LAS.
Stap voor stap uitleg van de communicatie:
- LM stuurt CD naar device X om gegevens a te versturen.
- Device X stuurt gegevens a de bus op.
- Alle subscribed device’s ontvangen gegevens a.
1.2.1.4 Acyclische communicatie
Er zijn ook berichten die niet op vastgestelde tijd verzonden worden, dit is acyclische communicatie. De LAS geeft via Pass Token (PT) toestemming voor het verzenden van deze berichten.
Pas wanneer een device de PT heeft ontvangen mag hij berichten verzenden, dit mag net zolang tot het bericht verzonden is of tot de maximale token hold time is verstreken.
De cyclische communicatie mag maximaal 50% van de bus belasten, hierdoor is de andere 50% beschikbaar voor de acyclische communicatie.
1.2.2 Fieldbus Access Sublayer (FAS)
FAS vervangt de lagen 3, 4, 5 en 6 van het OSI model en koppelt de DLL (laag 2) en de FMS in lag 7 aan elkaar.
Taken van de FAS zijn beschreven in de VCR (Virtual Communication Relationships).
VCR is net als de geheugentoets op de telefoon, 1 keer een nummer invoeren en daarna via een snel toets weer op te roepen.
Verschillende soorten VCR:
- Cliënt-Server
- Report Distribution
- Publisher-Subscriber
| Client-server | Report Distribution | Publisher-Subscriber |
|---|
| Pass Token | Pass Token | Compel Data |
| Acyclisch | Acyclisch | Cyclisch |
| 1 → 1 | 1 → ∞ | 1 → ∞ |
Operator berichten
- Setpoint changes
- Mode changes
- Tuning changes
- Upload/download
- Alarm management
- Access display views
- Remote diagnostics | Event & Trend rapporten
- Send Process Alarms to
operator consoles
- Send trend reports
to data historians | Publiceren van data
- Send transmitter PV to PID
control block and operator
console |
1.2.3 Fieldbus Message Specification (FMS)
De Fieldbus Message Specification (FMS) zorgt ervoor dat de berichten van de ene gebruikers laag naar de andere verzonden kunnen worden, gebruikmakend van een standaard formaat. FMS beschrijft communicatievoorzieningen, berichtformaten en de protocollen die nodig zijn om berichten te maken voor de communicatie laag.
Data over de bus is omschreven in de Object Bibliotheek, deze info wordt gebruikt om met Virtual Field Device’s (VFD) data in een device te bekijken.
1.2.3.1 Communicatie services
De communicatie services stellen een standard beschikbaar om over de veldbus te communiceren. FMS services kunnen alleen gebruik maken van het VCR type client-server (tenzij anders vermeld).
- Context management services
Maakt het mogelijk VCR tot stand te brengen met een VFD, ook wordt de status van de VFD bepaald.
De volgende FMS services worden gebruikt:
| - Initiate | (Tot stand brengen van communicatie) |
| - Abort | (Communicatie vrijgeven) |
| - Reject | (Niet juiste service weigeren) |
| - Status | (Leest de device status) |
| - Identify | (Leest leverancier, type en versie) |
- Object Dictionary services
Hiermee kun je de Object beschrijving in een VFD veranderen.
De volgende services worden gebruikt:
| - GetOD | (Leest object dictionary) |
| - InitiatePutOD | (Start een Object Dictionary) |
| - PutOD | (Laadt een OD in een device) |
| - TerminatePutOD | (Stopt een OD) |
- Variabelen Services
Geeft gebruikerslaag toegang tot variabelen en kan deze veranderen.
Men gebruikt hierbij:
| - Read | (Leest een variabele) |
| - Write | (Schrijft een variabele) |
| - Information Report | (Zend data) |
| - DefineVariableList | (Definieert een variabelen lijst) |
| - DeleteVariableList | (Delete een variabelen lijst) |
- Event Services
De volgende FMS services geven de gebruikerslaag de mogelijkheid events te rapporteren en het process te managen:
| - Event Notification | (Rapporteren van een event) |
| - AcknowledgeEventNotification | (Accepteren van een event) |
| - AlterEventConditionMonitoring | (Activeren/deactiveren van een event) |
- Upload/download service
FMS maakt gebruik van domeinen om op afstand data te up- of downloaden. Een domein vertegenwoordigt de geheugenruimte in een device.
De volgende FMS services worden gebruikt:
| - RequestDomainUpload | (Aanvragen van een upload) |
| - InitiateUploadSeqeunce | (Start een upload) |
| - UploadSegment | (Leest data van een device) |
| - TerminateUploadSeqeunce | (Stop upload) |
| - RequestDomainDownload | (Aanvragen van een download) |
| - InitiateDownloadSeqeunce | (Start een download) |
| - DownloadSegment | (Zendt data naar een device) |
| - TerminateDownloadSequence | (Stopt download) |
- Program Invocation Service (PI)
PI biedt de mogelijkheid een programma in een device op afstand te beïnvloeden en/of te controleren. Een programma kan gedownload worden en vervolgens op afstand bediend door het doen van een PI serviceverzoek.
| - CreateProgramInvocation | (Ontwerpt een programma object) |
| - DeleteProgramInvocation | (Delete een programma object) |
| - Start | (Start een programma) |
| - Stop | (Stopt een programma) |
| - Resume | (Vat de programma executie samen) |
| - Reset | (Reset het programma) |
1.2.3.2 Boodschap formaat
Exact formaat FMS boodschappen voorgeschreven in formele syntax beschrijvingstaal, Abstract Syntax Notation 1 (ANS.1) genoemd. ANS.1 is onderdeel van de CCITT post standaardisatieactiviteiten.
1.3 Gebruikerslaag
In de gebruikerslaag zitten de leverancier specifieke onderdelen. Leveranciers onderscheiden zich door andere functionaliteiten in de gebruikerslaag te implementeren.
De gebruikerslaag bestaat uit blokken, we kunnen deze onderverdelen in 3 verschillende soorten:
- Functieblokken
- Resourceblokken
- Transducerblokken
1.3.1 Functieblokken
De functieblokken zijn de bepalende factor in een control systeem, deze kunnen op een vast tijdstip worden uitgevoerd of in een applicatie aan elkaar gekoppeld worden.
De functieblokken kunnen in de controller geplaatst worden, dit heeft als nadeel een grote busbelasting. Om de bus minder te belasten kun je de blokken in devices onderbrengen, de aansturing van de blokken wordt dan lokaal geregeld.
Een voorbeeld:
 Buscommunicatie functieblokken |
Het AI blok (Analoge Input) is in de transmitter ondergebracht, het PID blok en het AO blok (Analoge Output) zijn in de klep ondergebracht.
De transmitter en de klep kunnen nu direct met elkaar communiceren, ze hebben geen PLC/PC of iets dergelijks nodig.
Wanneer je in bovenstaand voorbeeld het PID blok in de controller zet communiceert het AI blok met de controller, vervolgens stuurt de controller de waarde naar de klep. De klep stuurt zijn huidige stand weer terug naar het PID blok.
In het bovenstaand voorbeeld zit echter het PID blok in de klep. De transmitter stuurt zijn waarde naar het PID blok, dit gaat via de bus. De communicatie tussen het PID blok en het AO blok gaat niet meer via de bus omdat deze in dezelfde klep zitten.
In deze configuratie wordt de bus 3 keer zo kort belast.
1.3.2 Resourceblok
In het resourceblok staan de karakteristieken van het device:
- Naam van het device
- Fabrikant
- Serienummer
- Hoeveelheid vrij geheugen
- Hoeveelheid vrijetijd
Met dit blok kun je de status van het device bepalen, eventuele alarmen uitlezen en zelf in het elektronische gedeelte van het device aanpassingen aanbrengen.
1.3.3 Transducerblokken
De transducerblokken zetten het signaal van de sensor om naar een digitaal signaal.
De blokken bevatten informatie als de datum van de laatste kalibratie en het sensortype.
Voor elke in- en output functieblok is een transducerblok. Met het transducerblok kun je de status van de sensor bepalen, ook kun je de parameters aanpassen en de sensor kalibreren.
1.4 Device Description (DD)
Foundation Fieldbus maakt gebruik van DD om te garanderen dat de interoperabiliteit van de veldbus devices goed werken. DD levert informatie om de betekenis van de data te begrijpen.
DD beschijven mogelijkheden van een Foundation Fieldbus device in de standaard DLL
De Device Description services gebruiken de Device description om het hostsysteem van alle informatie te voorzien.
De DD file laat de HMI begrijpen welke informatie een device aanlevert. In deze DD file staat bijvoordeeld de Tagname, engineeringsunit enz.
De DD file is geschreven in een programmeertaal, de DD soucre file moet vertaald worden naar een DD output file. Tokenizer Tool maakt deze vertaal slag.
Door de gedefinieerde hiërarchie voor de DD wordt het makkelijker om devices te maken en een systeemconfiguratie uit te voeren. Deze hiërarchie bestaat uit 4 niveau’s:
- Universele parameter, zoals tagname, revisie, mode enz. Alle blokken moeten deze universele parameters bevatten.
- Functieblok parameters en de standaard resource blokken worden hier gedefinieerd.
- Transducerblok parameters zijn hier gedefinieerd, soms wordt de transducerblok specificatie aan de parameters van de standaard resourceblokken toegevoegd.
- Fabrieksspecificatie parameters, fabrikanten zijn hier vrij om extra parameters aan de functie- en transducerblokken toe te voegen.
De eerste 3 niveau’s worden door de Foundation Fieldbus geschreven.
Opbouw blokken
1.5 Interoperabiliteit
Interoperabiliteit is het aansluiten van apparatuur, van verschillende leveranciers, op dezelfde bus. Interoperabiliteit is een cruciaal aspect van de Foundation Fieldbus technologie. Functieblokken van verschillende leveranciers kunnen in eenzelfde regelkring worden opgenomen.
Het AI blok van de ene leverancier kan dus samenwerken met een PID blok van de andere leverancier.