-
Die Erfindung betrifft ein Softwareprodukt mit Programmcode, der dazu eingerichtet ist, eine externe Systemgruppe zu betreiben, deren Funktionalität auf mindestens einer Abstraktionsebene durch eine Struktur von Funktionskomplexen beschreibbar ist, die auf definierte Weise zueinander in Beziehung stehen.
-
Unter einer externen Systemgruppe soll hier ein physisches System oder eine Gruppe von physischen Systemen verstanden werden, deren Betrieb den Einsatz eines Computers oder Computersystems erfordert, die jedoch selbst nicht Bestandteil dieses Computers oder Computersystems sind, sondern dazu ausgebildet sind, auf ein physisches Substrat einzuwirken, wie beispielweise bei einem Produktionssystem, und/oder ihren Zustand unter physischen Einwirkungen zu verändern, wie beispielsweise bei einem Messsystem. Der Betrieb der externen Systemgruppe kann beispielsweise eine Steuerung der Systemgruppe, eine Überwachung der Funktionen der Systemgruppe und/oder die Auswertung von Messergebnissen der Systemgruppe umfassen.
-
Die Erfindung befasst sich insbesondere mit einem Softwareprodukt für den Betrieb eines Druckersystems, das einen oder mehrere Drucker sowie andere Geräte umfassen kann, die mit einem Drucker zusammenarbeiten, beispielsweise Scanner, Finisher für eine Endbearbeitung der Druckerzeugnisse, und dergleichen.
-
Eine besondere Problematik ergibt sich daraus, dass die Betriebssoftware für komplexe (und teure) Systeme auf verschiedenen Ebenen auf ihre Korrektheit und Robustheit geprüft werden muss. Dabei ist es aus Sicherheitsgründen oft erwünscht, die Software für einzelne Teilsysteme der externen Systemgruppe isoliert zu testen, damit im Fall eines Softwarefehlers die Gefahr von Schäden an den physischen Systemkomponenten eingegrenzt werden kann. Das bedeutet jedoch, dass, wenn die Software für eine Komponente getestet werden soll, entweder die Software für die anderen Komponenten abgeschaltet werden muss oder aber die Funktionen dieser anderen Komponenten für die Software simuliert werden müssen, wozu dann eine spezifische Simulationssoftware in das Programm eingebunden werden muss. In beiden Fällen ist das Ergebnis, dass die getestete Software nicht identisch ist mit der compilierten Software, mit der die komplette Systemgruppe dann tatsächlich betrieben wird.
-
Oftmals ist es auch erforderlich, den Programmcode in bestimmter Weise zu verändern, damit der Test der Software überhaupt sinnvoll durchgeführt werden kann. Wenn beispielsweise getestet werden soll, wie die Software auf das Auftreten bestimmter physischer Fehler reagiert, so müssen Softwarekomponenten für die Simulation dieser Fehler eingebaut und später wieder entfernt werden. Auch in diesen Fällen besteht das Problem, dass die getestete Software nicht mit der später tatsächlich eingesetzten Software identisch ist. Eine denkbare Lösung besteht darin, dass man die Softwarekomponenten, die speziell zu Testzwecken eingebaut wurden, im fertig compilierten Programm belässt und lediglich durch Eingabe entsprechender Parameter dafür sorgt, dass diese Komponenten während des realen Betriebs abgeschaltet bleiben. Das führt jedoch dazu, dass das Softwareprodukt letztlich eine beträchtliche Menge an „totem“ Code enthalten kann, der den Umfang der Programmdatei vergrößert und den Arbeitsspeicher des Computers unnötig belastet.
-
Aufgabe der Erfindung ist es, ein Softwareprodukt zu schaffen, das es erlaubt, die externe Systemgruppe ohne Veränderung des Softwareprodukts flexibel in unterschiedlichen Betriebsmodi zu betreiben.
-
Diese Aufgabe wird erfindungsgemäß dadurch gelöst, dass der Programmcode durch eine Anzahl geschlossener Funktionen gebildet wird, deren Code in mindestens einer dynamischen Bibliothek abgelegt ist und die über definierte Schnittstellen miteinander verknüpfbar sind und die Struktur der Funktionskomplexe der Systemgruppe abbilden, wobei der Programmcode mindestens eine geschlossene Funktion umfasst, die beim Betrieb der Systemgruppe inaktivierbar ist.
-
Mit dem Begriff „geschlossene Funktion“ ist hier gemeint, dass jede dieser Funktionen in dem Sinne komplett ist, dass nach der Ausführung der betreffenden Funktion sichergestellt ist, dass entweder die Anwendung mit dem Aufruf einer weiteren Funktion oder eines Hauptprogramms fortgesetzt wird oder die Anwendung planmäßig beendet wird. Die Schnittstellen, die eine Verknüpfung der Funktionen ermöglichen, sollen in dem Sinne definiert sein, dass eine Funktion wahlweise mit einer von mehreren anderen Funktionen verknüpft werden kann, ohne dass die Schnittstelle dazu verändert werden muss.
-
Dadurch, dass der Code der geschlossenen Funktionen in dynamischen Bibliotheken abgelegt ist, wird eine Einbindung dieser Funktionen zur Laufzeit ermöglicht, so dass verschiedene Funktionen je nach Bedarf ein- und ausgeschaltet und gegeneinander ausgetauscht werden können, ohne dass ein erneutes Compilieren der kompletten Anwendung erforderlich ist. Dadurch wird das Testen und die Entwicklung der Software sowie die Anpassung des Software an unterschiedliche Systemkonfigurationen wesentlich erleichtert. Da jeweils nur diejenigen Funktionen geladen werden, die aktuell benötigt werden, wird toter Code in der Anwendung vermieden.
-
Insbesondere ermöglicht es die Erfindung, Funktionen, die nur zu Testzwecken benötigt werden, mit Funktionen zu kombinieren, die für den Ernstfall getestet werden sollen. Wenn die getestete Software dann in der Praxis eingesetzt wird, so werden die Funktionen, die nur zu Testzwecken nötig waren, nicht geladen, und die Funktionen, die für den praktischen Einsatz benötigt werden, werden nicht neu kompiliert, so dass die Software, die in der Praxis wirklich zum Einsatz kommt, mit dem getesteten Compilat identisch ist.
-
Es wird angemerkt, dass die Erfindung hierarchisch angewendet werden kann, im Fall eines Druckersystems zum Beispiel auf einer niedrigen Ebene, auf der eine direkte Kommunikation mit einem Finisher stattfindet, sowie auf einer höheren Ebene, auf der Finisher-Funktionen wie ein generischer Schneidvorgang definiert sind.
-
Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
-
Verschiedene Konfigurationen der externen Systemgruppe können sich beispielsweise dadurch unterscheiden, dass bestimmte Komponenten vorhanden sind oder nicht vorhanden sind, oder dass eine Komponente durch eine andere Komponente mit ähnlichen Funktionen ersetzt ist. Im Fall eines Druckersystems können unterschiedliche Konfigurationen beispielsweise darin bestehen, dass ein und derselbe Finisher mit einem von mehreren Druckern zusammenarbeitet, die unterschiedliche Funktionen und Eigenschaften haben, oder dass ein Drucker die gedruckten Medien entweder an einen nachgeschalteten Finisher übergibt oder sie unmittelbar, ohne Endbearbeitung, auswirft.
-
Die Erfindung ermöglicht es, die Software flexibel an unterschiedliche Konfigurationen anzupassen, ohne dass bei einer Änderung der Konfiguration die Software oder Teile davon neu compiliert werden müssen und ohne dass an den getesteten Softwarefunktionen, die nach der Änderung der Konfiguration zu Einsatz kommen, irgendetwas verändert werden muss.
-
In einer vorteilhaften Ausführungsform enthält der Programmcode einen konfigurationsunabhängigen Teil, der für diejenigen Komponenten und Funktionalitäten des externen Systems zuständig ist, die in allen Konfigurationen gleich sind. Auch dieser konfigurationsunabhängige Teil kann ein oder mehrere geschlossene Funktionen enthalten, die flexibel mit den Funktionen kombinierbar sind, die in der einen oder mehreren dynamischen Bibliotheken abgelegt sind und den konfigurationsabhängigen Teil bilden.
-
Der konfigurationsabhängige Teil kann auch Funktionen enthalten, die das Verhalten bestimmter physischer Komponenten des externen Systems simulieren. In dem Fall ist es möglich, die Software für eine Komponente zu testen und dabei das Verhalten einer anderen Komponente durch die Simulation zu ersetzen, so dass diese letztere Komponente nicht physisch anwesend zu sein braucht und folglich bei dem Test auch nicht beschädigt werden kann.
-
Solche Simulationsfunktionen bieten auch Vorteile bei der Programmentwicklung oder beim Debugging, da sie es ermöglichen, vor allem in den frühen Entwicklungsphasen teure Hardware zu ersetzen.
-
Eine weitere attraktive Möglichkeit besteht darin, in den dynamischen Bibliotheken spezielle Funktionen abzulegen, mit denen speziell zu Testzwecken definierte Eingangsdaten in die Software eingebracht werden, so dass die Reaktion der Software auf diese Eingangsdaten getestet werden kann. Ebenso können Softwarefunktionen vorgesehen sein, die es ermöglichen, zumindest während eines Testbetriebs der Systemgruppe die relevanten Prozessabläufe zu aufzuzeichnen. Bei der Such nach Fehlern und der Beseitigung von Fehlern kann dann der aufgezeichnete Prozessablauf so oft wie nötig erneut durchgespielt werden. Beim wiederholten Durchspielen des Prozesses können dann bestimmte Parameter oder Aktionen gezielt verändert werden um zu testen, wie das System bei ansonsten gleichen Bedingungen auf die Veränderung reagiert. Dadurch kann das Debugging erheblich beschleunigt werden. Sofern außerdem die Hardware durch Simulationen ersetzt wird, können auch die Robustheitsgrenzen der Software ausgetestet werden.
-
Im Folgenden wird ein Ausführungsbeispiel anhand der Zeichnung näher erläutert.
-
Es zeigen:
- 1 ein Blockdiagramn eines Druckersystems einschließlich eines elektronischen Datenverarbeitungssystems, in das ein erfindungsgemäßes Softwareprodukt zur Steuerung des Druckersystems geladen ist; und
- 2 bis 7 Blockdiagramme analog zu 1, für unterschiedliche Konfigurationen des Druckersystems.
-
Als Beispiel für eine externe Systemgruppe 1, die durch ein erfindungsgemäßes Softwareprodukt gesteuert werden soll, ist in 1 ein Druckersystem gezeigt, das zwei Drucker D1, D2 und einen Finisher F (z.B. eine Falt- oder Bindevorrichtung) umfasst, die in unterschiedlicher Weise miteinander kombiniert werden können. Beispielsweise kann jeder der beiden Drucker D1 und D2 als Einzelsystem ohne Finisher betrieben werden, so dass keine Endbearbeitung der Druckerzeugnisse stattfindet, oder der Finisher F kann wahlweise mit einem der beiden Drucker D1, D2 gekoppelt werden.
-
Zur Steuerung des Druckersystems ist ein elektronisches Datenverarbeitungssystem 10 vorgesehen, beispielsweise ein Computer mit einem Terminal, das eine Benutzerschnittstelle zur Steuerung und Bedienung des Druckersystems bildet. In den Computer ist ein kompiliertes Softwareprodukt 12 geladen, das die gesamte Software für den Betrieb des Druckersystems in allen denkbaren Konfigurationen umfasst.
-
Im gezeigten Beispiel ist der Programmcode des Softwareprodukts 12 unterteilt in einen konfigurationsunabhängigen Teil KU und einen konfigurationsabhängigen Teil KA. Der konfigurationsunabhängige Teil KU umfasst alle Teilprogramme, Funktionen und Routinen, die für alle vorgesehenen Konfigurationen des Druckersystems gleich sind, so dass bei einer Änderung der Konfiguration keine Änderung des Programmcodes erforderlich ist. Der Programmcode des konfigurationsunabhängigen Teils kann beispielsweise ein Hauptprogramm umfassen, in das mehrere Funktionen für spezifische Steuerungsaufgaben eingebettet sind. Die Funktionen können auch ineinander verschachtelt sein und eine Hierarchie von Funktionen und Unterfunktionen bilden. Wenn eine einzelne Funktion ausgeführt worden ist, wird die Steuerung an das Hauptprogramm bzw. an die aufrufende Funktion der nächsthöheren Hierarchiestufe zurückgegeben. Die Information über die beim Aufruf einer Funktion geltenden Parameter und Eingangsvariablen sowie die Information über die nach Ausführung einer Funktion zurückzugebenden Parameter und Ausgangsdaten werden in bekannter Weise über standardisierte Schnittstellen zwischen den verschiedenen Programmteilen ausgetauscht. Wahlweise können einzelne Funktionen des konfigurationsunabhängigen Teils auch in einer oder mehreren dynamischen Bibliotheken abgelegt sein und zur Laufzeit in das Programm eingebunden werden.
-
Der konfigurationsabhängige Teil KA umfasst im gezeigten Beispiel sechs dynamische Bibliotheken B1 - B6, in denen jeweils die für den Betrieb des Druckersystems nötige Software abgelegt ist, die spezifisch an eine bestimmte Konfiguration des Druckersystems angepasst ist. Zur Vereinfachung der Darstellung ist in 1 für jede dynamische Bibliothek nur eine einzige Funktion und nur eine einzige hierarchische Ebene gezeigt. So enthält die Bibliothek B 1 eine Funktion FD1, die Bibliothek B2 eine Funktion FD2, die Bibliothek B3 eine Funktion FF, die Bibliothek B4 eine Funktion SD1, die Bibliothek B5 eine Funktion SD2 und die Bibliothek B6 eine Funktion SF. Jede Funktion ist über eine Schnittstelle SD oder SF mit dem Programm im konfigurationsunabhängigen Teil und/oder mit anderen Funktionen in derselben dynamischen Bibliothek des konfigurationsabhängigen Teils KA verknüpft und wird zur Laufzeit in das Programm eingebunden. In der Praxis kann jede der dynamischen Bibliotheken B1 - B6 eine Vielzahl von Funktionen umfassen, die auch hierarchisch organisiert sein können. Dies bedeutet auch, dass eine Bibliothek wieder von einer anderen Bibliothek abhängig sein kann, wie als Beispiel in 2 gezeigt ist. Dort kann die Bibliothek B1 über eine Schnittstelle S7 eine Funktion F7 aus einer Bibliothek B7 aufrufen.
-
Im dem in 1 gezeigten Beispiel enthält die Funktion FD1 in der Bibliothek B 1 die gesamte Funktionalität, die für den Betrieb der Hardware des Druckers D1 als Einzelsystem - ohne Finisher - benötigt wird. Während des Betriebs des Druckers D1 empfängt die Funktion FD1 Daten über den aktuellen Zustand des Druckers und übermittelt Befehle an die einzelnen Komponenten des Druckers. Diese Befehle werden im Drucker D1 ausgeführt und führen zu einer physischen Änderung des Zustands des Druckers, die dann wieder an die Funktion FD1 zurückgemeldet wird.
-
Entsprechend umfasst die Funktion FD2 die gesamte Funktionalität, die für den Betrieb des Druckers D2 als Einzelsystem benötigt wird. Da die Drucker D1 und D2 gegeneinander austauschbar sind, erfolgt die Verknüpfung der Funktionen FD1 und FD2 mit den übrigen Programmteilen über identisch ausgebildete Schnittstellen SD.
-
Die Funktion FF in der Bibliothek B3 umfasst die gesamte Funktionalität, die für den Betrieb des Finishers F benötigt wird, entweder als Einzelsystem oder in Kombination mit einem der Drucker D1 und D2. Dabei wird in diesem Beispiel davon ausgegangen, dass es für die Arbeitsweise des Finishers F keine Rolle spielt, aus welchem der beiden Drucker D1 und D2 die zu behandelnden Druckerzeugnisse stammen. Die Verknüpfung der Funktion FF mit den übrigen Programmteilen erfolgt über eine für den Finisher spezifische Schnittstelle SF. Auf diese Weise können, wenn der Finisher F beispielsweise an den Drucker D1 angekoppelt ist und gemeinsam mit diesem betrieben wird, auch die Funktionen FD1 und FF miteinander koordiniert werden.
-
Die in den dynamischen Bibliotheken B4, B5 und B6 abgelegten Funktionen SD1, SD2 und SF sind Simulationsfunktionen, mit denen die Arbeitsweise des Druckers D1 bzw. des Druckers D2 oder des Finishers F simuliert werden können. Das erlaubt es, die Software für bestimmte Komponenten des Druckersystems zu testen, ohne dass die mit diesen Komponenten zusammenwirkenden anderen Systemkomponenten wirklich aktiv sein müssen oder überhaupt physisch vorhanden sein müssen. Die Funktion der inaktiven oder nicht vorhandenen Komponenten innerhalb des Gesamtsystems wird dann mit Hilfe der Simulationsfunktionen simuliert, so dass die Software für die vorhandenen Komponenten unter realitätsnahen Bedingungen getestet werden kann.
-
Inaktivierbar bedeutet, dass die Funktion nicht geladen wird oder dass die Funktion durch eine andere Funktion ersetzt wird. Beispielsweise ersetzen die Simulationsfunktionen SD1, SD2 und SF die Druckerfunktionen FD1 und FD2 bzw. die Finisherfunktion, aber die Druckerfunktionen FD1 und FD2 können auch einander ersetzen.
-
3 zeigt ein Beispiel für eine spezifische Konfiguration, in der der Drucker D1 zusammen mit dem Finisher F betrieben wird. Der Drucker D2 ist in dieser Konfiguration nicht vorhanden oder abgeschaltet. Bei Beginn des Druckbetriebs wird mit dem Start des Softwareprodukts 12 die fertig compilierte Funktion FD1 in die konfigurationsunabhängige Software eingebunden, und der Betrieb des Druckers D1 wird durch die Funktion FD1 gesteuert. Sobald die ersten Druckerzeugnisse fertiggestellt sind und an den Finisher F übergeben werden, wird die Schnittstelle SF auch die Funktion FF zur Laufzeit eingebunden, so dass auch der Finisher F so gesteuert wird, wie es der Produktionsablauf erfordert. Die dynamischen Bibliotheken B2 und B4 bis B6 werden in dieser Konfiguration nicht benötigt und die entsprechende Software wird deshalb auch nicht in den Arbeitsspeicher des Computers geladen und auch nicht installiert.
-
4 zeigt ein Beispiel für eine Konfiguration, in der der Drucker D2 zusammen mit dem Finisher F betrieben wird. In diesem Fall werden nur die Funktionen FD2 und FF zur Laufzeit eingebunden, während die übrigen dynamischen Bibliotheken unbenutzt bleiben.
-
Für die beiden in 3 und 4 gezeigten Konfigurationen kann somit unverändert dieselbe Software verwendet werden, so dass keine erneute Compilation erforderlich ist. Beim Programmstart müssen lediglich die Parameter eingegeben werden, die angeben, in welcher Konfiguration sich das System befindet. Diese Eingabe kann gegebenenfalls auch automatisch erfolgen, wenn die Drucker und der Finisher mit Sensoren ausgestattet sind, die angeben, ob ein anderes Gerät angeschlossen ist und wenn ja welches.
-
5 zeigt als weiteres Beispiel eine Konfiguration, in welcher der Drucker D2 als Einzelsystem betrieben wird. In dem Fall braucht nur die Funktion FD2 eingebunden zu werden.
-
6 illustriert den Fall, dass die Funktion FF die für den Betrieb des Finishers F zuständig ist, unter realen Bedingungen getestet werden soll. Zugleich soll auch die Software getestet werden, die für das Zusammenwirken des Finishers F mit dem Drucker D2 zuständig ist. In der hier betrachteten Situation ist jedoch der Drucker D2 (noch) gar nicht physisch vorhanden, oder er ist zumindest nicht in Betrieb, damit im Fall eines Softwarefehlers eine Gefährdung der Hardware des Druckers vermieden wird. Die Betriebsweise des Druckers D2 wird deshalb mit Hilfe der Funktion SD2 simuliert. Unter diesen Umständen werden zur Laufzeit die zu testende Funktion FF und die Funktion SD2 zur Simulation des Druckers D2 eingebunden. Die Verknüpfung der Simulationsfunktion mit den übrigen Programmteilen erfolgt dabei über die gleiche Schnittstelle SD wie bei den Funktionen FD1 und FD2. Die Funktion SD2 simuliert die Funktionen des Druckers D2 und ersetzt die Funktion FD2.
-
Je nachdem, welche speziellen Funktionalitäten des Finishers F und der zugehörigen Software getestet werden sollen, wird der Finisher entweder im Leerlauf betrieben, ohne dass tatsächlich Druckerzeugnisse bearbeitet werden, oder Test-Druckerzeugnisse werden manuell zugeführt.
-
7 illustriert schließlich den Fall, dass in einem frühen Stadium der Softwareentwicklung die Software getestet werden soll, ohne dass irgendeine Verbindung zu physischen Komponenten des Druckersystems besteht. Getestet werden soll auch hier wieder die Konfiguration, in der der Drucker D2 mit dem Finisher F kombiniert ist. In diesem Fall werden auch die Funktionen des Finishers lediglich mit Hilfe der Funktion SF in der Bibliothek B6 simuliert. Bei einem Testlauf des Programms wird somit über die Schnittstelle SD die Funktion für die Simulation der Arbeitsweise des Druckers geladen, sowie über die Schnittstelle SF die Funktion SF für Simulation des Finishers.
-
Nach erfolgreichem Test der Software kann dann schrittweise zu den Konfigurationen gemäß 6, 5 und schließlich 4 übergegangen werden, so dass die Software unter zunehmend realistischeren Bedingungen getestet und schließlich im Realbetrieb eingesetzt werden kann. Bei dem gesamten Entwicklungs- und Testprogramm ist, sofern keine Softwarefehler zu korrigieren sind, keine erneute Compilation des Softwareprodukts erforderlich.
-
Das hier betrachtete Druckersystem als externes System 1 soll die Erfindung lediglich anhand eines einfachen Beispiels illustrieren. In der Praxis kann das externe System eine wesentlich größere Anzahl von Komponenten umfassen. Die Änderungen der Konfiguration müssen nicht darauf beschränkt sein, dass die physische Anordnung und Verbindung der Systemkomponenten verändert wird, sondern kann beispielsweise auch darin bestehen, dass die Geräteeinstellungen für eine oder mehrere Komponenten geändert werden. In dem Fall enthält der konfigurationsabhängige Teil der Software mehrere Funktionen oder Funktionsgruppen für dasselbe Gerät, und je nach Konfiguration wird eine dieser Funktionsgruppen eingebunden.
