Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
Eine Computerplattform (auch -schicht oder -ebene, kurz Plattform) bezeichnet in der Informatik eine einheitliche Grundlage, auf der Computerprogramme ausgeführt und entwickelt werden können.
Eine Plattform ist eine Komponente eines Rechnersystems und befindet sich im Verbund mit weiteren Komponenten. Dabei kann es sich um die Hardware oder das Betriebssystem (OS), sogar um einen Webbrowser und die zugehörigen Programmierschnittstellen oder andere zugrunde liegende Software handeln, solange das Computerprogramm damit ausgeführt wird.
Für die betrachtete Plattform selbst sind die weiteren Komponenten des Rechnersystems, in dem sie arbeitet, nicht sichtbar. Eine Plattform kann aufgrund dieser Abstraktion auf unterschiedliche Rechnersysteme übertragen werden und arbeiten (siehe grafische Darstellung). Die interne Komplexität des Computersystems wird hierbei mit Hilfe von Softwaretechnik erhöht, was vereinfachte Nutzung durch menschliche Anwender zur Folge hat.
Bestandteile bzw. Abstraktionsebenen einer typischen Plattform sind: Rechnerarchitektur, Softwarestack, Laufzeitumgebung, Programmiersprache.
Die Idee hinter einer Plattform ist Abstraktion und Vereinfachung.
Erreicht werden kann diese Vereinfachung dadurch, dass dem Anwendungsentwickler ein abstrakteres Funktionsmodell von konkreter Funktionalität zur Verfügung gestellt wird, typischerweise in Form einer Programmierschnittstelle (eng. API), welche darunter liegende Funktionalität einhüllt. Für die resultierende Anwendung geschieht das typischerweise in Form einer dynamisch interpretierten Laufzeitumgebung (z. B. JRE, Browser) oder einer binären ABI zu bekannten Softwarefunktionen.
Eine Qualität, die diese Abstraktionsschichten bieten können, ist Allgemeingültigkeit, üblicherweise als Kompatibilität bezeichnet. Das kann sich auf die Breite, also die Menge der verschiedenartigen, abstrahierten Details beziehen, wie auch auf die Stabilität der Plattform über die Zeit. Bei der Kompatibilität über die Zeit kann die Sicherstellung der Abwärtskompatibilität bei einer Weiterentwicklung einer Plattform gemeint sein oder auch die Zusicherung des Herstellers, dass mit dem Aufkommen neuer abstrahierbarer „Details“ (z. B. neue Betriebssysteme, neue Hardware) diese in die Plattform integriert werden (Aufwärtskompatibilität).
Bei Plattformen kann zwischen Soft- und Hardwareplattformen unterschieden werden.
Eine Hardwareplattform, auch Maschinenebene genannt, bezeichnet eine bestimmte Rechnerart oder eine [Prozessor]-Familie. Die Maschinenebene ist hauptsächlich durch eine bestimmte Rechner- oder Prozessorarchitektur gegeben und liegt logisch betrachtet ganz unten – unter der Anwendungsebene.
Eine Prozessorarchitektur-Plattform verwendet eine einheitliche Maschinensprache, Datenwortgröße, Byte-Reihenfolge usw. Ein Beispiel dafür ist die weitverbreitete x86-Architektur.
Wie die einzelnen Befehle dieser Maschinensprache intern im Mikroprozessor verarbeitet werden (z. B. mit Micro-ops), kann sich aber innerhalb der gleichen Plattform stark unterscheiden. Nur die Endergebnisse, welche die Befehle liefern, bleiben dieselben.
Hardwareplattformen können grob in CISC- und RISC-Architekturen eingeteilt werden. Bei aktuellen Prozessorarchitekturen verwischen sich aber die Grenzen zwischen diesen beiden Architekturtypen zusehends.
Die sogenannten Software-Plattformen, auch Anwendungsebene genannt, werden wie folgt unterschieden.
Kompatibilität über die Zeit lässt sich beispielsweise über stabilgehaltene Binärschnittstellen von Funktionsbibliotheken erreichen, mit denen auf die Plattform zugegriffen wird. Bei einer Weiterentwicklung der Plattform muss ausschließlich der Plattformanbieter dafür Sorge tragen, dass die Kompatibilität erhalten bleibt. Dieser muss dann die neue Version seiner Plattformbibliothek verbreiten, Änderungen am Anwendungsprogramm (Neukompilierung oder Anpassung) durch Anwendungsentwickler oder Konfigurationsänderungen durch Anwender sind nicht notwendig.
Neben dem obigen Konzept einer auf Binärkompatibilität basierenden Plattform, welches eine weitergehende Lauffähigkeit von einmal erstellter Software ermöglicht, existiert noch das Konzept der Kompatibilität über die Portierbarkeit des Quellcodes eines Anwendungsprogramms. Hier wird keine langfristige oder breite Lauffähigkeit der Anwendungsprogramm-Kompilate garantiert,[1] sondern eine Kompilierbarkeit mit einer weiten Palette an unterliegender Hardware, Programmbibliotheken und Software-APIs, auch Plattformunabhängigkeit genannt. Nachteile sind, dass der Vorgang des Kompilierens dann häufiger und vor allem durch den Anwender oder Anwendungsentwickler durchgeführt werden muss, ein manchmal komplexer und fehlerträchtiger Vorgang. Auch die Erstellung portabler Software für eine solche Plattform ist ein Problem.[2] Ebenso kann die Notwendigkeit, dass der Quellcode beim Anwender vorliegen muss, ein Hindernis sein, da beispielsweise bei proprietärer Software eine Offenlegung von diesem unüblich ist. Deshalb ist dieses Konzept der Quellcode-basierenden Kompatibilität vor allem im Open-Source-Bereich und bei unixähnlichen Betriebssystemen dominierend, die Binärkompatibilität dagegen beispielsweise bei Windows[3][4] oder den Mac-Betriebssystemen.[5]
Beispielsweise ermöglicht es eine Softwareplattform – wie die Win32-API und andere ähnliche in Betriebssysteme integrierte Schnittstellen – Softwareentwicklern, Anwendungen zu schreiben, die auf veränderlicher Hardware, wie Prozessoren unterschiedlicher Hersteller, verschiedenen Grafikkarten, verschiedenen Peripheriegeräten usw. funktionsfähig sind. Typischerweise werden solche Anwendungen jedoch zu binären Programmen, bestehend aus Maschinenbefehlen, kompiliert, sind also nur auf einer spezifischen Hardware funktionsfähig, setzen also auf diese Hardwareplattform auf. Dieses Vorgehen kann als Kompromiss aus Effizienz und Abstraktionsgrad betrachtet werden, da dadurch aufwändige Konvertierung zur Laufzeit eingespart wird.
Bei dynamisch interpretierten Laufzeitumgebungen wird die Anwendung von der Hardware noch weitergehend abstrahiert. Das bedeutet, dass Befehle und Daten einer Laufzeitumgebung oder einem Dienst übergeben werden und dort erst zur Laufzeit interpretiert oder in die entsprechende Maschinensprache übersetzt werden. Weitergehend können mit einer Laufzeitumgebung (z. B. JRE oder Webbrowser) auch verschiedene unterliegende Betriebssysteme, also andere Softwareplattformen, wegabstrahiert werden.
Für die Werbung werden oft Markennamen in vereinfachender Weise, als technisch betrachtet eigentlich zu differenzierende Plattformen, zusammengefasst. Ein bekanntes Beispiel dafür ist die „Macintosh-Plattform“, deren technische Plattformen sich je nach Generation grundlegend unterscheiden können. Diese vereinfachende Sicht ist teilweise in den Sprachgebrauch und die öffentliche Wahrnehmung übergegangen.
So wirbt z. B. die Firma Apple mit der „Macintosh“- bzw. „Mac“-Plattform, obwohl über die gesamte Zeit des Bestehens praktisch alle Plattformen, die Macintosh ausmachen, (teilweise mehrfach) ausgetauscht wurden. Aus technischer Sicht besteht und bestand Macintosh aus sehr unterschiedlichen und teilweise inkompatiblen Hard- und Softwareplattformen. (Im Laufe seiner Geschichte nutzte bzw. nutzt der „Macintosh“ aus Sicht der Prozessorarchitektur 680x0, PowerPC, IA-32 bzw. x64 und ARM64. Von Apple-Betriebssystemen verwendete Softwareschnittstellen und Standards sind bzw. waren Carbon, Cocoa, POSIX, SUS, GNU-Software-Umgebung, JRE etc.) Um den Nutzern einen reibungslosen Wechsel dieser Architekturen zu gewährleisten verwendete Apple übergangsweise Ansätze wie Fat Binarys oder Universal Binaries und (transparente) Emulatoren. Dadurch wurde die ganze Produktfamilie in der Öffentlichkeit weiter als eine einheitliche Plattform wahrgenommen.
Ähnliches gilt auch für die von der Firma Microsoft beworbene Marke „Windows“. Obwohl die Änderungen nie so umfassend waren wie bei Macintosh, ist auch Windows keine einheitliche Plattform. (Es nutzt die Plattformen x86 – IA-32 und x64 – sowie ARM, in der Vergangenheit auch MIPS, POWER bzw. PowerPC, Alpha sowie Itanium und stellte oder stellt die Plattformen DOS, Win16, Win32, Win64, Native API, Windows CE, .NET, POSIX, OS/2 und andere Anwendungen zur Verfügung.) So sind z. B. die Win32- und die Windows-CE-API nur sehr bedingt kompatibel. Alle auf den DOS- oder Windows-NT-Kernel aufbauenden Windows-Produkte enthalten mehrere Plattformen, wodurch für Anwendungen eine Rückwärts-Kompatibilität von teilweise bis zu 30 Jahre (im Fall von Win16) erreicht wurde.
Hersteller von Plattformen haben verschiedene Vorgehensweisen bezüglich der Offenheit bzw. Geschlossenheit ihrer Plattformen. Dies betrifft z. B. das Entwicklungsmodell, Kostenmodell oder den Grad der Offenheit bzw. Freiheit die bei der Verwendung auf verschiedenen Ebenen gewährt wird.
In der Industrie bilden Plattformen die Infrastruktur für Geschäftsmodelle der Digitalisierung.[6] Die digitale Plattform dient hier als IT-Architektur für „Datengenerierungen, Datenstrukturierungen und Datenaustauschformate auf Basis technischer Standards“.[7] Es entsteht ein „digitaler Backbone“, der in digitaler Kontinuität alle Akteure und Aktionen verbindet, die an der Wertschöpfung mitwirken.
Als Anwendungsschnittstelle kann im Wesentlichen eine durch das Betriebssystem eingeführte oder inkludierte Programmierschnittstelle (englisch Application Programming Interface, kurz API) bezeichnet werden. Es gibt jedoch auch plattformübergreifende APIs, die auf mehreren Betriebssystemen als Laufzeitumgebung verfügbar sind und oft nachträglich installiert werden müssen.
Plattformen für Personal Computer sind eng mit jenen für Anwendungsschnittstellen und Betriebssysteme verknüpft, gehen aber u. U. über Betriebssystemgrenzen hinweg. PCs (im Allgemeinen Sinn von „persönlicher Computer“) und Heimcomputer sind nicht nur Plattformen für Arbeitscomputer, meist sind sie gleichzeitig auch Spieleplattformen.
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
