PDF Tagungsband Beitrag deutsch

ikb.weihenstephan.de

PDF Tagungsband Beitrag deutsch

Seite 1 16. März 2001Die LBS Programmbibliothek –erstes Open Source Modell in der LandwirtschaftACHIM SPANGLER, TUM-WEIHENSTEPHANHERMANN AUERNHAMMER, TUM-WEIHENSTEPHANAbstractThe open communication system “Landwirtschaftliches BUS System” (LBS) lacks a standardreference implementation, which would lead to capable and compatible communications systems.An Open Source program library could be developed to a standard implementation ofthe application layer of DIN9684. This would reduce the needed investments for developingLBS systems, and would guarantee compatibility of all systems by using the same sourcecode.1. LBS – Ein Netzwerk teilweise autonomer AgentenDas Landwirtschaftliche BUS System (LBS) ist ein offenes Kommunikationssystemzur Steuerung und Überwachung von Arbeitsprozessen. Hierbei werden die Jobrechnerder Arbeitsgeräte und des Traktors über CAN untereinander und mit Dienstenwie z.B. virtuellem Termial und Task-Controller verbunden.Bei LBS wird ein Arbeitsgespann als Netz weitgehend autonomer Einheiten modelliert.Diese bieten nach außen Dienste zur Steuerung und Dokumentation an, undmüssen zum Teil selbst die Dienste anderer Elemente in Anspruch nehmen. Zur vonKonstruktionsdetails abstrahierten Steuerung und Überwachung von Arbeiten werdenhierbei Prozessdaten verwendet, mit denen eine Einheit ähnlich zu „CommonObject Request Broker“ (CORBA) durch die Sammlung seiner Dienstleistungsobjekteim Netz dargestellt werden kann. Diese Objekte können anhand einer Kennung überein genormtes Data Dictionary identifiziert werden. Die Zugriffe zu den Diensten einesProzessdatenobjektes sind für alle Prozessgrößen gleich.Nur sehr wenige Informationen werden in festen Zeitintervallen, ohne direkte Anforderunggesandt. Diese als Basisdaten definierten Informationen stellen ein wichtigeGrundlage zur Arbeit aller Systemteilnehmer dar. Theoretische und wahre Geschwindigkeit,Zapfwellen- und Motordrehzahlen geben den Anbaugeräten wichtigeAuskünfte über das zentrale Antriebsgerät, den Traktor.


Seite 2 16. März 2001Die Benutzerstation und seine Möglichkeit zur Verwaltung von virtuellen Terminalskann durch „windows on a tractor“ beschrieben werden. In der Art von Windows Anwendungenkann ein LBS Jobrechner die Dienste der Benutzerstation verwenden,um sich dem Bediener grafisch darzustellen und um seine Steuerung vorzunehmen.2. Problemstellung aus der Analyse der Umsetzung der Normdurch HerstellerAuch 3 Jahre nach der Veröffentlichung der LBS Norm gibt es keine breite Palettevon Geräten mit leistungsfähiger und normkonformer Nutzung des Protokolls. Diemomentan am Markt verfügbaren Systeme setzen LBS zumeist in sehr unterschiedlichenInterpretationen um, was dem Landwirt große Probleme bereitet, wenn er versuchtLBS Geräte verschiedener Hersteller zu kombinieren.2.1. Fehlen einheitlicher ImplementierungDie meisten Landmaschinenhersteller haben ihre LBS Systeme ohne Abstimmungmiteinander entwickelt, so dass bei nicht exakt definierten Elementen der Norm jeweilsunterschiedliche Auslegungen gewählt wurden. Zudem wurden Kommentareveröffentlicht, die nicht ausreichend mit den entsprechenden Normpassagen abgeglichenwaren.Da sich bei den von den Landmaschinenherstellern eingesetzten Jobcontrollern derMikroprozessor und das Betriebssystem bzw. BIOS stark voneinander unterscheiden,hätte eine zentral erstellte Referenzimplementierung mit einem hohen Verwaltungsaufwandan alle Systeme angepasst werden müssen. Ein kommerzieller SoftwareHersteller hätte sich diesen Aufwand durch sehr hohe Lizenzgebühren finanzierenlassen müssen, oder er hätte den Programmtext den Firmen offenlegen müssen,damit diese eigenständig eine Anpassung an ihr System vornehmen könnten. Damithätte er jedoch sein internes Wissen preisgeben müssen, was für Softwarehersteller,die mit Programmen und nicht mit Dienstleistungen zu ihren Programmen Geld verdienenwollen, undenkbar ist.2.2. Beschränkte Nutzung der Möglichkeiten des KommunikationssystemsDie Komplexität der Prozesse in dem offenen Kommunikationssystem LBS hebt sichstark von den üblichen Abläufen in einem Jobcontroller einer landwirtschaftlichen


