Steeds vaker wordt software ingebed in apparatuur, zoals televisies. Vanwege de toenemende complexiteit ligt het gebruik van een database en een databasemanagementsysteem binnen ‘ingebedde’ systemen voor de hand. Een technisch ontwerper van Alert Automation Services schetst de toepassingsmogelijkheden van dergelijke systemen en de problemen waarvan sprake is.
In de administratieve automatiseringsbranche is het beheer van data van groot belang. Om te zorgen voor een goed beheer wordt veelal gebruik gemaakt van databasemanagementsystemen. In de technische automatiseringsbranche speelde het beheer van data altijd een ondergeschikte rol. Het accent lag veelal op de besturing van hardware. Met name in de ‘embedded software’-industrie (software ingebed in produkten als televisie, audio, telefoon, medische apparaten, telecommunicatie), zien we dat het beheer van data een steeds grotere rol begint te spelen. Een aantal trends is waarneembaar. Er is een forse toename van de grootte en de complexiteit van software in producten. In de nieuwste generatie tv’s gaat het om zo’n 2 MB aan software, gemaakt door projectteams van 50 man. Verder is er meer vraag naar open systemen met gestandaardiseerde interfaces, zodat koppeling naar andere producten kan plaats vinden. En ten slotte groeit het belang van hiërarchische en robuuste architecturen, ingericht op toekomstige aanpassingen en uitbreidingen.
Om succesvol op deze trends te kunnen inspelen, dient het beheer van data meer aandacht te krijgen dan nu het geval is.
Gedistribueerde data
Het volgende voorbeeld dient om dit te illustreren.
Een software-ontwerper wilde zijn tv-software aanpassen, zodat de graphics-module van de tv-software geschikt werd gemaakt voor breedbeeld tv. Hij dacht dat het aanpassen niet meer was dan het aanpassen van een constante, een getal dat de breedte van het scherm representeert. De ontwerper had gelijk, het was echter niet één constante, maar vijf. Alle vijf representeerden exact dezelfde informatie, het aantal beschikbare pixels in de breedte.
 |
| Figuur 1. Architectuur van ingebedde systeem met gedistribueerde data. |
In iedere laag zijn modules te onderscheiden die gekenmerkt worden door één bepaalde functionaliteit. Modules uit één laag maken gebruik van één of meerdere modules uit een laag daaronder. In het algemene geval kunnen modules ook afhankelijk zijn van elkaar binnen een laag. Iedere module houdt data bij die zij voor zichzelf belangrijk acht. Deze data bepaalt mede het gedrag van de module. In de figuur wordt deze data gerepresenteerd door de zwarte stippen binnen de modules. Zoals in het geval van de tv-software, kunnen die stippen op verschillende plekken zitten en toch dezelfde informatie representeren. Zo heeft een ‘graphics device driver’ een interne variabele beeldschermbreedte. Als de daar bovenop gebouwde ‘window manager’ onafhankelijk van de ‘graphics device driver’ is ontwikkeld, is het waarschijnlijk dat daar een soortgelijke variabele is geïntroduceerd.
Centrale database
Met betrekking tot databeheer sluit het model van figuur 1 slecht aan bij wat ingebedde software feitelijk is. Figuur 2 laat het algemene model van een ingebed systeem zien. Zo’n systeem bestaat uit sensoren en actuatoren. Op een zeker tijdstip wordt de toestand van de actuatoren bepaald door de huidige en een eindig aantal vorige toestanden van de sensoren. In dit model wordt het eindig aantal vorige toestanden van de sensoren opgeslagen in een zekere structuur, de database.
 |
| Figuur 2. Algemeen model van een ingebed systeem. |
Als we dit model vergelijken met de architectuur van figuur 1, dan blijkt dat de actuatoren en sensoren op de ‘device driver’-laag kunnen worden afgebeeld. De ‘application main’ vinden we terug in de lagen daarboven. De centrale database met bijbehorend ‘polling mechanisme’ (afvraagmechanisme) is in figuur 1 verdwenen.
Op basis van het algemene model lijkt het gebruik van een database binnen ingebedde systemen toch voor de hand te liggen. Binnen de ingebedde software is men echter een beetje bang voor databases. Als men aan databases denkt, ziet men al snel grote logge systemen waar makkelijk een miljoen velden in kwijt kunnen. Dergelijke databases sluit goed aan bij de behoeften binnen de niet-ingebedde software zoals de kantoorautomatisering. Voor ‘dat beetje’ data in ingebedde systemen ziet men zo’n database als overhead. Het lijkt makkelijker om de data in eigen gedefinieerde structuren op te slaan binnen de functionele modules. Dit leidt meestal tot een gedistribueerde opslag van de data zoals aangegeven in figuur 1.
 |
| Figuur 3. Architectuur van ingebed systeem met database. |
Databasemanagementsysteem
In de toekomst wordt de ingebedde software echter steeds complexer en wordt databeheer belangrijker. Een architectuur zoals beschreven in figuur 3 past beter bij het model van figuur 2. De modules halen en stoppen hun belangrijke variabelen in een centrale plaats, de database.
Door data centraal op te slaan is de data makkelijker consistent te houden. Ook voor diagnose-activiteiten kan het zeer handig zijn om alle belangrijke data bij elkaar te hebben. Als voor de implementatie van het centrale databeheer gekozen wordt voor een bestaand databasemanagementsysteem, dan krijgt de applicatie-ontwikkelaar allerlei data-transactiefunctionaliteiten cadeau.
De vraag is echter hoe zo’n databasemanagementsysteem er uit moet zien. Aan ingebedde databases zijn andere eisen verbonden dan aan niet-ingebedde databases. In het algemeen geldt dat in ingebedde software de databasemanagementsystemen compact en snel moeten zijn. Daar staat tegenover dat de te verwerken hoeveelheden data relatief klein zijn ten opzichte van de databasesystemen uit de niet-ingebedde wereld. Figuur 4 geeft een overzicht van de verschillen tussen ingebedde en niet-ingebedde software met betrekking tot databeheer.
In de niet-ingebedde software zijn de relationele databases het meest gebruikt. Deze tabelgeoriënteerde databases hebben bewezen zeer nuttig te zijn als het gaat om het verwerken en consistent houden van grote hoeveelheden data, al dan niet gedistribueerd. Op de markt zijn veel commerciële relationele databasemanagementsystemen beschikbaar waaraan de applicatie-ontwikkelaar het databeheer kan uitbesteden. De meeste van deze databasesystemen hebben een universele interface naar buiten toe, de Standard Querie Language (SQL). Zo zijn op uniforme wijze alle mogelijke transacties op de database te verrichten. Mede door deze standaard zijn de relationele databases zo populair geworden.
 |
