Autoren: Dipl.Ing. Andreas Foltinek, IMACS; Michael Zenk, Wolf Heiztechnik Wolf Heiztechnik ist als innovativer Systemlieferant von Heizungs- und Klimasystemen bekannt. Bei einer jährlichen Stückzahl von ca. 200.000 Steuerungseinheiten verschiedenster Größe bestand bereits von Anfang an die Notwendigkeit, Embedded Systeme anstelle von SPSen einzusetzen. Diese werden von externen, branchenspezialisierten Lieferanten vollständig entwickelt und gepflegt. Auch wenn Heizsystemsteuerungen typische Consumer-Anwendung sind, so ist die sich ergebende \“embedded Problematik\“ durchaus vergleichbar mit der anderer Einsatzgebiete, z.B. dem klassischen Maschinen- und Anlagenbau. Folgende Umstände stellten sich immer wieder als unbefriedigend dar: – das System Know How liegt nicht im eigenen Hause – es bestehen Abhängigkeit vom Lieferanten in vielerlei Hinsicht – vom Lieferanten angegebenen Aufwände können nicht immer nachvollzogen werden – die Prioritäten des Lieferanten decken sich nicht immer mit den eigenen – eine agile Vorgehensweise ist faktisch nicht möglich, da die Reaktionszeit i.d.R. 1 Tag bis 1 Woche betragen kann – auch bei trivialen Änderungen ergibt sich oft ein extremer Zeitaufwand und Verzögerungen – nötige Innovationen werden indirekt gehemmt, da jede Änderung stets externe Kosten verursachen. Wunschsystem Bei der der Suche nach Alternativen stand der Fokus zunächst auf einem Werkzeug zur Applikationsentwicklung mit folgenden Schwerpunkten: – Applikations-Entwicklung vollständig im eigenen Hause durchführbar – kalkulierbare Einarbeitungszeit – Modellbasierte, objektorientierte Arbeitsweise – vollständige Abstraktion der Hardware zur freien Hardwarewahl – Modellierung möglichst aller Projektaspekte in einer Modelldatenbasis, d.h. auch Metadaten (Werte-/Auswahlbereich, physikalische Einheit, Genauigkeit, Speicherart, mehrsprachige Bezeichnungs- und Informationstexte usw.) sowie Bedienoberflächen, verteilte Systeme/Kommunikation, Testinformationen etc. – Grafische Programmierung, d.h. weitgehend ohne C-Wissen (jedoch sollte C/C++-Codierung oder auch IEC61131-ST/FUP prinzipiell möglich sein) – vollständige und einfache Wiederverwendbarkeit (auch z.B. der Bedienoberflächen) – automatische Dokumentationsgenerierung – Design-Level-Debugging – Unterstützung von Standards wie UML und IEC 61508-3 – effektive Konfigurations- und Variantenverwaltung. Finale Zielsetzung war eine realitätsgetreue Simulation, durch die die gesamte Entwicklung und Tests der Applikation vollständig auf einem PC durchgeführt werden können (also ohne Ziel-Hardware). Diese sollte ebenfalls zu Review-, Demo- und Verifikationszwecke einsetzbar sein. Unabhängig davon sollte die Hardware-Entwicklung erfolgen und mit einer zum Applikationswerkzeug passenden Middleware (API) ausgestattet werden, was den Einsatz einer Hardware in verschiedensten Projekten sicherte. Diese sollte initial vom Systemlieferanten durchgeführt und dann im Hause weiter gepflegt werden. Die Systemlieferanten sollten ferner einen schnellen und kompetenten Support bieten, Tool-Erweiterungen kurzfristig integrieren können sowie eine mehrjährige praktische Projekterfahrung, Hardwarekompetenz und belastbare Kundenreferenzen besitzen. Werkzeugsuche Im Rahmen des Auswahlverfahrens wurden zunächst die klassischen Soft-SPSen und UML-Tools evaluiert. Es stellte sich jedoch bereits nach den Produktpräsentationen heraus, das die gesteckten Ziele in vieler Hinsicht nicht erfüllt werden konnten. UML-Tools boten zwar eine vollständige Abdeckung bezüglich der Anforderungs- , Design- und Strukturmodellierung jedoch war die eigentliche Implementierung nur in C/C++ möglich und es existierte keine, brauchbare, im Modell integrierte Virtualisierung (d.h. Daten werden unabhängig Ihres Typs, Verwendung, Speicherorts etc. gleich angesprochen). Soft-SPSen dagegen boten, obwohl bereits teilweise objektorientiert, mit der IEC 61131 keine Anforderungs- und Strukturmodellierung sowie keine aus der UML bekannten grafischen Programmiermöglichkeiten. Zudem wäre eine spezielles, royality-pflichtiges Laufzeitsystem nötig gewesen, das zudem für den gewünschten Zielprozessor (PIC24x) nicht verfügbar war. Modellabdeckung Ferner bot kein System die gewünschte Modellabdeckung. Metadaten (wie oben beschrieben) sowie grafische Bedienoberflächen (Target), Visualisierungsoberflächen (PC), Simulationsattribute, Testdaten etc. konnten nicht direkt im Modell eingegeben werden, sondern müssen parallel in anderen Datenquellen oder als Codierung abgelegt werden. Damit sind diese jedoch für eine automatisierte Mehrfachnutzung durch den Design-Compiler verloren, z.B. zur Generierung von: – Offline-PC-Simulation (realitätsgetreuer Test der gesamten Applikation einschl. verteilter Kommunikation auf einem PC) – Online-PC-Visualisierung – SW-Dokumentation – Design-Level-Debugging – automatische Testläufe – Parametrier-Tools – Datenlogger – externe Verwendung Auch ist eine schnelle und einfache Wiederverwendung von Applikationsteilen nicht möglich, da die Informationen einer logischen technischen SW-Einheit auf mehrere Informationsquellen verteilt sind. Die Folge wären ein manuelles Zusammenkopieren mit erheblichen Redundanzen sowie den damit verbundenen Fehlerpotential (s. Abb. 2). Fündig Der deutsche Systemlieferant und Toolhersteller Imacs konnte mit radCase hingegen eine passende Lösung bieten, die alle Anforderungen abdeckt. Mit dem UML basierende Tool können alle, auch bisher ungewohnte Applikationsinformationen vollständig im UML-Design abgelegt werden. Dazu besitzt radCASE zahlreiche pragmatische Spracherweiterungen darunter auch die Integration UML-fremder, jedoch bewährter Methoden. Diese einmalige Datenbasis erlaubt es dem System neben dem Funktions-Code noch hilfreiche Zusatztools, Dokumentationen etc. zu generieren. radCase besteht aus einer grafischen IDE (Design-Editior) und einem Design Compiler der u.a. ANSI C-Code oder C++ generiert. Dieser kann auf einem beliebigen Zielsystem ab 1kB ROM ablaufen. Ferner bot Imacs mit seinem Systemkonzept ecoSolut (embedded control Solutions) ebenfalls die passenden Hardware- und Middlewarekompetenz (s. Abb.3). Projektanforderung Als Pilotprojekt, zum Test und zur Integration des gewählten UML Tools, wurden zwei Steuerungen von Lüftungsgeräten und ein dazugehöriges Bedienteil entwickelt. Dabei handelte es sich um eine überaus anspruchsvolle Aufgabe. Neben sehr umfangreichen Funktionen der Steuerung, können mehrere Knoten über ein Bussystem kommunizieren und interagieren. Das Bedienteil wurde ebenfalls über das Bussystem angebunden. Zusätzlich dazu mussten die Lüftersteuerungen in ein bereits bestehendes Bussystem integriert werden. Aufgrund der beengten Platzverhältnisse und der hohen Anforderungen an Funktionalität wurden alle drei Leiterplatten kundenspezifisch entwickelt. Projektumsetzung Unmittelbar nach Projektstart wurde mit dem Hardware-Design und der Schaltungsentwicklung begonnen. Unabhängig davon konnte durch die klare Hardware-Abstraktion parallel dazu ebenfalls der Entwurf, Implementierung und sogar Test der Applikationssoftware erfolgen. Hierzu wurde im ersten Schritt der komplette Projektumfang in einzeln umzusetzende Arbeitspakete aufgeteilt. Dabei wurde beachtet, dass die Softwarebausteine, sogenannte Module, eigenständig lauffähig und somit für weitere Projekte jederzeit wiederverwendbar sind. Innerhalb eines Modules, vergleichbar mit Funktionsbausteinen einer SPS, ist die Realisierung einer kompletten Teilaufgabe des Projektes möglich. So werden die relevanten Prozesswerte, Parameter, entsprechende Funktionalitäten aber auch die Bedienoberfläche sowie die komplette Dokumentation des Modules modelliert (s. Abb. 1). Anschließend konnte die Modulstruktur erarbeitet werden. Damit einhergehend wurde auch der Informationsaustausch zwischen den Modulen festgelegt. Modulstruktur und Informationsaustausch stellen einen wichtigen Teil der Applikationsentwicklung dar. Hierzu wurde von Imacs ein Konzeptvorschlag erarbeitet, diskutiert und nach verschiedenen Modifikation umgesetzt. Parallel dazu konnte mit radCase die komplette grafische Oberfläche des Bedienteiles intuitiv erstellt werden. Test und Inbetriebnahme Die erstellte Software wurde im ersten Schritt komplett ohne vorhandene Hardware getestet. Sämtliche Funktionstest konnten unmittelbar an einem PC mit Hilfe einer automatisch aus radCASE generierten Simulation überprüft werden (s. Abb. 4). Dabei wurde die zu testende Software mit einem PC Compiler anstelle des Embedded Compilers übersetzt. In der erzeugten Simulation können auf einer komfortablen Oberfläche die aktuellen Zustände der Prozesswerte, der Parameter und sogar die Zustände der integrierten Prozesse direkt dargestellt werden. Zusätzlich dazu ist die parallele Simulation aller beteiligten Knoten des Systems möglich. Die jeweiligen Busprotokolle werden wie im tatsächlichen Zielsystem generiert, und als Textdatei zur Analyse auf dem simulierenden PC geloggt. Die erzeugte Simulation kann auch unabhängig von der Entwicklungsumgebung gestartet werden. So wurden zum Beispiel anhand der Simulationsumgebung die ersten Produktpräsentationen durchgeführt. Danach kann in Schulungen oder Außendienstpräsentationen die Simulationsumgebung weiterhin benutzt werden. Nach Abschluss der Softwaretest am PC waren die ersten Musterleiterplatten verfügbar. Die Middelware war von Imacs bereits aufgesetzt und mit simplen Testapplikationen geprüft. Nach Abschluss der \“trockenen\“ Modultests auf der PC Simulation wurde der Code für die Zielplattform erzeugt und auf die Leiterplatten programmiert. Zum Debuggen des Systems stellt radCase auch hier dem Entwickler ein Werkzeug zur Verfügung. Die vorher erstellte Simulation kann hier zusätzlich als Visualisierung der Hardware eingesetzt werden. Damit können, wie aus der Simulation bekannt, die Zustände der Prozesswerte, Parameter und der Funktionen des Module ausgelesen werden. Dies geschieht über eine serielle bzw. USB-Schnittstelle und ermöglicht ein komfortables Debugging auf der Zielplattform. Damit können auch in der Simulation nicht entdeckte Fehler rasch lokalisiert und abgestellt werden. Fazit
Imacs GmbH