Seite 3 16. März 2001Maschine ab. Diese sind von einer strikten sequentiellen Struktur geprägt, bei dereine definierte Menge von Eingängen bzw. Ereignissen abgefragt wird, und zumeistdirekt in einem stark begrenzten Kontext reagiert werden kann. Ein LBS System istjedoch von vielen Routineaufgaben (z.B. Anfragen beantworten, Alive senden,Messprogramme behandeln) geprägt, bei denen die Ausführung von einigen Nebenbedingungenabhängig ist, und letztendlich zu relativ komplex formatierten CAN Botschaftenführt.Neben den Prozessdaten mit der Vielzahl von Optionen für Messprogramme, Sollwerteund Anfragen führt das Konzept des virtuellen Terminals, einer Art „Windowson a tractor“, mit komplex verknüpften Botschaftssequenzen zum Aufbau des Benutzerinterface,eine neue hohe Komplexität von Aktionsfolgen ein.Die Vielzahl von Routineaufgaben, und die Anforderung, bei allen Aktionen einengroßen Kontext zu beachten, können mit den üblichen Programmiertechniken nursehr unzureichend bewältigt werden.Statt durch Investitionen und Flexibilität die benötigten Programmierweisen langfristigin die eigene Entwicklung einzubringen, werden von Landtechnikherstellern bzw. derenZulieferern Teillösungen gesucht, deren Leistungsgrenzen schon bei etwaskomplexeren Betriebsbedingungen überschritten werden.3. Lösungsansätze für eine standardkonforme LBS UmsetzungDamit LBS eine größere Marktdurchdringung erfahren kann, müssen standardkonformeleistungsfähige Systeme verfügbar sein, die vom Kunden flexibel kombinierteingesetzt werden können.3.1. Einsatz einer Referenzimplementierung durch Open SourcefördernAls mögliche Lösung dieser Anforderung kann die Entwicklung einer Referenzimplementierungunter Federführung einer neutralen Institution in Zusammenarbeit mitNormentwicklern angesehen werden. Wird diese von Landmaschinenherstellern alsOpen Source Projekt gefördert, kann jeder Anwender den verfügbaren Quelltext andas eigene System anpassen. Die Aufgaben zum Test des Systems, zur Weiterentwicklungund zur Anpassung an diverse Jobrechner, können in einem Open SourceProjekt auf alle Beteiligte verteilt werden, sofern jeder erkennt, dass der eigene Nut-


