Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

17.11.1978 - 

Mikrorechner-Software:

Rückkehr in die Programmiersteinzeit?

17.11.1978

"Im Gegensatz zu dem rasanten Tempo bei der Entwicklung der Hardware-Komponenten für Mikrorechner steckt die Entwicklung der zugehörigen Software noch in den Kinderschuhen." Götz Hoffmann, Spezialist für Mikrorechner-Software bei der Compac GmbH in Essen, geht noch weiter. Seiner Ansicht nach fand hier sogar "eine Rückkehr in die Steinzeit der Programmierung" statt, verglichen mit dem heute existierenden Standard bei Mini- beziehungsweise Prozeßrechnern. Ein weiteres, nicht zu unterschätzendes Problem sei zudem - und das bestätigten alle von uns befragten Mikro-Spezialisten - die unterschiedliche Auslegung des Begriffes "Mikrocomputer". Fünf lnsider-Statements sollen zur Aufklärung beitragen. hö

Gunter Haselbach

Geschäftsführer, Compac GmbH, Essen

Im Gegensatz zu dem rasanten Tempo bei der Entwicklung der Hardware-Komponenten für Mikrorechner (Prozessoren, Speicher, intelligente Interfaces, DMA-Steuerungen, Arithmetik-Prozessoren) steckt die Erstellung der zugehörigen Software noch in den Kinderschuhen. Vergleicht man den Stand der Softwareentwicklung bei den Mikrorechnern mit dem heute existierenden Standard bei den Mini- beziehungsweise Prozeßrechnern, so kann man von einer Rückkehr in die "Steinzeit der Programmierung" sprechen.

Dieser Zustand hat mehrere Gründe:

- Mangelnde Software-Unterstützung der Bauelemente-Hersteller;

- Vielfalt der am Markt befindlichen Prozessortypen mit ihren unterschiedlichen Strukturen und Befehlssätzen;

- Unterschiedlichste Systemkonzeptionen bei der Entwicklung von Mikrorechner-Systemen;

- Fehlen einer einheitlichen Programmiersprache.

Alle diese Punkte haben die Entwicklung von Standard-Software bisher wesentlich erschwert. Da aber gerade die Programmierkosten heute einen sehr hohen Anteil an den Gesamtkosten eines Mikrorechnersystem in der Prozeßrechnertechnik ausmachen, ist die Steigerung der Effektivität bei der Programmerstellung die nur durch eine Standardisierung von Software-Moduln und eine Anpassung der Programmiersprache an das Problem erreicht werden kann, dringend erforderlich.

Ein wichtiges Hilfsmittel für die Verringerung des Software-Aufwandes ist die Einführung einer prozeßorientierten Programmiersprache die - abgesehen von den üblichen Anforderungen an eine solche Sprache - speziell folgende Eigenschaften aufweisen müßte: - Anpassungsfähigkeit des Compilers an verschiedene Prozessoren und Mikrorechner-Strukturen;

- Ausnutzbarkeit spezieller Hardware-Funktionen;

- Möglichkeit zur Einfügung von Programmen in Maschinensprache;

- Trennbarkeit von maschinenabhängigen und maschinenunabhängigen Programm-Moduln.

Der Einsatz einer solchen Programmiersprache wie sie etwa Pearl werden konnte, hat den Vorteil, daß die meisten Programme beim Obergang von einem Rechner zum anderen beziehungsweise bei Weiter- und Neuentwicklungen wieder verwendbar sind. Lediglich ein geringer Anteil der Software ist an die speziellen Hardware-Schnittstellen anzupassen und neu zu schreiben.

Eine weitere wesentliche Voraussetzung für die Reduzierung des Programmieraufwandes ist der Aufbau von geeigneten Betriebssystemen für Mikrorechner, die aus den oben genannten Gründen soweit wie möglich in einer höheren Programmiersprache abgefaßt sein sollten. Diese Programmsysteme haben die Aufgabe, den Programmierer von allen rechnerspezifischen Problemen zu entlasten. Im einzelnen sollte ein solches Betriebssystem für den Einsatz in der Prozeßautomatisierung folgende Aufgaben erfüllen können:

- Echtzeitverarbeitung und Datum-/ Uhrzeitverwaltung;

- Prioritätsgesteuerte Programmverwaltung für quasi-parallelen Ablauf verschiedener Programme (Multi Programming);

- Interrupt-Verarbeitung;

- Interaktive Steuerung der Programme untereinander;

- Verwaltung der Peripheriegeräte;

- Bereitstellung von Standard-Programmen wie zum Beispiel Konvertierungsroutinen und Arithmetik-Routinen;

- Hardware-Testmöglichkeiten;

- Selbstüberwachung des Rechners und Fehlerdiagnose.

Neben diesen Systemprogrammen ist außerdem die Schaffung von Anwender-Programm-Bibliotheken anzustreben, die für die in der Prozeßautomatisierung immer wiederkehrenden Aufgaben zum Beispiel folgende Programme enthalten sollten: Ablauf- oder Verknüpfungssteuerung, Meßwert-Verarbeitung mit Grenzwertkontrolle, Meldungsprotokollierung und Kopplungen zu anderen Rechnersystemen .

Alle genannten System- und Anwenderprogramme müssen in einer höheren Programmiersprache geschrieben, übersichtlich strukturiert, einfach zu warten, maschinenunabhängig, bedienerfreundlich und mit klar definierten Schnittstellen versehen sein, um eine Anwendung in weitem Rahmen zu ermöglichen.

Die genannten Forderungen nach Einführung einer einheitlichen problemorientierten Programmiersprache, Schaffung von Anwender- und System-Software stellen die Grundlage für die effektive Programmierung von Rechnersystemen in der Prozeßautomatisierung dar, mit der es gelingen wird, den Software-Aufwand um bis zu 80 Prozent gegenüber dem heutigen Stand zu senken.

Egbert Hirschfelder

PSI-Gesellschaft für Prozeßsteuerungs- und Informationssysteme mbH, Berlin

Der Einsatz von Mikrocomputern für die Prozeßautomatisierung läßt sich in drei Aufgabenbereiche teilen:

- Aufgaben, die in früheren Jahren von Prozeßrechnersystemen abgewickelt wurden: Diese Aufgaben stellten nur geringe Anforderungen an den Umfang der Peripherie, an die Größe des Speichers und an die Reaktionsgeschwindigkeit des Rechnersystems.

- Aufgaben, die sich aus der Dezentralisierung komplexer Systeme ergeben: Mikrocomputer werden dafür als Satelliten an Prozeßrechner gehängt, um eigenständige Funktionen abzuwickeln. Beispiele dafür sind Steuer-, Regel- und Bedienfunktionen.

- Aufgaben, für die der Einsatz eines Mikrocomputers nur aufgrund der geringen Hardwarekosten interessant geworden ist.

Besonders aus den beiden zuerst genannten Aufgabenbereichen ist ersichtlich, daß die Anforderungen für die Mikrocomputersoftware aus den in Prozeßrechnern bestehenden Softwaresystemen abgeleitet werden können. Das gilt speziell für Realzeitbetriebssysteme und Bibliotheksprogramme, wie sie von kleinen Prozeßrechnersystemen her bekannt sind.

Die Betriebssysteme von Mikrocomputern sollten

- interrupt-gesteuert sein;

- maximal 30 resident im Hauptspeicher liegende Anwenderprogramme führen können;

- minimal drei Prioritätsebenen und einen Verriegelungsmechanismus haben;

- eine E/A-Verwaltung für Daten- und Prozeßperipherie besitzen, dazu die Treiber und Handler für die Standardperipherie;

- Wartezeitaufträge abwickeln können, Alarmbausteine besitzen etc.

