|
ellan:Stacks
Struktur und Bestandteile der Firmware in Elink-Hardware
Elink Firmware wird seit 1981 entwickelt. Mehr als ein Viertel Jahrhundert an Erfahrung und Know How spiegelt sich in diesen Entwicklungen wieder. Firmware nennt man übrigens Software, die speziell für Mikrocomputersysteme entwickelt wird und nicht für PCs. Firmware ist vielfach komplexer als PC-Software, weil sie nicht auf die vorhandenen Ressourcen eines „großen“ PC-Betriebssystems zurückgreifen kann. Außerdem muss Firmware ihre Aufgaben mit deutlich kleinerer und leistungsschwächerer Hardware realisieren.
Zu Beginn wurden Programme für Geräte entwickelt, die verschiedene Kommunikationsprotokolle miteinander verbinden mussten. Hierbei ging es noch um analoge Modems und serielle Schnittstellen. Danach wurden komplette Modems programmiert und damit nicht nur das jeweilige serielle Protokoll zum Host, sondern auch alles, was sich auf der Telefonleitung abspielte: Datensicherungsprotokolle, Paketierungsverfahren und Datenkompressionsalgorithmen.
Mit der Einführung von ISDN wurde das bestehende Know How auf die neue digitale Plattform portiert. Obwohl die Grundzüge ähnlich sind, verlangt ISDN hier zusätzliche Leistungen. Einen Signalisierungskanal (D-Kanal) hat es bei Modems nicht gegeben und auch die Kommunikationsprotokolle waren neu und erweitert. Mit der ISDN-Technologie wurde bei Elink auch erstmals die Sprachkommunikation integriert. Die digitalen Daten enthielten nun auch Audioinformationen, die transportiert und wiedergegeben werden mussten.
Kurz darauf wandelte sich die Schnittstellenlandschaft zum PC. Die serielle Schnittstelle (V.24 / RS232) wurde abgelöst durch USB und die Netzwerktechnik erhielt immer höhere Akzeptanz. Das war der Moment des Umstiegs auf die neuen Technologien, namentlich dem Ethernet und TCP/IP als zukunftsträchtigem Medium.
Neben der Datenkommunikation hatte sich inzwischen die Sprache als wichtiges zweites Standbein etabliert und so war von Anfang an VoIP im Zentrum unseres Fokusses. Ab 1999 ist VoIP und Netzwerktechnologie Thema unserer Arbeit (zu 95%).
- Struktur (was sind stacks?)
Eine Firmware ist ein Programm, das sich wie jede Software aus mehreren Teilen zusammensetzt. Eine sogenannte top-down-Programmierung ist nur in extrem kleinen Projekten möglich, völlig indiskutabel in Geräten, wie wir sie entwickeln. Firmware ist ein Oberbegriff. Firmware, Stacks, Module, Software......alles sind Programme, die allenfalls verschiedenen Zwecken dienen. Im Folgenden soll versucht werden, das auf einfache Weise zu erläutern.
Programme werden in einer Programmiersprache geschrieben, die dem jeweiligen Zweck am ehesten dient. Auf PCs werden so genannte Hochsprachen verwendet, die leicht zu erlernen sind (Basic, Pascal, C++, C#) aber viel Rechenleistung verbrauchen. Außerdem sind sie auf die PC-Umgebung spezialisiert und machen reichlich Gebrauch von PC-Ressourcen.
Firmware wird in Sprachen verfasst, die näher an der Hardware sind. Das bedeutet, dass diese Befehle besonders gut in so genannte Maschinenbefehle übersetzt werden können, die der Prozessor direkt ausführen kann. Für Firmware verwendete Sprachen sind typischerweise Ansi-C und Assembler.
Ansi-C ist auch (noch) eine Hochsprache, die sich relativ gut lesen und schreiben lässt, sich aber auf Befehle beschränkt, die leicht zu übersetzen sind. Die Übersetzung übernimmt ein Compiler, dazu später. Assembler ist die native Sprache, die der Prozessor selbst versteht, aber mit mnemonischen Befehlen arbeitet. Die Befehle haben also lesbare Namen wie jump, call, load, set und rotate, werden aber 1:1 in Maschinenbefehle übersetzt. Diese Sprache ist für jeden Prozessortyp anders und schwer zu beherrschen, weil man mit nur wenigen Direktiven die Aufgaben formulieren muss.
Die Übersetzung von Ansi-C in Assembler übernimmt ein so genannter Compiler. Die Übersetzung des Assembler-Codes übernimmt ein Programm, das man selbst Assembler nennt. Viele Dinge, die besonders schnell ablaufen müssen, kann man nur sinnvoll in Assembler schreiben. Codeteile verschiedener Module, die eventuell auch in verschiedenen Sprachen geschrieben sind, werden durch einen Linker zur endgültigen Firmware zusammengefügt. Compiler, Assembler und Linker sind Tools, die auf einem PC laufen.
Der Programmierer schreibt also seine Programme auf einem PC als normalen Text in einer der Programmiersprachen. Diesen Text nennt man Sourcecode, weil er die Quelle all dessen ist, was daraus entsteht. Nach dem Compilieren und Assemblieren entsteht daraus Code, der direkt durch das Zielsystem ausgeführt werden kann. Das ist ein ausführbares Programm, nicht mehr sinnvoll durch Menschen lesbar und man nennt diesen Code Objectcode. Der Objectcode wird ins Zielsystem geladen und läuft dort ab.
Der Objectcode ist das wichtige Ergebnis der Programmierung. Er entspricht dem, was man auch auf allen CDs mit gekaufter Software findet, was man installiert und zur Ausführung startet. Der Sourcecode wird nie mitgeliefert (Ausnahme: Open Source), er wird für die Ausführung der Programme auch nicht benötigt.
Hochkomplexe Systeme wie die Elink-Hardware, enthalten sehr vielschichtige Firmware. Die Hardware enthält neben dem Prozessor eine Reihe von wichtigen Schnittstellen, die bedient werden müssen. Die Firmware muss also genau wissen, welche Schnittstellen zu welchem Zweck auf welche Weise an das System angebunden sind. Die gesamte Peripherie, also alles was an diesen Schnittstellen angeschlossen ist, muss von der Firmware verwaltet, abgefragt oder gesteuert werden. Das ist zeit- oder ereignisgesteuert und diese gesamte Verwaltung ist die wichtigste grundlegende Aufgabe der Firmware. Diesen Teil nennt man deswegen Betriebssystem.
Betriebssysteme kennt man auch von den PCs. Dort sind die Aufgaben weitaus vielschichtiger und umfangreicher, weil der PC weniger spezialisiert und deshalb universeller sein muss. Dafür muss das Betriebssystem einer Elink-Hardware deutlich schneller sein und mit möglichst geringer Verzögerung auf Ereignisse reagieren. Außerdem ist es wichtig, dass nach dem Einschalten das System möglichst schnell betriebsbereit sein muss. Man spricht deshalb in diesen Fällen von einem RTOS (real time operating system), in unserem Fall ist es das ellan:RTOS.
Das ellan:RTOS wird seit 1999 gezielt für Audioanwendungen, Telefonie und Steuerungsprozesse entwickelt und kann in diesen Umgebungen seine Stärken ausspielen. Das RTOS ist das wichtigste (wenn auch nicht das komplexeste) Modul der Firmware. Vor dem RTOS befindet sich noch der Bootloader, vergleichbar mit dem BIOS eines PCs, der das RTOS nach einem Selbsttest startet und Funktionen zur Verfügung stellt, die auch ohne Betriebssystem schon benötigt werden (z.B. für Updates).
Aufbauend auf dem RTOS stehen weitere Module zur Verfügung, die das Betriebssystem ergänzen. Module sind eigenständige Programmteile, die zu einer Einheit verlinkt werden, die man dann Stack nennt. Der Stack ist ein Bestandteil der Firmware, der einzeln lizenzierbar ist. Der Zusammenbau einer kompletten Firmware für ein bestimmtes Gerät, besteht in erster Linie aus der Kombination bestehender Stacks, die dann angepasst werden und zusammen mit dem ebenfalls angepassten RTOS die Grundlage für das Gerät bilden.
Es wird immer nur eine gewisse Auswahl an Stacks für ein Projekt benötigt. Elink hat eine große Menge fertiger Stacks für die verschiedensten Aufgaben im Portfolio. Für die Programmierung, Test und Pflege sind insgesamt weit mehr als 100 Mannjahre aufgewendet worden. Dabei sind natürlich auch bestehende Teile verbessert und erneuert worden, so dass der Aufwand für die Neuerstellung der gleichen Stacks heute bei etwa 40 Mannjahren liegen würde. Davon sind allein 30 Mannjahre für den Bereich Netzwerktechnologie (TCP/IP, VoIP) anzusetzen.
- Zusammenhang mit der Anwendung
Nachdem die richtigen Stacks zusammengestellt und angepasst wurden ist die nächste Aufgabe des Programmierers die Programmteile zu schreiben, die aus den Stacks ein verwendbares Ganzes machen. Diese Programmteile nennt man Anwendung und werden ausschließlich speziell für das einzelne Zielsystem geschrieben. Anwendungen werden deshalb nicht lizenziert sondern für den Einzelfall verkauft, sozusagen als Zubehör zur Hardware.
Die Anwendungssoftware beschäftigt sich mit der Bedienung und der Grundfunktion eines Systems. Sie verwendet die Stacks wie Werkzeuge um damit sinnvolle Aufgaben zu erfüllen. Bedienelemente werden abgefragt, Anzeigen gesteuert, Daten verschickt und empfangen und in Abhängigkeit von anderen Ereignissen beeinflusst. Auch die Systemkonfiguration, Webseiten und Befehlsoberflächen gehören zur Anwendung.
Die Stacks sind wie ein großer Werkzeugkasten, aber die Anwendung bestimmt, was mit diesen Werkzeugen gebaut wird und wie es gebaut wird. Es macht zum Beispiel einen großen Unterschied wie und wohin eine Audioverbindung aufgebaut wird:
- Wodurch wird sie ausgelöst?
- Welche Gegenstelle soll angerufen werden?
- Welches Protokoll wird für die Übertragung verwendet?
- Wie sind die Sprachdaten zu codieren?
- Welche Informationen sind zusätzlich zu übergeben?
- Auf welche Ereignisse soll während der Verbindung wie reagiert werden?
- Was soll bei Erkennen eines Fehlers passieren?
- Ist die Gegenstelle bereit?
- Wie wird das Ende einer Verbindung signalisiert?
- Sind Timeouts zu beachten?
- Wie wird die Verbindung beendet?
Jedes Gerät bedingt eine andere Anwendung. Die Unterschiede sind sehr groß. Die Zusammenstellung und Anpassung der notwendigen Stacks ist meistens in einigen Mannwochen erledigt. Die Anwendung selbst kann manchmal, bei simplen Projekten, auch in wenigen Wochen (Entwicklung und Test) erledigt sein. Manchmal braucht es aber auch mehrere Mannmonate.
Das Herz eines jeden Gerätes ist also nicht die Hardware, sondern die Firmware, bestehend aus Stacks und Anwendungsprogrammteil. Beides kann, obwohl es nur zusammen zu einer funktionierenden Einheit führt, getrennt betrachtet und erstellt werden. Nicht notwendigerweise muss beides aus einer Hand kommen, wenn es auch die Sache deutlich vereinfacht.
Stacks sind oft komplexer als man glaubt. Im Bereich VoIP ist der Austausch von Sprachdaten ein sehr umfangreicher Vorgang. Die Sprache erreicht über ein Mikrofon einen Vorverstärker und dann einen analog/digital-Wandler. Dieser wandelt das Audiosignal in einen digitalen Datenstrom um, der dann in den Prozessor geleitet wird. Hier zeigt sich schon, dass das Programm keinerlei Verzögerung zulassen darf. Nach der Digitalisierung steht für jedes Sample eine Zeit von 2-12µs zur Verfügung. In dieser Zeit muss das Sample verarbeitet sein, egal was der Prozessor sonst noch zu tun hat, sonst geht das Sample verloren. Jedes verlorene Sample ist ein Codierungsfehler und damit hörbar.
Der digitale Audiostream muss nun ggf. in der Dynamik variiert und codiert werden (das ist ein Rechenvorgang). Auch der gängige Codec G.711, den man aus dem ISDN und der allgemeinen Telefonie kennt, komprimiert die Audiodaten. Höherwertige Codecs, wie z.B. der G.722, stellen noch viel höhere Ansprüche.
Audiodaten bewegen sich nur in den wenigsten Fällen lediglich in eine Richtung. In der Praxis ist neben dem Mikrofon auch ein Lautsprecher in Betrieb, der über die Luft und den Körperschall des Gehäuses ins Mikrofon zurückspricht. Da die digitale Audioübertragung immer eine gewisse Verzögerung bewirkt, kann man diesen Effekt als unangenehmes Echo wahrnehmen. Um solche Echos zu vermeiden oder zumindest zu vermindern, müssen die empfangenen mit den gesendeten Audiodaten in geeigneter Weise verrechnet werden. Dies ist ein so komplexes Verfahren, dass man dafür einen DSP benötigt, der in Assembler programmiert werden muss.
Nun sind die digitalen Sprachdaten fertig für den Versand. Verbindungsaufbau und Protokollverhandlungen sind gleichzeitig von anderen Stacks erledigt worden und die Sprachdaten werden nun dementsprechend paketiert und gemäß dem RTP (real time protocol) verpackt und mit den zugehörigen Headerdaten, die wiederum ein anderer Programmteil erzeugt hat, in einen RTP-Frame gepackt. Dieser wird dann in einem UDP-Frame (user datagram protocol) untergebracht, der wiederum in einen IP-Frame (internet protocol) gepackt wird. Dieser wird entsprechend dem verwendeten Medium noch einmal verpackt um damit schließlich wirklich versendet zu werden. Normalerweise ist das an dieser Stelle das Ethernet, was eine Umadressierung von IP-Adressen auf MAC-Adressen erfordert, wofür wieder ein komplettes unabhängig verlaufendes Protokoll (ARP = address resolution protocol) erforderlich ist.
Dieses leicht verwirrende Beispiel (und es ist trotzdem noch vereinfacht) soll nur zeigen, wie komplex der ganze Vorgang ist, wenn man nur versucht digitale Sprachdaten zu verschicken. Empfangen muss man sie ja auch noch (gleichzeitig) und es gibt noch eine Menge anderes, was der Prozessor zu erledigen hat. Um dies alles zu bewerkstelligen sind viele Jahre harter Arbeit notwendig und so versteht man auch, dass Entwicklungskosten von einigen Millionen Euro zusammenkommen, wenn man versucht, das alles nochmal von vorn zu entwickeln.
Gewöhnlich baut man heute auf bestehende Betriebssysteme auf, die man entsprechend lizenziert. Windows, MAC OS, Unix und andere professionellere Varianten sind aus der PC-Welt her bekannt. Sogenannte „freie“ Betriebssysteme sind zwar eine Alternative, aber was man an solchen Systemen (Linux usw.) bearbeitet, ist ebenfalls „frei“ und muss veröffentlicht werden. Und damit gibt man jedem die Möglichkeit, es zu benutzen und zu kopieren. Keine Option für den professionellen Einsatz.
Diese, für den Einsatz in kleinen Gerätschaften, völlig überdimensionierten Systeme, bieten auch nicht genügend Sicherheit für den industriellen Einsatz.
|