Seite 4 16. März 2001zen die eigene Investition übersteigt. Der Kunde würde dadurch Geräte frei kombinierenkönnen, deren Kommunikationssystem einen leistungsfähigen, identischenApplication Layer zu LBS verwenden.3.2. An Teilaufgaben eines LBS-Systems orientierte modularisierteProgrammbibliothekDie einzelnen Aktivitäten eines LBS-Systems lassen sich am besten durch die Verknüpfungvon mehreren Teilaufgaben beschreiben. Jedes dieser Module kann sokonzipiert werden, dass es die in seiner Schnittstelle angebotenen Dienste effizientund sicher auch in schwierigen Betriebsbedingungen umsetzt, und damit zur Umsetzungvieler Aufgaben optimal eingesetzt werden kann. Als Raster zur Modularisierungbietet sich die Unterteilung der LBS Norm in Bereiche wie Systemverwaltung,Prozessdaten und Benutzerstation an.Durch die Modularisierung können für jedes Element des KommunikationssystemsAnwendungsszenarios entwickelt werden, um die Anforderungen an den jeweiligenBereich der Software festlegen zu können. Zudem können die Module so ausgelegtwerden, dass sie einen sicheren und einfachen Zugriff auf komplexe Elemente desKommunikationssystems ermöglichen.4. Entwicklung einer Open Source LBS ProgrammbibliothekIm Rahmen der Forschergruppe „IKB-Dürnast“ wurde vom Institut für Landtechnikder TUM eine LBS Programmbibliothek entwickelt. Diese Software wird zur Förderungvon LBS als Open Source weiterentwickelt.4.1. Grundlegende ZielsetzungenDie Entwicklung eines hardwareunabhängigen Application Layer für ein LBS Kommunikationssystem,bei dem leistungsfähige Schnittstellen einen einfachen und sicherenZugriff auf alle LBS Dienste für alle Plattformen in identischer Weise bereitstellen,kann als oberste Maxime der Projektentwicklung angesehen werden. DieSoftwarestruktur muss die Integration von Erweiterungen wie z.B. Strategien zur Behandlungvon Interessenkonflikten und die optionale teilweise ISO11783 Kommunikationermöglichen. Daneben muss das Design den Anforderungen eines Echtzeitsystemsentsprechen, und sollte von Compilern für die üblichen Mikroprozessorenunterstützt werden. Zuletzt sollte die Programmbibliothek von den Entwicklern der


Seite 5 16. März 2001Branche mit vertretbarem Einarbeitungsaufwand verstanden werden, und sollte inbestehende Projekten integriert werden können.4.2. Analyse der Abläufe in einem LBS SystemAufbauend auf einer Analyse der LBS Norm wurden Anwendungsszenarios entwickelt,um die Anforderungen an die Flexibilität und Leistungsfähigkeit der Implementierungabschätzen zu können. Für den Bereich der Systemverwaltung wurde dasRisiko von inkorrekt arbeitenden Teilnehmern erkannt, die mit der Identität von fremdenTeilnehmern senden könnten, was zu Adresskonflikten und zur Verfälschungvon Daten führen kann. Dies kann durch teilweisen Programmabsturz, falsches Designoder gar durch Sabotage hervorgerufen werden. Daher wurde die Notwendigkeiterkannt, dass ein Jobrechner aufzeichnet, wenn ein anderer mit seiner Identität (Absenderadresse)sendet, und sich ggf. bei weiderholtem Konflikt vom LBS abmeldet,um in einem erneuten Anmeldeprozess eine neue Adresse zugeteilt zu bekommen.An dieser Stelle wird auch deutlich, dass die Norm um eine Botschaft zur Mitteilungderartiger Konflikte erweitert werden muss.Weiterhin muss damit gerechnet werden, dass zwei Geräte mit dem selben Gerätetypund der selben Standardanbaubposition (z.B.: hinten) eingesetzt werden, wodurchschon eine korrekte Anmeldung verhindert wird, sofern nicht eines der beidenSysteme auf eine virtuelle alternative Anbaupositionskennung ausweicht.Bei Basisdaten, einem eng begrenzten Pool von Informationen (z.B. Zapfwellendrehzahlen,Fahrgeschwindigkeit, Hubwerkstellungen), die vornehmlich vom Traktorzur Information aller Teilnehmer ausgeschickt werden, kommt es häufig vor, dass zurNachrüstung von LBS vorgesehene Terminals diese Daten aussenden, obwohl einTraktorjobrechner vorhanden ist. Daher muss ein System, das diese Informationenverwerten möchte, gezielt die vom Traktorjobrechner gesendeten Daten selektierenund verarbeiten.Bei Prozessdaten muss damit gerechnet werden, dass zu einer Prozessgröße mehrereMessprogramme parallel von unterschiedlichen Teilnehmern angefordert werden.Ein LBS Jobrechner sollte in der Lage sein, diese getrennt von einander bedienenzu können. Vor allem, wenn ein anderer Teilnehmer einen Reset der Messgrößeanfordert, darf dadurch nicht der Wert für andere Teilnehmer verändert werden. BeiSollwerten zu einer Prozessgröße sind Möglichkeiten zur getrennten Verarbeitung