Um einen Test unter Realzeitbedingungen zu ermöglichen, ist ein entsprechendes Testsystem zu integrieren.

Betriebssysteme für Prozeßrechner werden normalerweise speziell jeder Anlage angepaßt. Für Mikrocomputer sollte aus Kostengründen die Standardsoftware in ROM's gelegt werden.

Damit ist eine spezielle Anpassung nur noch in geringem Maße möglich. Da jedoch der volle Adreßraum des Arbeitsspeichers in Mikrocomputern kaum genutzt wird, kann für ein Standardbetriebssystem ein fester Adreßbereich reserviert werden. Nicht benötigte Betriebssystemfunktionen bräuchten hardwaremäßig nicht bestückt zu werden.

Für den Benutzer muß die Möglichkeit bestehen, eigene Betriebssystemmodule, insbesondere Treiber und Handler, an den bestehenden Standard anzuschließen.

Als Bibliotheksprogramme werden neben den üblichen Umcodierroutinen eine Gleitkomma-Arithmetik, eine Pufferverwaltung und ein Warteschlangensystem gefordert.

Für die Programmentwicklung weichen die hier gestellten Anforderungen von denen anderer Anwender kaum ab.

Ein DOS-System mit Editor, Macroassembler, Compiler, Lader und Binder sowie File-Management sollten im Programmentwicklungssystem enthalten sein.

Die speziellen Anforderungen von seiten der Prozeßautomatisierung konzentrieren sich daher auf das Realzeitverhalten der Anwenderprogramme und eine entsprechende Betriebssystemunterstützung .

Helmut Hoseit

Hoseit Systeme GmbH, München

Zunächst einmal gehe ich davon aus, daß unter "Prozeß" nicht jegliche Realzeitanwendung verstanden wird, sondern daß hier Prozesse im engeren Sinne, das heißt technische Prozesse gemeint sind. Mit dieser allgemein üblichen Einschränkung ist ein "Prozeßrechner" also ein Rechner, der zur Steuerung eines technischen Prozesses eingesetzt wird. Für diese Zwecke wurden bisher die auch unter dem Namen "Minicomputer" bekannt gewordenen, realzeitfähigen, interruptgesteuerten, üblicherweise 16-bit-breiten Wortrechner verwendet. Die Anforderungen an die Software für derartige Anwendungen sind hinreichend bekannt. An diesen Anforderungen ändert sich allein durch die Tatsache, daß die Zentraleinheit des Rechners aus einem Mikroprozessor besteht, überhaupt nichts.

Da nun aber die Mikros keine Minis sind, ist die Substitution doch nicht ganz so einfach. Sofern man für die Steuerung technischer Prozesse einen Mikrocomputer als Alternative zu einem Mini überhaupt ernsthaft in Betracht ziehen kann, wird es sich entweder um kleinere Systeme handeln oder um einzelne Komponenten eines stark dezentralisiert konzipierten Systems. In beiden Fällen übernimmt der Mikrocomputer eine sehr exakt umrissene Menge von Funktionen. Man wird ihn, um seinen Kostenvorteil voll ausnutzen zu können, hinsichtlich seiner Leistungsfähigkeit und seines Ausbaus so dimensionieren, daß er diese Funktion mit einem wirtschaftlich noch vertretbaren Maß an Reserven gerade erfüllen kann. Dadurch ergeben sich in der Liste der Anforderungen an die Software einige Gewichtsverschiebungen gegenüber klassischen Prozeßrechnern.

