<![CDATA[
<BODY>
<H1>www.aud24.net : Dr. M. Bauch: "Bedienung und Beobachtung kleinerer Automatisierungssysteme"</H1>
<P> <BR>
[<A href="/">www.aud24.net</A>] [<A href="../index.html">back</A>]
</P>
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=top>
<TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=TOP CLASS=detailBereichRedaktion>Bereich >
Redaktion
> <B><FONT color="#CC3300">Fachbeiträge</FONT></B></TD>
<TD ALIGN=right VALIGN=bottom CLASS=detailDatum>17.04.2001</TD>
</TR>
</TABLE>
</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailFirma ID=topSpace>Software Objects GmbH:</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailTitel>Dr. M. Bauch: "Bedienung und Beobachtung kleinerer Automatisierungssysteme"</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top CLASS=detailSubtitel>Es gibt Alternativen zu reinen Individuallösungen und oft überdimensionierten Standardtools</TD>
<TD VALIGN=top> </TD>
<TD VALIGN=top> </TD>
</TR>
<TR>
<TD VALIGN=top>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>
<TR>
<TD VALIGN=top CLASS=detailContent>Bei der Auswahl der richtigen Software zur Erstellung einer PC-basierten Visualisierungs- und Bedienanwendung gibt es keine allgemeingültigen Kriterien. Gerade bei kleineren Anlagen spielen die Kosten im Verhältnis zur Gesamtinvestition eine große Rolle. Der Blick auf flexible Tools, die moderne Ansätze wie graphisches Programmieren und Komponententechnologie einsetzen, kann hier lohnend sein. <BR><BR>Einleitung<BR><BR>Bei der Automatisierung kleierer Anlagen oder -teile ist oft die Einbindung eines PC in die Anlage erforderlich, um einige Vorgänge zu visualisieren, kritische Daten laufend zu beobachten und in bestimmte Prozessabläufe eingreifen zu können. ‚Kleinere‘ Systeme über einen PC zu bedienen und zu beobachten, lässt sich jedoch nur effizient implementieren, wenn die Engineering- und Laufzeitkosten im Verhältnis zu den Gesamtsystemkosten auf einem niedrigen Niveau gehalten werden können. Denn viele Standardprodukte sind eigentlich für viel mächtigere Aufgaben an- und ausgelegt, und Individuallösungen sind oft nicht kostengünstig zu realisieren. Alternativen sind also gefragt.<BR><BR>Hauptteil<BR><BR>Standardtools<BR>Die Situation kehrt immer wieder: Ein neues PC-Tool wird getestet und anhand des Manuals ausprobobiert. Es eröffnet sich eine Fülle von Möglichkeiten, doch bei deren Vergleich mit den konkreten Anforderungen aus der zu betreibenden Anwendung ergeben sich häufig erhebliche Diskrepanzen: Erstens - nur einen Bruchteil der zur Verfügung stehenden Funktionalität des Tools kann verwendet werden; zweitens - die konkrete Anforderung entspricht nicht dem ‚Standard‘ und die gewünschte Funktionalität kann lediglich von einem auf dem Produkt geschulten Entwickler realisiert werden.<BR><BR>Individuallösungen<BR>Auch hier ist ein Szenario häufig anzutreffen: Die Anforderungen an die Software sind definiert, ein Pflichtenheft ist erstellt und alle Punkte sind ausführlich mit dem Entwickler besprochen. Er macht sich umgehend an die Arbeit und liefert die Software zum vereinbarten Termin. Sie entspricht genau den gestellten Anforderungen an Funktionalität und Design. Die Anwendung läuft nach wenigen Optimierungen problemlos. Das ist sicherlich die Idealsituation - die Realität sieht bei den meisten Unternehmen weniger rosig aus: Ressourcenmangel in der Entwicklungsabteilung, Abstimmungsschwierigkeiten zwischen Auftraggeber und Softwareentwickler, Terminverzögerungen und überzogene Budgets sind kein Einzelfall.<BR><BR>Der Mittelweg <BR>Wie könnte eine Lösung aussehen, welche die Vorteile der Standardprodukte mit denen der Individuallösung kombiniert? Wie kann man die beschriebenen Nachteile verhindern? Um diese Fragen zu beantworten, sind folgende Einflussfaktoren näher zu betrachten: <BR>· Die Handhabung - oder genauer ausgedrückt: Welche Anforderungen stellt das verwendete System an den Ingenieur? <BR>· Die Flexibilität - genauer: Welchen Grad an Flexibilität sollte der Lösungsweg beinhalten? <BR>· Das Kosten-Nutzen-Verhältnis über die gesamte Produktlebensdauer als Bewertungsfaktor für künftige Entscheidungen.<BR><BR>Lösungsansatz<BR>Das am einfachsten einzusetzende Engineeringtool würde folgendermaßen funktionieren: Das Produkt wird auf dem Zielrechner installiert; es erkennt automatisch alle verwendeten Schnittstellen, die Hardware, Bussysteme, Parameter u, s. w.; es weiß natürlich auch, welche Anforderungen Sie haben und generiert hierfür automatisch die Oberflächen, stellt Verbindungen her und implementiert die benötigte Funktionalität. Ihre Aufgabe besteht lediglich darin, das fertige Programm dann per Doppelklick zu starten. <BR><BR>Moderne B&B Tools orientieren sich an der erstgenannten Herausforderung. Da das Programm leider nicht wissen kann, wie Ihre Anforderungen aussehen, und um aber dennoch ein Höchstmaß an Komfort und ‚Einfachheit‘ zu erreichen, wird aus der unendlichen Anzahl von Möglichkeiten eine Menge an Standardanforderungen festgelegt, die von dem Tool dann als vorgefertigte Lösung oder in Form von einzelnen Komponenten angeboten werden. Die Implementierung einer Anwendung auf standardisierter Basis kann von einem Nichtprogrammierer nach einer - kürzeren oder längeren - Einarbeitungszeit durchgeführt werden.<BR>Problematisch wird es bei vielen Tools jedoch, wenn die standardisierten Vorgaben nicht zum Ziel führen und individuelle Lösungen integriert werden müssen. Um an diesem Punkt weiterzukommen, sind detaillierte Kenntnisse der internen Arbeitsweise des Tools notwendig. Zudem sind die Ergänzungen oft nur in hauseigenen Scriptsprachen zu realisieren. Für den Ingenieur ist dies keine zufriedenstellende Lösung.<BR>Ein Konzept, diese Barriere aufzuweichen, stellt zum einen einen Editor zur Verfügung, mit dem Komponenten rein graphisch zu einer ablauffähigen Anwendung zusammengefügt werden. So werden weitereichende Programmierkenntnisse und lange Einarbeitungszeiten vermieden. Zum anderen sind die mitgelieferten Komponenten so dimensioniert, dass Standardanwendungen sehr schnell realisiert werden können, individuelle Lösungen aber genauso einfach zu integrieren sind. Natürlich muß der Anwender hier abwägen, ob er mit vorhandenen Komponenten rein graphisch seine Teilfunktionalität erstellt oder ob es nicht sinnvoller ist, eine neue Komponente ‚herkömmlich‘ zu programmieren oder programmieren zu lassen. Ein praktiakables Programm muss diese Option bieten.<BR><BR>Flexibilität<BR>Ein modernes Engineeringtool für B&B-Anwendungen muß möglichst flexibel sein und zwar in mehrere Richtungen. Dies bedeutet auf der einen Seite, dass bestimmte Technologien, die sich als Standard etabliert haben, unterstützt werden sollten (Stichworte: COM/DCOM; ActiveX; OPC, Officeanwendungen). Dadurch ist sichergestellt, dass auch Komponenten anderer Hersteller integriert und vorhandene Infrastrukturen genutzt werden können. <BR>Flexibilität bedeutet auf der anderen Seite, dass die Einsatzmöglichkeiten nicht eingeschränkt werden dürfen. Die letztgenannte Forderung bedeutet, dass spezifische, individuell benötigte Funktionalität, die noch nicht als Komponente vorliegt und somit herkömmlich beispielsweise mit C/C++ programmiert werden muß, einfach integriert werden kann. Tools wie der Elementbuilder von Software Objects bieten hier eine elegante Alternative. Damit wird das Interface der benötigten Komponenten festgelegt, wiederum ohne dass dafür Programmierkenntnisse nötig sind. Die eigentliche Funktionalität wird dann vom Programmierer in seiner gewohnten Entwicklungsumgebung und Sprache, beispielsweise MS Visual C++, implementiert. Der Vorteil des Konzepts besteht darin, dass der Ingenieur, der die B&B-Anwendung erstellt, definiert, welche Schnittstellen die Komponente hat und welche Funktionalität sie erfüllen soll. Die softwaretechnische Umsetzung der Funktionalität erfolgt dann durch den Programmierer. Die Gefahr, dass Fachanwender und Softwareentwickler aneinander vorbei arbeiten wird so minimiert.<BR><BR>Kosten-Nutzen-Verhältnis<BR>Das Kosten-Nutzen-Verhältnis als Entscheidungskriterium zur Auswahl einer B&B-Software ist denkbar einfach. Je kleiner das Verhältnis, desto günstiger das Tool! Die Problematik besteht nur darin, die Kosten richtig zu ermitteln und den Nutzen richtig zu bewerten. Das ist individuell zu verschieden und die sogar generaliserte Abhandlung dieses Themas würde den Rahmen des Beitrags sicher sprengen. Daher nur einige grundsätzliche Überlegungen:<BR>Als Kosten fallen zunächst die Anschaffungskosten des Tools oder der Entwicklungsumgebung sowie eventuell fällig werden Runtimelizenzgebühren an. Entscheidende Überlegung sollte dabei sein, wieviel Funktionalität eines Systems brauche ich wirklich? Die Engineeringkosten bestehen aus der Einarbeitung in das Tool und der Entwicklung der Anwendung selbst. Hier stellt sich unter anderem die Frage, wieviel Einarbeitungsaufwand sich auch im Hinblick auf zukünftige Aufgaben lohnt. Danach entstehen Kosten durch Fehlerbehebung und Wartung. Welche Hilfen bietet mir das Tool hierbei; kann unter Umständen der Endanwender Anpassungen selbst vornehmen? <BR>Direkter Nutzen entsteht i. d. R. beim Verkauf der fertigen Softwarelösung oder auch beim Erstellen von Produkten mit der neuen Anlage. Ein zusätzlicher Nutzen kann dadurch entstehen, dass das verwendete Tool einfach zu handhaben ist und die Wiederverwendbarkeit von Komponenten optimal unterstützt. Je mehr Projekte mit einem solchen Tool realisiert werden können, desto größer wird der Nutzen. Dieser letzte Aspekt sollte vor allem bei etwas längerfristiger Betrachtung nicht vernachlässigt werden.<BR><BR>Zusammenfassung<BR><BR>Der Trend zur Nutzung des PC zum Bedienen und Beobachten von immer kleineren Systemen wird weitergehen. Für Hersteller und Entwickler wird die Effizienz der verwendeten Software zunehmend wichtig, je kleiner die Gesamtsysteme beziehungsweise die Gesamtinvestitionen sind. Keine der angesprochenen Möglichkeiten zur Realisierung einer B&B-Anwendung, die Standardsysteme, Individuallösungen oder Visual als Mittelweg, stellt eine dominant überlegene Lösung dar. Der Anwender, Ingenieur oder Entwickler muss im konkreten Fall - aber immer auch mit Blick auf zukünftige Aufgaben - entscheiden, welcher Weg der individuelle richtige ist.<BR><BR></TD>
</TR>
<TR>
<TD CLASS=detailQuelle> </TD>
</TR>
</TABLE>
</TD>
<TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=1 HEIGHT=1 ALT=""></TD>
<TD WIDTH=174 VALIGN=top></TD>
</TR>
<TR>
<TD VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=393 HEIGHT=1 ALT=""></TD>
<TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=28 HEIGHT=1 ALT=""></TD>
<TD WIDTH=174 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=174 HEIGHT=1 ALT=""></TD>
</TR>
</TABLE>
<P><I>Diese Seite wurde am 22.09.2006, 13:54 Uhr aktualisiert</I></P>
</BODY>
]]>