Seite 6 16. März 2001von unterschiedlichen Absendern, und zur selektiven Bestätigung und Ablehnungvon Sollwerten vorzusehen. Gerade bei konkurrierenden Sollwerten sollte eine allgemeineRichtlinie geschaffen werden, der zufolge Absender von zuerst eingetroffeneSollwerten bis auf explizite Rücknahme des Sollwertes oberste Priorität erhalten.Nachfolgende Sollwerte des als Master eingestuften Systems sollten Vorrang gegenüberSollwerten anderer Teilnehmer erhalten, damit das Mastersystem die Sollwerteden aktuellen Betriebsbedingungen anpassen kann.Daneben wurden bei der Entwicklung Interpretationsspielräume und Mängel imNormtext identifiziert, und in Zusammenarbeit mit den Normentwicklern geklärt. Geradeim Bereich der Messprogramme zu einer Prozessgröße mussten unter anderemdie folgenden Details geklärt werden:• wegproportionale (Messwerterfassung getriggert durch die gefahrene Strecke)Messprogramme wurden bei Anwendungen häufig mit wertproportionalen(Messwerterfassung getriggert durch die Messwertänderung) verwechselt• für einen Datensammlungsmodus zur Zwischenspeicherung von Daten fehlt inder Norm ein Befehl zur Anforderung des verzögerten Versandes der Messwerte• Integral- und Mittelwerte lassen sich nur auf Basis einer konstanten Abtastrate(z.B.: bei weg- oder zeitproportionalen Messprogrammen) definieren, was in derNorm nicht explizit herausgestellt wird, und daher vielfach falsch ausgelegt wordenist.4.3. Aufbau der LBS-LibEin LBS-System ist nicht nur als Verknüpfung von Geräten, sondern auch innerhalbvon einem Jobrechner ein in weitgehend autonome Teilaufgaben strukturierbaresNetzwerk. Da jede Teilaufgabe weitgehend auf Basis lokaler (Zustands-) Informationenerfüllt werden kann, bietet sich das objektorientierte Paradigma zum Implementiereneiner LBS Software an. Zudem erleichtert die objektorientierte Modellierungauch die verteilte Administration einer Software, was gerade bei Open Source Projektensehr bedeutend ist.Entsprechend der wichtigsten Zielsetzung eines hardwareunabhängigen ApplicationLayer für LBS Anwendungsprogramme, lässt sich eine grundlegende Aufteilung inLBS Kommunikation und hardwarenahe Schicht zum einheitlichen Zugriff auf dieHardware festlegen. Auf diese Weise kann gewährleistet werden, dass durch die


Seite 7 16. März 2001Anpassung an einen Jobrechner keine Komponenten beeinflusst werden, die für dasVerständnis zwischen LBS Systemen entscheidend sind.Im hardwarenahen Bereich wurde eine Objektstruktur in der Art von Hardwaretreibernerstellt. Ein zentral verwaltendes Objekt verwendet Teilobjekte, um einen vereinheitlichtenZugriff auf die diversen Ressourcen darzustellen. Diese Modularisierungermöglicht auch eine gezielte Verkleinerung der Programmbibliothek, wenn einzelneRessourcen (z.B. Aktorsteuerung, serielle Schnittstelle) nicht benötigt werden.Hardwareunabhängige Anwendungen mit Hardware Zugriff profitieren ebenso vondiesem Abstraktions Layer, so dass Beispielprogramme und ein Open Source Task-Controller (Ausgabe von Daten über RS232) möglich werden.Im LBS Application Layer bilden die vier Teilobjekte eines zentral verwaltenden Objektesdie zentralen Aufgabenbereiche in LBS ab (siehe Abbildung 1). Das SystemverwaltungsobjektLBS_System stellt sich dem Anwender als Manager einer Listevon stellvertretenden Objekten für die unterschiedlichen Teilnehmer und Dienste dar.Dieses Ordnungsprinzip wird konsequent in allen Bereichen verwendet, so dassMessprogramme zur einer lokalen Prozessgröße über die Zugriffskette:LBS_Process – Auswahl der Prozessgröße LBS_Process_Data_Local – Zugriff auf Messprogramm Measure_Progr_Localerreicht werden können.Abbildung 1: Vollausbau der LBS Programmbibliothek