An oberster Stelle aller Anforderungen an die Prozeßrechner-Software steht die Sicherheit. Dieses Sicherheitsargument, das bereits bei der Planung der Software in Form von Modularität, Strukturierung und ausreichender und eindeutiger Dokumentation berücksichtigt werden muß, hat vor allem Auswirkungen auf die Methodik des Softwaretests. Bei Prozeßrechner-Software reicht im allgemeinen nicht aus, daß das Funktionieren des Gesamtsystems demonstriert wird. Die Software muß vielmehr in einer Art Zerreißprüfstand vorher durch speziell geschriebene Prüfprogramme und eventuell speziell angefertigte Hardware unter allen theoretisch erdenklichen Konstellationen erprobt worden sein. Diese Vorgehensweise, die sehr viel mehr Aufwand bedeutet als die übliche Methode des "Testens bis es geht", ist bei Mikros sofern besonders schwierig einzuhalten, weil dort die Hardware- und Softwareunterstützung für die erforderlichen Testrahmen im allgemeinen nicht vorhanden ist. Als weiterer Baustein zum Sicherheitswall sei das Kapitel "Abschließbarkeit" genannt. Hierunter verstehe ich die von der Konzeption und schließlich der technischen Realisierung der Software her gegebene Unmöglichkeit, ein einmal installiertes System vor Ort absichtlich oder fahrlässig zu verändern. Bei Mikrocomputern ist diese Forderung am leichtesten dadurch zu erfüllen, daß die gesamte Software in PROMs gespeichert wird. Eine Summenkontrolle beim Anlauf des Systems hat sich als weitere Sicherheitsmaßnahme gut bewährt.

Nach den Sicherheitsanforderungen an zweiter Stelle stehen bei Prozeßrechnern die Forderung in puncto Geschwindigkeit. Da die Mikrocomputer, wie erwähnt, über nur beschränkte Leistungsreserven verfügen, rückt dieser Punkt an eine andere Wertigkeit, als er sie bei den meisten Prozeßrechnern haben mag. Nach dem heutigen Stand der Technik bedeutet dies für mich immer noch, daß sehr maschinennah, das heißt im allgemeinen in Assembler programmiert werden muß. Daß dies die Lesbarkeit, Änderbarkeit und Übertragbarkeit eines Programmes nicht unbedingt negativ beeinflussen muß, wird von den kompromißlosen Anhängern der problemorientierten Sprachen oft übersehen. Zeitkritische Programmschleifen müssen, eventuell in einer Nachentwicklung der Software, auf Geschwindigkeit gezüchtet werden. Die Interruptfähigkeit des Prozessors, die man für Prozeßrechnereinsätze als gegeben voraussetzen muß, ist mit möglichst wenigen Befehlen möglichst intensiv zu nutzen, und zwar ohne den Einsatz eines millisekundenfressenden Betriebssystems. Nur so bekommt man die Laufzeiten und damit die Leistungen des Systems so in den Griff, daß der Mikro sich letzten Endes nicht als überfordert herausstellt.

Wenn man den Aufwand zur Erfüllung der genannten und aller anderen bekannten Forderungen an die Software addiert, so kommt man leicht zu dem Ergebnis, daß sich der Einsatz eines Mikrocomputers wegen des damit erhöhten Softwareentwicklungsaufwandes nicht rentiert, womit sich der Mikro einmal wieder für das fundamentale Mißverständnis gerächt hätte, er sei ein spottbilliges Äquivalent eines Minis. Die eigentlichen Vorteile, die sich mit der Verwaltung von Mikros erzielen lassen, zeigen sich erst bei solchen Systemen, die in mehreren, möglichst vielen gleichartigen Installationen zur Welt gebracht werden sollen.

Prof. Dr.-lng. Rudolf Lauber

Institut für Regelungstechnik und Prozeßautomation der Universität Stuttgart

Mit der rasanten Entwicklung der Hardware von Mini- und Mikrocomputern (wobei die Benennungen "Mini" und "Mikro" nur bezüglich des Volumens und des Preises, nicht aber bezüglich der Leistungsfähigkeit berechtigt sind!) hat die Herstellungstechnik für die Software nicht Schritt gehalten. Die als Prozeßrechner eingesetzten Minirechner und erst recht die in technische Geräte und Prozesse eingebauten Mikrorechner der gegenwärtig marktbeherrschenden 8-Bit-Generation werden nach wie vor nahezu ausschließlich in maschinennahen Programmiersprachen, vorwiegend in Assemblersprachen, programmiert - kaum anders, als die alten Röhrenrechner vor 20 Jahren. Mit dem Eindringen der Mikrorechner in immer neue Anwendungsbereiche erwachsen daraus zunehmend Probleme:

- Die Software-Erstellungs- und Wartungskosten für sogenannte "Einmal-Systeme" steigen prohibitiv an.

- In neuen Anwendungsbereichen, wie etwa im Maschinenbau, ist bisher nur wenig Personalkapazität mit Elektronik- oder gar mit Softwarekenntnissen vorhanden, wie sie für die maschinennahe Programmierung erforderlich wäre.

- Die Diskrepanz zwischen der Langlebigkeit vieler technischer Systeme (zirka 10 bis 30 Jahre) und der kurzen Generationszeit der in diese Systeme einzubauenden Mikroprozessoren (zirka fünf Jahre) kann enorme Schwierigkeiten für die spätere Pflege und Wartung verursachen.

Zur Lösung dieser Schwierigkeiten müssen - insbesondere bezüglich der Software - folgende Forderungen gestellt werden:

- Die Handhabbarkeit der Mini- und vor allem der Mikrocomputer muß entscheidend verbessert werden. Dies bedeutet, daß zur Handhabung der Software (Erstellung, Pflege und Wartung) Personal mit niedrigem Ausbildungsstand einsetzbar sein muß.

- Die Übertragbarkeit der Software muß verbessert werden, um die Software von der auch in Zukunft noch zu erwartenden raschen Weiterentwicklung der Hardware zu entkoppeln.

- Die Software muß der Dezentralisierung der Hardware Rechnung tragen.

- Durch Rechner-gestützte Verfahren muß die Herstellung zuverlässiger, einfach dokumentierbarer und leicht wartbarer Software vereinfacht werden.

Die für die Zeit-unabhängige Datenverarbeitung konzipierten höheren Pogrammiersprachen, wie zum Beispiel Fortran, Basic und Cobol, sind für Echtzeitprogramme im allgemeinen nicht geeignet. Denn bei diesen muß, zusätzlich zu den algorithmischen Zusammenhängen, auch die zeitliche und logische Synchronisierung zwischen Programm- und Prozeßgeschehen, der rechtzeitige und parallele Ablauf der Programme und die Ein- und Ausgabe von Prozeßsignalen mit entsprechenden Sprachmitteln formulierbar sein.

In den letzten Jahren wurden auf verschiedenen Wegen höhere Programmiersprachen mit Spracheigenschaften für die Echtzeitprogrammierung konzipiert:

- Die naheliegendste Methode war die Erweiterung vorhandener höherer Programmiersprachen. So entstanden verschiedene Hersteller-abhängige Varianten von Fortran- und Basic-Erweiterungen. Die Echtzeit-Eigenschaften werden durch den Aufruf von Betriebssystem-Funktionen des jeweiligen Zielrechners verwirklicht, so daß die Programme nicht auf Rechner mit anderen Betriebssystem-Funktionen übertragbar sind.

Gegenwärtig sind Bemühungen im Gange, zu einer einheitlichen Form eines "Prozeß-Fortran" beziehungsweise "Prozeß-Basic" zu kommen.

- Die zweite, jedoch aufwendigere Methode besteht darin, neue Prozeßprogrammiersprachen mit eigenen Sprachelementen für die Echtzeit-Programmierung und die Prozeßsignal-Ein-Ausgabe zu schaffen. Mit den Ausdrucksmitteln dieser Sprachen können dann Automatisierungsprogramme weitgehend Maschinen-unabhängig formuliert werden.

Dr. Dieter Noga