| Figuur 4. Verschillen tussen ingebedde en niet-ingebedde software met betrekking tot databeheer. |
Tot op heden wordt er weinig gebruik gemaakt van actieve en real-time databases. Ze zijn nog relatief nieuw en er zijn dan ook slechts een paar commerciële producten van op de markt. Een groot probleem is de vraag welke functionaliteit een actieve of real-time database moet bieden. Deze vraag is nog steeds niet afdoende beantwoord. Dit is een van de redenen waarom een SQL-standaard voor actieve en real-time databasemanagementsystemen nog niet bestaat. Binnen de academische wereld wordt echter op diverse plekken onderzoek gedaan naar de vraag wat actieve en real-time databases nu zijn. Ook wordt er gewerkt aan de definitie van een standaard actieve/real-time SQL.
 |
| Figuur 5. Ingebed systeem dat gebruik maakt van een actief databasemanagementsysteem |
Zolang deze databasemanagementsystemen er nog niet zijn, kan er echter wel nagedacht worden over een betere structurering van de data binnen ingebedde systemen. Het gebruik van een databasemanagementsysteem is niet noodzakelijk om het database-concept binnen de software door te voeren. Het gebruik van zo’n concept zet mensen tot denken. Plotseling gaan ze bedenken welke data belangrijk is, welke bewerkingen erop uitgevoerd moeten worden en hoe ze de data moeten opslaan en opvragen. Zolang dergelijke vragen niet in een vroeg stadium naar boven komen, zal het vijf constanten kosten om de beeldschermbreedte van de tv-software in te stellen.
Ir. B.J.M.Bon, technisch ontwerper bij Alert Automation Services te Veldhoven
Relationele databasemanagementsystemen
Relationele databasemanagementsystemen (rdbms-en) slaan data op in tabellen en leggen relaties vast tussen de verschillende tabellen. Zo kan een verandering in tabel x invloed hebben op tabel y. Op de tabellen kunnen queries toegepast worden. Ook zijn tabellen te combineren tot nieuwe tabellen. Als de tabellen en hun relaties op een goede manier zijn vastgelegd, is het mogelijk om bepaalde queries efficiënt (in de tijd) uit te voeren.
Rdbms-en zijn populair, vooral in de niet-ingebedde software wereld. Rdbms-en worden overal gebruikt waar grote hoeveelheden data moeten worden opgeslagen en bewerkt, zoals dat het geval is bij banken, belastingkantoren, verzekeringsmaatschappijen, enzovoort. Rdbms-en hebben aangetoond dat het mogelijk is om betrouwbaar om te gaan met grote hoeveelheden data in complexe (gedistribueerde omgevingen) met meerdere gebruikers.
SQL speelt een belangrijke rol in de populariteit van rdbms-en. Dankzij SQL is het mogelijk, om verschillende rdbms-en met elkaar te koppelen.
Actieve databasemanagementsystemen
Een actief databasemanagementsysteem (adbms) is een dbms met reactief gedrag. Een adbms kan bepaalde toestanden in een dbms herkennen en de daarbij behorende acties ondernemen.
De meeste adbms-en zijn gebaseerd op het ‘eca-rule’-model. Eca staat voor ‘event-conditieëvaluatie-actie’. Het idee is dat bij een zekere ‘event’ de ‘eca-rule’ geactiveerd of ‘afgevuurd’ wordt. Het afvuren bestaat uit het testen op een bepaalde conditie. Als de conditie ‘waar’ is, dan wordt een zekere actie ondernomen.
Een ‘event’ kan een zeker punt in de tijd zijn of een andere interessante gebeurtenis die door de adbms vastgesteld kan worden. Een conditie kan een booleaanse functie zijn of een database-query. Een actie is omschreven in de datamanipulatietaal (dml) van de adbms.
Adbms-en zijn voornamelijk onderwerp van onderzoek. Een standaard dml bestaat nog niet.
Real-time databasemanagementsystemen
Real-time databasemanagementsystemen (rtdbms-en) zijn dbms-en waarbij tijdsrestricties een rol spelen. Te denken valt aan:
- Het uitvoeren van een transactie binnen een zekere tijd. Het goed plannen van de transacties is een voorwaarde om aan deze eis te kunnen voldoen.
- Het geven van een schatting over de doorlooptijd van een querie of transactie.
- Voorzieningen om data op tijd te verversen (absolute tijdelijke consistentie).
- Voorzieningen om data onderling consistent in de tijd te houden (relatieve tijdelijke consistentie).
Rtdbms-en bevatten vaak actieve componenten. Een rtdbms is dan ook te zien als een uitbreiding op een adbms. Rtdbms-en staan nog in de kinderschoenen. Een van de weinige praktijk voorbeelden is de rtdbms Eagle Speed die is ontstaan uit een database voor een onderzee commandosysteem.