Seite 8 16. März 20014.4. ImplementierungDie LBS Programmbibliothek wurde mit C++ implementiert, da es auf dem weit verbreitetenC aufbaut, und damit in den Bereichen Lernaufwand für Programmierer,Unterstützung durch Compiler und Integration in bestehende Projekte eindeutigeVorteile aufweist. Zudem unterstützt C++ als objektorientierte (OO) Programmiersprachedie Implementierung der Module mit Objekten und deren Unterscheidungvon Schnittstelle und Implementierungsdetails. Im Vergleich zu anderen OO Sprachenkann man bei C++ sehr gut den Overhead (z.B. vergrößerte Laufzeit) steuern,indem für einzelne Teilaufgaben eine Kosten-Nutzen Analyse der verfügbaren Implementierungsalternativendurchgeführt wird.Die STL Container von C++ unterstützen die geforderte Flexibilität des Systems. Dadie für Echtzeitsystem problematische Allozierung von Speicher auf nicht zeitkritischeBereiche beschränkt werden kann, waren diese zumeist statischen Arrays vorzuziehen.Zur Steigerung der Effizienz von kurzen, zumeist dem Setzen und Auslesenvon einfachen Werten dienenden Funktionen konnten das C++ Sprachmittel inlineeingesetzt werden.Durch das C++ Sprachmittel Namespaces konnten ohne Einfluss auf die Programmausführungzusammengehörende Objekte zu Gruppen zusammengefasst werden.Damit wird die Quelltextnavigation mit einem Class-Browser wesentlichübersichtlicher. Zudem können so Objekte für die Schnittstelle zu einem Anwendungsprogrammund Objekte zur Implementierung der Aufgaben streng getrenntwerden. Da die meisten Objekte viele Schnittstellenfunktionen nur zur Erfüllung internrelevanter Dienste für andere Objekte bereithalten, wurden Interface Abwandlungenerzeugt, deren Schnittstelle nur noch die anwendungsrelevanten Bestandteileenthält. Damit werden die Objekte übersichtlicher. Hervorzuheben ist, dass diesdurch inline ohne negativen Einfluss auf die Ausführungsgeschwindigkeit realisiertwird.4.5. Entwicklungsphasen der LBS-LibDie Entwicklung der LBS-Lib kann in mehrere Phasen eingeteilt werden. In einerersten Entwicklungsphase wurde die Software in Teilen mit Hilfe eines pseudo BIOSauf einem PC mit für PC’s verfügbaren Entwicklungswerkzeugen programmiert und


Seite 9 16. März 2001getestet. Anschließend wurde die Software auf einen realen Jobrechner (ESX vonSensor-Technik Wiedemann) als Ziel Plattform überführt.Zum Test der LBS-Lib mit realen Jobrechnern wurde ein Test Szenario entwickelt,bei dem ein simulierter Traktorjobrechner in einer Jobrechner Testumgebung abhängigvon Sensorwerten LBS Basisdaten (z.B. Geschwindigkeiten, Strecken, Hubwerkstellung)bereitstellt (siehe Abbildung 2). Zudem können mit Schaltern der Testum-Abbildung 2: Test der LBS-Lib in realer Umgebunggebung Messprogramme für Prozessdaten eines zusätzlichen Jobrechners (hier einImplement Indicator = IMI) gestartet bzw. gestoppt werden. Mit Leuchtdioden wirdzudem der Empfang eines neuen Wertes zu den Prozessdaten signalisiert. Auf dieseWeise kann in einer realen Umgebung die Funktion von analogen und digitalen Sensorenund Aktoren getestet werden. Der IMI-Jobrechner kann abhängig von den Basisdatenentsprechend der einprogrammierten Arbeitsbreite Informationen wie Arbeitsflächeermitteln, und als Prozessdatengröße am LBS BUS anbieten. Zudemrepräsentiert sich der IMI auf einem virtuellen Terminal und zeigt dort dynamisch einzelneMesswerte an. Mit einem CANalyzer wird dabei der gesamte Datenverkehr aufdem CAN BUS aufgezeichnet und überprüft.