Diplom-Mathematiker und Bereichsleiter in der Geschäftsstelle Zentrale Projekte der SCS Scientific Control Systems GmbH, Hamburg

Wer wissen will, ob und wie Quantität in Qualität umschlagen kann, der sollte sich mit Mikros befassen. Einerseits sind Mikros nur Rechner - kleiner, billiger, aber auch weniger komfortabel als die nächstgrößere Klasse. Deshalb sieht die Computergemeinde mit ungläubigem Staunen, wie sich nun ein erweiterter Nutzerkreis anschickt, das bereits mehrfach bezahlte Lehrgeld noch einmal zu entrichten. Andererseits kann man einen Mini nur schlecht am Handgelenk tragen Es gibt aber kaum Geräte oder Maschinen, die nicht durch Mikros intelligenter gemacht werden könnten.

Bislang anderweitig realisierte Funktionen und die mit ihnen verbundenen Wertschätzungen wandern in die Mikroelektronik. Fähigkeiten, auf die sich professioneller Stolz und eine ökonomische Existenz sicher zu gründen schienen, werden nutzlos. Der Mikro löst eine industrielle Revolution aus.

Indes ist das intelligentere Produkt, isoliert für sich betrachtet, nur der weniger wichtige Aspekt. Wo Rechner in einem Gerät vorhanden sind, da hat man auch das, was im Jargon ,,intelligentes Interface" heißt. Intelligente Geräte können leichter in von Rechner bestimmte Zusammenhänge - seien dies Informations- oder Steuerungssysteme - eingebaut werden. Der Mikro macht integrierte Systeme möglich, die bislang aus prinzipiellen oder ökonomischen Gründen unmöglich waren und wird so zu einem Motor für die weitere Computerisierung der Gesellschaft.

Dieser Trend zeichnet sich auch im Mikro-Geschäft großer Softwarehäuser und Systemhäuser ab. Bei der SCS begann es DV-technisch: Zuerst waren Bildschirm- und Leitungs-Controller zu programmieren. Ein Kunde brauchte ein kompaktes Betriebssystem für einen Mini-kompatiblen Mikro. Aber schnell dominierte der integrative Aspekt. Die Software für ein Datenerfassungssystem mit abgesetzten intelligenten Arbeitsplätzen war zu konzipieren und zu realisieren. Ein auf Mikros basierendes Textsystem legte die Kopplung an einen Großrechner und das auf ihm bewirtschaftete Datenbanksystem nahe. Für ein schlüsselfertiges landesweites Informations- und Radiokommunikations-System boten sich Mikros als Funkeinkopplungs-Controller an. Da SCS bereits vor Jahren in der Labordatenverarbeitung Kleinstrechner für die Vorverarbeitung eingesetzt hatte, war es nur folgerichtig, Mikros in Überwachungssystemen als intelligente Schnittstellen vor Meßgeräten zu verwenden. In eben dieser Tradition steht auch, daß SCS in seinen fernsehtechnischen Aktivitäten die Planung intelligenter Interfaces für die Automation in Studios maßgeblich mitgeprüft hat.

Diese Liste ist nicht vollständig. Sie illustriert indes, wie sehr das Geschäft mit den Mikros im traditionellen Spektrum der Software- und Systemhäuser liegt. Sicher gibt es Grenzen. Der Produzent eines in Großserie erstellten Produktes wird den in ihm enthaltenen Mikro nicht völlig aus seiner Kontrolle entlassen können. Sicher gibt es Nuancen. Manche vielerorts schon zur Sünde abgestempelte Technik feiert für eine Übergangszeit fröhliche Urstände wie Cross-Compilierungen und Host-Simulation. Dennoch, eines ist gewiß: Ein erfolgreicher Mikro-Einsatz setzt solide Kenntnisse in moderner Software- und Systemtechnologie sowie ein ausreichendes Projekt-Abwicklungs-Know-how voraus, eben die für Software- und Systemhäuser charakteristischen Erfahrungen.