Seite 10 16. März 20015. Einsatz der LBS-LibDie LBS-Lib unterstützt die einfache und schnelle Entwicklung von leistungsfähigenAnwendungen wesentlich, indem komplexe Aufgaben durch einfache Funktionenzugänglich gemacht werden, und Routineabläufe automatisch ausgeführt werden.So reicht ein einziger Funktionsaufruf, um einen Teilnehmer am LBS anzumelden,für den bis zum Systemstop automatisch Aufgaben wie Senden einer regelmäßigenAlive Botschaft, oder Antworten auf Anfragen nach dem Bezeichner erfüllt werden.Entsprechend werden Messwertanfragen zu lokalen Prozessdaten automatisch beantwortet,und eintreffende Sollwerte werden für eine effiziente Entscheidung überAkzeptanz oder Ablehnung passend vorverarbeitet.5.1. Exemplarische Verwendung der Objekte der LBS-LibDer Einsatz des Objektes LBS_System zum Zugriff auf die Systemverwaltungsfunktionenvon LBS wird in Abbildung 3 beschrieben. Abbildung 4 zeigt exemplarisch dieVerwendung von LBS_Base zur Arbeit mit LBS Basisdaten.Abbildung 4: Anwendung vonLBS_SystemAbbildung 3: Anwendung vonLBS_Base


Seite 11 16. März 2001Das Starten eines Messprogramms beieinem Jobrechner wird als Beispielanwendungin Abbildung 5 dargestellt. Daseinfache Konfigurieren und Ausleseneines Sensoreinganges wird in Abbildung6 gezeigt.Abbildung 6: Anwendung vonLBS_Process5.2. Programmentwicklung mitder LBS ProgrammbibliothekBetrachtet man eine einfache Anwendungeines IMI (Implement Indicator),der externe Informationen mit festeninternen Größen (z.B. Arbeitsbreite, Bedingungenfür Arbeitszustand) verknüpft,um Größen wie Gesamtzeit, Arbeitsstatusund Arbeitsfläche am LBSBUS durch Prozessdaten bekanntzumachen, so stellt sich das Programm als sehreinfach strukturiert dar (siehe Abbildung 7). Hierbei ist entscheidend, dass die aufgeführteneinzelnen Aktionen zumeist durch eine Programmzeile umgesetzt werdenkönnen.Abbildung 5: Anwendung von Sensor_IO


Seite 12 16. März 2001Abbildung 7: Ablaufdiagramm einer IMI AnwendungAbbildung 8: Einfache Maske auf virtuellem Terminal


Seite 13 16. März 2001Möchte man für einen Jobrechner eine Maske auf einem virtuellen Terminal erstellen,so wird dies auch durch die LBS-Lib wesentlich vereinfacht. Die Bildschirmanzeigevon Abbildung 8 kann durch relativ wenige Programmzeilen erzeugt werden,wobei z.B. mit einem einzigen Funktionsaufruf eine Linie gezeichnet werden kann,oder ein beliebig langer Text ausgegeben werden kann.6. LBS-Lib als Open Source ProjektNach der Entwicklung und Dokumentation der Software für eine erste Betaversion,muss eine effektive Weiterentwicklung in einer zentral koordinierten Arbeit vielerBeteiligter erfolgen.6.1. OrganisationZur Weiterentwicklung der LBS-Lib sollen die in Abbildung 9 dargestellten Kreisläufeetabliert werden. Erfahrungsaustausch und Angebot der Quelltexte mit Dokumentationund Beispielen werden von zentraler Stelle im Institut für Landtechnik der TUM() erfolgen. Im Verbundmit den anderen Bereichen von Wissenschaft, allgemeinen Anwendern und Interessiertenund der Landmaschinenindustrie sollen ausführliche Tests, Portierung aufunterschiedliche Systeme und Erweiterung der Software gemeinsam betrieben werden.Abbildung 9: Kreisläufe der Entwicklung der Open-Source LBS-Lib


Seite 14 16. März 20016.2. Wichtige Ziele für die WeiterentwicklungUm eine weite Verbreitung der LBS-Lib zu fördern, sind intensive Tests erforderlich.Diese könnten aufgrund der modularen Struktur der Software auf Gruppen verteiltwerden, die für einzelne Aufgabenbereiche die Verantwortung für die Fehlersucheübernehmen. Die Leitung dieser Gruppen kann von Vertretern einer in diesem Bereichsehr erfahrenen Firma übernommen werden. Meldungen von Fehlern und derenBehebungen können damit auf mehrere Personen, Firmen und Institutionenverteilt werden. Anerkannte Korrekturen und Verbesserungen der Software solltenvon der zentralen Koordinationsstelle in die Referenzversion der LBS-Lib übernommenwerden. Bei Erweiterungen und tiefergehenden Umstrukturierungen der LBS-Lib bietet sich eine Versionsverwaltung in der Art von Linux an, bei dem die ersteVersionsziffer die Hauptrelease (Beta 0, erste stabile 1), die zweite Produktions-und Entwicklerzweige unterscheidet (stabil gerade, instabil ungerade) unddie letzte Ziffer die Fortentwicklung bezeichnet.Damit diese Tests auf möglichst vielen Systemen durchgeführt werden können, istes erforderlich den „Hardware Adaption Layer“ (hardwareabhängige Schicht um eineneinheitlichen Zugriff auf Hardware zu ermöglichen) auf möglichst viele Jobrechneranzupassen. In der Art der schon verfügbaren Anpassungen für PC, ESX undProzessormodul (IMI) sollten diese als Teile der LBS-Lib verwaltet werden.Damit interessierten Anwendern die Entwicklung von Testsystemen erleichtert wird,bietet es sich an, an zentraler Stelle auch ein Archiv von Beispielprogrammen zu e-tablieren. So kann auch ein für Forschungszwecke ausreichender Task Controller alsBeispielanwendung zur Verfügung gestellt werden, damit kommerzielle Anbieter diesenzu leistungsfähigen Produkten weiterentwickeln.Sobald LBS, gefördert von der LBS-Lib, für viele Geräte verfügbar ist, sind problematischeBetriebsbedingungen zu erwarten, die einheitliche Strategien der Anwenderprogrammeerforderlich machen. So sind Strategien und Verhaltensregeln zurVermeidung und Lösung von Interessenkonflikten nötig. Neben allgemeingültigenRegeln, wie z.B. soweit möglich mit MIN und MAX Sollwerten einen erlaubten Bereichvorzugeben, statt einen einzelnen festen Wert zu diktieren, ist eine zentraleDokumentation von problematischen Anwendungsszenarien nötig. Zum einen kannman anhand von Diagrammen erkennen, welche Dienstleistungen von unterschiedlichenGeräten wiederum von der Steuerung der selben Prozessgröße eines dritten


Seite 15 16. März 2001Gerätes abhängig sind (z.B. zwei Anbaugeräte müssen Geschwindigkeit der Traktorssteuern). Zum anderen kann daran erkannt werden, welche Prozessgrößen einerMaschine voneinander abhängig sein können (z.B. Zapfwellendrehzahl und Fahrgeschwindigkeiteines Traktors sind je nach Getriebe nur sehr bedingt unabhängig),und welche Konsequenzen dies für das gesamte Arbeitsgespann haben kann. Gegebenenfallskönnen derartige Erkenntnisse auch zu Erweiterungen der LBS-Lib undder damit implementierten Kommunikationsnorm führen, um zur Konfliktlösung erforderlicheInteraktionen der Maschinen zu ergänzen.Zieht man für die weitere Entwicklung der LBS-Lib auch eine teilweise Interaktion mitISO 11783 Geräten in Betracht, ist es jedoch ratsam, nur die von LBS bekanntenKommunikationsmittel zu übernehmen. Zum einen beschränkt sich die Anpassungder Kommunikation weitgehend auf eine andere Formatierung der Botschaften, sodass Applikationen sich ggf. dynamisch an das jeweilige System anpassen können.Zum andern sind auch schon mit der sehr strikten Modellierung von LBS Teilnehmernals Black Box, und der damit verbundenen Definition einer konstruktionsunabhängigenSchnittstelle, sehr viele Abhängigkeiten zwischen Systemen zu erwarten.Je komplexer die Abhängigkeiten in einem Netzwerk werden, desto schwieriger wirdjedoch die Erkennung und Beseitigung von Interessenkonflikten. So führt der in ISO11783 vorgesehene direkte steuernde Zugriff auf Teile einer Maschine (z.B. Getriebeeines Traktors) neue, nur schwer zu erkennende Abhängigkeiten von Regelungswünschenein. Somit ist zur Erkennung des Zusammenhangs zwischen Zugriff aufdas Getriebe des Traktors und aktueller Fahrgeschwindigkeit die Kenntnis von Konstruktionsdetailsdes eingesetzten Traktors nötig.Verlässt sich eine Gerätesteuerung jedoch darauf, dass der Jobrechner einer anderenMaschine am besten entscheiden kann, wie er die geforderten Regelgrößen einhaltenkann, ist die Steuerung über konstruktionsunabhängige Prozessgrößen einprobates und für LBS und ISO11783 anwendbares Vorgehen.7. AusblickDie LBS-Lib wurde in zweijähriger Arbeit erstellt und ist zu einer kompletten Betaversionentwickelt worden. Die verfügbare Bibliothek wurde mittlerweile auf einem deutschenund englischen Workshop vorgestellt. Dort konnten alle Beteiligten die Leistungsfähigkeitkennenlernen und Erfahrungen im Einsatz der Programmbibliothek


Seite 16 16. März 2001zur Anwendungsentwicklung sammeln. Es ist zu erwarten, dass viele Hersteller denBedarf einer leistungsfähigen LBS Kommunikation erkennen und feststellen, dassihre Probleme mit der LBS-Lib als passendem Werkzeug einfach, zuverlässig undschnell gelöst werden können. Damit könnte sich dieses Projekt langfristig überDeutschland hinaus zu einem de-facto Standard entwickeln.8. LiteraturAUERNHAMMER, H.; DEMMEL, M. (2000): Innovationen in Technik und Bauwesen füreine wettbewerbsfähige und nachhaltige Landwirtschaft. In: KTBL-SchriftAUERNHAMMER, H.; DEMMEL, M.; SPANGLER, A. (1999): Betriebsdatendokumentationmit LBS und GPS für Traktor-Gerätekombinationen. In: Tagung Landtechnik1999: VDI Verlag, VDI Berichte 1503: 217-221BALZERT, H. (1996): Lehrbuch der Software-Technik, Software-Entwicklung. Heidelberg,Berlin, Oxford: Spektrum, Akad., Verl, 1009 S.BERGNER, K; RAUSCH, A; SIHLING, M. (1997): Using UML for Modeling a DistributedJava Application. In: ForSoft project A1 on „Component-Based Software Engineering“of Insitut für Informatik – Technische Universität MünchenDEMMEL, M.; AUERNHAMMER, H. (2000): Elektronik in der Landwirtschaft. In: KTBL-Schrift 390DEUTSCHES INSTITUT FÜR NORMUNG (1997): DIN9684: Landwirtschaftliches BUS System.LGPL LIZENZ: URL: MOEN, R. (November 17, 1999): Fear of Forking - How the GPL Keeps Linux Unifiedand Strong. In: Linuxcare, Featured Article;URL: MYERS, N. C. (1997): C++ in the real World - Advice from the Trenches. In: Dr.Dobb’s Journal, Fall 1997 Careers issue;URL: STAFF, J. (February 19, 2000): „Giving something back“ to the Linux and/or OpenSource community. Linux.com;URL: STROUSTRUP, B. (1998): Die C++-Programmiersprache. Bonn: Addison-Wesley-Longman, 956 S.VELDHUIZEN, T. L.; JERNIGAN, M. E. (1998): Will C++ be faster than Fortran? Of: Departmentof Systems Design Engineering, University of Waterloo;URL:


Seite 17 16. März 2001YORK, D. (2000): In the trenches – Twelve Rules For A Better Open Source Project.In: Linux Magazine, February 2000,URL:

Weitere Magazine dieses Users
Ähnliche Magazine