Sicherheit und Zuverlässigkeit der Computersysteme des Space Shuttles

Größe: px
Ab Seite anzeigen:

Download "Sicherheit und Zuverlässigkeit der Computersysteme des Space Shuttles"

Transkript

1 Sicherheit und Zuverlässigkeit der Computersysteme des Space Shuttles Malte Diehl Department für Informatik Carl-von-Ossietzky-Universität Oldenburg The faulty Solid Rocket Motor joint and seal must be changed. [...] The joints should be fully understood, tested and verified. The Presidential Commission on the Space Shuttle Challenger Accident Abstract Sicherheit und Zuverlässigkeit stehen bei bemannten Flügen ins Weltall ganz oben auf der Anforderungsliste. Dieser Artikel befaßt sich daher mit den Techniken, die eingesetzt wurden, um die US-amerikanischen Space Shuttles so zuverlässig und sicher wie möglich zu machen. Das Augenmerk wird dabei auf Hard- und Software sowie die Überwachung der Raumfähren vom Boden aus gelegt. Schließlich soll untersucht werden, inwieweit die Raumfähren den in sie gesetzten Erwartungen gerecht wurden, auch im Hinblick auf die beiden schweren Unglücke, bei denen Shuttles abgestürzt sind. 1. Einleitung Das 1972 gestartete Space-Shuttle-Programm der NASA (National Aeronautics and Space Administration) ist das wohl bekannteste und eines der wichtigsten Raumfahrtprojekte unserer Zeit. Ziel war es, ein kostengünstiges, flexibles und sicheres System zu entwickeln, um Lasten und Personen in den Weltraum zu transportieren. Besonderes Interesse verdienen die Space Shuttles, weil sie zu den wenigen bemannten Raumfahrzeugen weltweit gehören und die einzigen sind, die nach einer Mission wiederverwendet werden können. Höchste Ansprüche an Sicherheit und Zuverlässigkeit kennzeichnen Entwicklung und Einsatz der Shuttles, da Abstürze nicht nur Geld, sondern auch Menschenleben kosten. Um so interessanter ist es daher, genauer zu betrachten, was getan wurde, um die korrekte Funktionalität der Raumfähren sicherzustellen. Welche möglichen Fehler können auftreten? Welchen Gefahren muß begegnet werden? Welche Vorsichtsmaßnahmen sind sinnvoll und machbar? Wie lassen sie sich mit beschränkten Rechnerleistungen umsetzen? All dies sind Fragen, die die Ingenieure nicht nur bei der Entwicklung, sondern auch bei allen Verbesserungen des Shuttles zu beantworten hatten. Das Ziel dieses Artikels ist nachzuvollziehen, wie sie möglichen Problemen im Bereich der Informatik begegnet sind. Zunächst aber folgt ein kurzer chronologischer Abriß, in dem die Meilensteine des Projektes bis heute dargestellt werden [8, 9, 12]. 5. Januar 1972: Offizieller Start des Space-Shuttle- Programms 17. September 1976: Auslieferung des ersten Shuttles Enterprise für Landungstests Oktober 1977: Beginn der Entwicklung des Primary Flight Software Systems 25. März 1979: Auslieferung des ersten voll funktionsfähigen Shuttles 12. April 1981: Erster Raumflug eines Shuttles 28. Januar 1986: Explosion der Raumfähre Challenger kurz nach dem Start 12. September 1992: 50. Space-Shuttle-Mission 11. Oktober 2000: 100. Space-Shuttle-Mission 1. Februar 2003: Verglühen der Raumfähre Columbia beim Wiedereintritt in die Atmosphäre Frühjar 2005: Wiederaufnahme der Flüge geplant 2. Untersuchung der Computersysteme Bevor wir mit der Analyse beginnen, sollen noch drei Begriffe definiert werden, mit denen wir im folgenden immer wieder zu tun haben [16]:

2 Sicherheit: Abwesenheit von Gefahren für Mensch und Maschine Zuverlässigkeit: Fähigkeit eines Systems, in vorgegebenen Zeiträumen und Einsatzbedingungen eine bestimmte Aufgabe zu erfüllen Fehlertoleranz: Fähigkeit eines Systems, seine Aufgabe trotz einer bestimmten Anzahl von Fehlern zu erfüllen 2.1. Fehler- und Gefahrenanalyse Während die Außenhaut eines Raumschiffs etwa den enormen Hitzebelastungen beim Eintritt in die Atmosphäre gewachsen sein muß, so darf die Bordelektronik nicht durch etwaige Hardware- oder Softwarefehler lahmgelegt und das Space Shuttle somit manövrierunfähig werden. Gerade in kritischen Situationen wie bspw. direkt nach dem Start, wenn noch keine stabile Umlaufbahn eingenommen wurde, entstünde dadurch eine enorme Gefährdung. Die Hardware des Shuttles muß daher eine hohe Fehlertoleranz aufweisen. Die physische Beschädigung oder Zerstörung eines einzelnen Rechners oder einer seiner Komponenten darf keine Auswirkungen auf die Sicherheit der Besatzung haben. Um einem solchen Fall begegnen zu können, müssen wenigstens die für die Steuerung und die Lebenserhaltung nötigen Rechner mehrfach vorhanden sein, und es muß die Möglichkeit geben, nach dem Ausfall eines solchen Rechners die jeweiligen Programme sicher auf irgendeinem anderen auszuführen. Auch stellt sich die Frage, ob einfache Redundanz bei kritischen Systemen ausreicht oder nicht, da während des Fluges keine Reparaturen an der Hardware vorgenommen werden können. Ein weiteres sicherheitskritisches Problem sind fehlerhafte Berechnungen seitens der Hardware. Wenn ein Computer bei korrekten Eingabedaten falsche Ergebnisse liefert, so dürfen diese keinesfalls an die Besatzung weitergeleitet werden. Eine falsche Anzeige des Eintrittswinkels in die Atmosphäre z.b. könnte die Piloten zu fatalen Kurskorrekturen veranlassen. Unabdingbar ist also an dieser Stelle eine Fehlererkennung und -unterdrückung durch die anderen redundant arbeitenden Rechner, am besten aber durch den verursachenden Rechner selbst. Die Anforderungen an die Software beschränken sich im wesentlichen auf völlige Fehlerfreiheit (die aber bei realistischer Betrachtung unmöglich zu erreichen ist). Durch Fehler verursachte falsche Anzeigen auf den Displays im Cockpit könnten ähnlich schlimme Folgen haben wie Rechenfehler der Hardware. Am gefährlichsten sind fehlerhafte Algorithmen, deren Ergebnisse falsche Befehle an die Steuerung des Shuttles auslösen und kaum von internen Testprogrammen erkannt werden können. Unter Umständen könnten unerkannte Fehler gar alle redundanten Rechner gleichzeitig zur Abschaltung zwingen, was den Absturz der Raumfähre bedeuten würde. Eine weitere potentielle Gefahr besteht schließlich darin, daß die Software vor ihrem Einsatz nur unzureichend auf die Hardware abgestimmt wird. Eine andere, oft unterschätze Gefahrenquelle stellt auch das Cockpit dar. Mangelhafte Ergonomie der sogenannten Mensch-Maschine-Schnittstelle kann dazu führen, daß die Piloten z.b. durch völlige Überflutung mit momentan irrelevanten Informationen dazu verleitet werden, wichtigere Daten zu ignorieren, so daß flugkritische Steuerungsbefehle ggf. unterbleiben. In den folgenden Abschnitten werden wir näher betrachten, wie die verantwortlichen NASA-Mitarbeiter an diese und andere Probleme herangingen und sie bewältigten Shuttle-Hardware Grundlegende Informationen Das Rückgrat der Hardware der Raumfähren bilden fünf identische digitale Mehrzweckrechner (engl. general purpose computer, GPC), die jeweils mit den Avioniksystemen kommunizieren und kritische wie auch unkritische Aufgaben erledigen können [8]. Ein GPC wiederum besteht aus einer CPU vom Typ IBM AP und einem Input/Output-Prozessor (IOP). Jeder IOP ist an verschiedene 1-MHz-Busse angeschlossen, über die er mit digitalen und analogen Subsystemen sowie den anderen IOPs kommuniziert (siehe Abbildung 1). Die Busse werden zu Gruppen zusammengefaßt, wobei niemals zwei redundante Subsysteme 2 am selben Bus hängen, damit bei einem Busausfall nie zwei gleiche Subysteme mit ausfallen. Der Grad der Redundanz eines (Sub)systems hängt von seiner Wichtigkeit ab. So kümmern sich insbesondere in kritischen Flugphasen (Start, Landung etc.) vier GPCs um dieselben kritischen Berechnungen, während nur ein GPC für den Rest zuständig ist. Das Subsystem zur Trägheitsmessung ist hingegen nur dreifach vorhanden. Damit wird gewährleistet, daß das Gesamtsystem unter bestimmten Bedingungen auch mehr als einen Ausfall einer Komponente gleichzeitig tolerieren kann. Manche Subsysteme wie z.b. die Handsteuerung weisen auch interne Redundanzen [2] auf, d.h., sie sind mit zusätzlichen Schaltkreisen ausgestattet und erhalten statt einer einzigen Eingabe Daten von allen zu einer redundanten Gruppe zusammengefügten Rechnern und erzeugen unter Verwendung interner Algorithmen eine einzige, fehlerbereinigte Ausgabe. Dieses Vorgehen hat den Vorteil, daß es i.a. nichts ausmacht, wenn ein Computer falsche Daten an 1 Der IBM AP-101 mit 424 KB Hauptspeicher [3] wurde bereits im US- Langstreckenbomber B-52 eingesetzt und befindet sich nach Verbesserungen Anfang der 90er Jahre als AP-101s noch immer im Space Shuttle. 2 Redundante Subsysteme sind z.b. die Radar-Höhenmesser, die Trägheitsmesser oder die Luftdatenmeßgeräte.

3 Abbildung 1. Rechnerarchitektur im Space Shuttle [2, S. 21] solch ein System sendet, da Fehler beseitigt werden. Somit ist die Erkennung und Wiederherstellung ausgefallener Rechner zwar noch immer wichtig, jedoch nicht mehr zeitkritisch. Im übrigen ist das Bussystem so ausgelegt, daß jeder GPC Zugriff auf alle übertragenen (kritischen) Daten hat, womit Berechnungen leicht verglichen und somit auf ihre Korrektheit überprüft werden können. Die Kommunikation zwischen den GPCs erfolgt über fünf Inter-computer channel-busse (ICC), an die keine Subsysteme angeschlossen sind. Neben der Identifikation fehlerhafter Ausgaben auch bedeutsam und vor allem zeitkritisch ist die Synchronisation der Rechner, da die Kontrolle über die Subsysteme auf die GPCs verteilt ist. Diese geschieht teils mittels spezieller Signale, die zwischen den GPCs ausgetauscht werden, teils mittels Synchronisationssoftware Anforderungen an das Redundanzmangement (RM) Für die GPCs ergaben sich seitens der NASA die folgenden fünf Anforderungen an das Redundanzmanagement (vgl. [2]): Ein ausfallender GPC muß mit 96%iger Wahrscheinlichkeit durch Selbsttests erkannt (Hardwareabdeckung) und der Besatzung gemeldet werden, bevor er der redundanten Gruppe zugeordnet wird, damit z.b. die Mission rechtzeitig vor dem Start abgebrochen werden kann. Bei vier redundanten GPCs müssen zwei bei Versagen sofort identifiziert und angezeigt werden. Gleiches gilt - sofern mit angemessenem Ressourcenverbrauch möglich - für den dritten Rechner. Dies bezweckt, daß die Besatzung rechtzeitig Gegenmaßnahmen wie Abschaltung, Neukonfiguration etc. einleiten kann. Ein fehlerhaft arbeitender GPC soll in der Lage sein, automatisch all seine Übertragungen zu unterbinden, sofern die Besatzung diese Option eingeschaltet hat (zwecks automatischer Neukonfiguration). Fehler eines GPCs dürfen nicht dazu führen, daß ein anderer GPC als fehlerhaft erkannt wird, damit sich Fehler nicht fortpflanzen. GPCs, die wegen einer vorübergehenden Fehlfunktion falsche kritische Daten liefern, sollen baldmöglichst rekonfiguriert werden, um Auswirkungen temporärer Fehler gering zu halten. Darüber hinaus kam man zu dem Schluß, daß es nützlich sei (vgl. [2]),

4 eher die Auswirkungen von Hardwarefehlern auf die Ausgabeschnittstellen als die Hardwarefehler an sich zu entdecken, da sich GPCs oder Teile davon im Weltall ohnehin kaum austauschen lassen, durch spezielle, zusätzliche Hardware die Abhängigkeit davon zu minimieren, daß Computer sich selbst als fehlerhaft erkennen, Software zu benutzen, um den Zustand eines GPCs zu beurteilen, indem z.b. von ihr der Vergleich von Outputs (s.o.) durchgeführt wird, Prüfsummen für kritische Outputs zu generieren und zu überwachen, ein Vergleichswort über die ICC-Busse zu übertragen und Fehler in der zusätzlichen RM-Hardware durch Testprogramme, die in jeder CPU ausgeführt werden, aufzuspüren, zumal diese Fehler systemkritisch sind Implementierung des Redundanzmangements Wie wurden diese Anforderungen und Überlegungen nun beim Systemdesign umgesetzt? Prinzipiell muß zwischen zwei Arbeitsmodi unterschieden werden, für die jeweils unterschiedliche Maßnahmen getroffen wurden (vgl. [2]): 1. drei/vier GPCs in der redundanten Gruppe 2. zwei GPCs in der redundanten Gruppe Im ersten Fall werden zwei kooperative Tests durchgeführt, die zusammen vollständige Abdeckung aller möglichen flugkritischen Ausfälle gewährleisten. Einer davon ist ein Timeout-Test, bei dem nach der Synchronisation der GPCs eine bestimmte Zeit darauf gewartet wird, daß die Rechner eine Eingabetransaktion auf ihrem Bus ausführen. Tut ein GPCs dies nicht, wird er als fehlerhaft behandelt. Eine andere Methode sind Tests mittels eines Vergleichsworts. Hierzu wird ein Vergleichswort aus kritischen GPC- Ausgaben gebildet und über die ICC-Leitungen den anderen redundanten Computern übermittelt. Danach werden Vergleichsworte von anderen Rechnern empfangen, gespeichert und eine Zeit gewartet, damit gewährleistet ist, daß alle Rechner die Wörter empfangen. Schließlich werden empfangene Worte mit dem berechneten verglichen. Ein Computer wird als fehlerhaft erkannt, wenn er durch seine Vergleichswörter zwei fehlgeschlagene Vergleiche in Folge ausgelöst hat. Der Input/Output-Prozessor jedes GPCs verfügt über ein 4-Bit-Register. Jedes dieser Bits steht für einen der anderen Computer und wird gesetzt, sobald der zugehörige GPC aus Sicht des urteilenden Rechners fehlerhaft arbeitet. Jedes dieser vier Bits steuert einen Treiber, der in Verbindung steht mit dem IOP des jeweils anderen GPCs sowie mit Anzeigen im Cockpit. Außerdem existieren pro GPC vier Empfänger, die anzeigen, welche der anderen Computer die Entscheidung über den Ausfall eines anderen GPCs akzeptieren oder eben nicht. Bei mindestens zweifacher Akzeptanz erzeugt die sogenannte Voter logic ein Signal, so daß der Besatzung ein kritischer Ausfall angezeigt wird. Um ein solches Problem zu beheben, kann der betroffene Rechner je nach Lage entweder rekonfiguriert, aus der redundanten Gruppe genommen oder von den Failure votes ausgeschlossen werden. Falls nur zwei GPCs redundant arbeiten, werden in bestimmten Abständen Selbstests durchgeführt, und zwar auf drei Arten: Ein Überwachungstimer im Input/Output- Prozessor wird regelmäßig von der CPU geladen und kann Ausfälle, die die Programmausführung durch die CPU betreffen, entdecken. Zusätzlich gibt es mikrocode- und softwarebasierte Selbsttestprogramme (STP), die von der Besatzung ausgeführt werden können, um CPU-Versagen festzustellen. Außerdem existieren fest eingebaute Tests (ET), die aus der Hardware oder dem Mikrocode bestehen, die Interrupts verursachen, sobald CPU-Versagen festgestellt wird. Einen Überblick hierzu verschafft Tabelle 1. Art des Abdeckung Speicher- Rechenzeit Selbsttests der kritischen verbrauch- Hardware (%) (Halbworte) (ms) ET 36,9 0 0 ET+Timer 68,5 4 0,005 ET+Timer+STP 88,7 14 0,15 (nur Mikrocode) ET+Timer+STP 96, ,3 Tabelle 1. Beziehung zwischen Selbsttests, Hardwareabdeckung und Ressourcenverbrauch [2, S. 27] 2.3. Shuttle-Software HAL/S Eine Sprache für den Weltraum Für ein derart komplexes und sicherheitskritisches Projekt wie das Space Shuttle benötigte die NASA eine Programmiersprache, die es erlaubte, echtzeitfähige, robuste und gut zu wartende Programme zu schreiben [1, 10, 8]. Die bisherigen Programme waren entweder schwer verständlich und unhandlich (Assemblersprachen) oder nicht robust genug und zu langsam (Interpretersprachen). Um die NASA-Anforderungen zu erfüllen, wurde die Sprache HAL/S entwickelt, die neben bewährten Kon-

5 strollstrukturen spezielle Echtzeitanweisungen wie WAIT, SCHEDULE und PRIORITY enthielt und leicht verständlich auch für jene Ingenieure war, die bislang keine oder nur wenig Programmiererfahrung hatten. Überdies verzichtete man bei der Implementierung von HAL/S auf bestimmte, fehleranfällige Befehle wie GOTO. Zudem wurde die Durchführung raumfahrttypischer Berechnungen wie etwa Matrix-Arithmetik möglichst einfach gehalten. Das Vertrauen in die neue Sprache war so groß, daß die gesamten Bordprogramme des Shuttles ausschließlich in HAL/S geschrieben wurden. Jedoch wurden ab Mitte der 80er Jahre neue Projekte der NASA in ADA realisiert [1], da sich das US-Militär für diese Sprache entschieden hatte, so daß die Weltraum-Sprache weitgehend in Vergessenheit geriet PASS Das Primary Avionics Software System Das Primary Avionics Software System ist die Flugsteuerungssoftware für die Space Shuttles. Es besteht aus acht getrennt voneinander ausführbaren Modulen (siehe Abbildung 2), die auf einem Speicherband liegen und bei Bedarf von der Besatzung in den Hauptspeicher von GPCs geladen werden können [12]. Sie enthalten jeweils die Funktionen für eine bestimmte Flugphase sowie die Systemüberwachung und teilen sich ein gemeinsames Betriebssystem, das Flight computer operating system (FCOS) [3], welches typische Aufgaben wie das Prozeßmanagement übernimmt. Zudem ist PASS ist der Lage, mit dem Startsystem am Boden sowie über das Network signal processing (NSP) - Interface während des Fluges mit dem Kontrollzentrum in Houston zu kommunizieren. Für die Zuverlässigkeit von PASS ist die Tatsache von Bedeutung, daß das gerade benötigte Modul immer komplett in den Hauptspeicher geladen wird, damit keine Verzögerungen durch Nachladen von Daten oder gar kritische Fehler durch Unauffindbarkeit von Programmteilen entstehen. Gleichzeitig wird damit der Datenverkehr zwischen Hauptspeicher des jeweiligen GPCs und dem Massenspeicher auf das absolut Nötigste reduziert, was freie Kapazitäten schafft. Die wichtigste Anforderung an die Flugsoftware war und ist bis heute Fehlerfreiheit, da Ausfälle während eines Fluges mit unkalkulierbaren Sicherheitsrisiken verbunden sind. Um dies zu gewährleisen, muß PASS in kritischen Flugphasen in mehreren GPCs redundant arbeiten. Wie bereits in Abschnitt erwähnt, sind dazu Synchronisationen der Computer in der redundaten Gruppe unabdingbar. Das FCOS sorgt dafür, daß dies bis zu 330mal in der Sekunde geschieht, und kontrolliert zusätzlich die Eingabedaten, um Fehler auszuschließen. Wie bei sicherheitskritischen Komponenten üblich, wurde bei der Entwicklung der Flugsteuerungssoftware PASS ganz besonderer Wert auf ingenieurmäßiges Vorgehen gelegt, um die Fehleranfälligkeit bereits vor den Tests zu minimieren. Dafür bediente man sich zahlreicher, mitunter neuartiger Techniken, die von vielen damals üblichen Programmiersprachen nur unzureichend oder gar nicht unterstützt wurden wie z.b. Modularisierung, Datenkapselung zwischen den Prozessen, klare Programmstrukturierung, Entwurfsdokumentation und Kommentare im Quellcode. Darüber hinaus gab es abschließende Prüfungen der Übereinstimmung mit diesen Methoden und Abweichungsberichte. Bei der Implementierung der Komponenten wurde eine Top-down-Vorgehensweise gewählt (vgl. [12]. Am Anfang wurden die Strukturen der Kontrollsegmente entworfen, die zusammen mit bereits existierender Software installiert wurden. Die NASA hatte vor Beginn der PASS- Entwicklung bereits Anflug- und Landungstests mit speziell dafür entwickelten Programmen durchgeführt. Programmteile, für die noch keine klaren Anforderungen vorlagen, wurden zunächst als Stümpfe implementiert, damit schon Tests durchgeführt werden konnten, und erst später, nachdem sich die Bedürfnisse herauskristallisiert hatten, ausprogrammiert. Die Anforderungen an die Flugsoftware mußten dabei mehrfach angepaßt werden. Zum einen stellte sich heraus, daß die Ressourcen der Bordcomputer nicht ausreichten, so daß Funktionen wieder gelöscht und Ausführungsraten von Programmen herabgesetzt werden mußten. Zum anderen war die verwendete Hardware zur Software nicht vollständig kompatibel. Vor allem aber war kein Testshuttle verfügbar. Die Softwareentwicklung für den ersten richtigen Flug des Space Shutte dauerte insgesamt 31 Monate und umfaßte insgesamt 17 inkrementelle Releases, wobei bereits nach dem neunten Release im Dezember 1978 alle Funktionen integriert waren. Jedoch bedurfte es acht weiterer Releases, um alle Anforderungen, die sich teilweise immer noch änderten, zu erfüllen. Aus den Erfahrungen mit der Entwicklung von PASS, das ungeahnte Komplexität entwickelt hatte, entstand auch die Forderung nach besseren Möglichkeiten des Software- Engineerings [8], wie sie heute als selbstverständlich gelten BFS - Das Backup Flight System Die Software des Backup Flight System kommt nur in kritischen Flugphasen wie z.b. beim Eintritt in die Atmosphäre aktiv zum Einsatz [4]. Es beansprucht lediglich einen der fünf GPCs für sich und dient als Rückfallebene, wenn es im PASS zu schweren Fehlern kommen sollte. Noch vor dem Start wird das BFS in den Hauptspeicher des ihm zugewiesenen GPCs geladen und dort bis zum Ende des Fluges

6 Abbildung 2. Module der Flugsteuerungssoftware [12, S. 915] gehalten, um ggf. nicht von der Funktionstüchtigkeit der externen Massenspeicher abhängig zu sein. In normalen Flugphasen arbeitet das BFS im Hintergrund und wertet die Datenströme von Computern und Sensoren aus, so daß es stets auf dem neuesten Stand ist und somit zu jeder Zeit in der Lage, die Kontrolle der Raumfähre zu übernehmen. Dies geschieht jedoch nicht automatisch, sondern nur, nachdem von einem der Piloten im Cockpit ein entsprechender Befehl per Knopfdruck erteilt worden ist. Sinn einer Kontrollübernahme durch das BFS ist es vor allem, das PASS währenddessen neu zu starten, um damit weiterarbeiten zu können. Um die Übernahme eventueller Fehler zu vermeiden, wurde die BFS-Software unabhängig von der des PASS entwickelt und programmiert. Gleichwohl ist sie ähnlich wie das PASS zu bedienen, damit so wenig Umstellung wie möglich seitens der Astronauten vonnöten ist Das Testmodell der Shuttle-Software Ein großes Projekt wie die Flugsoftware des Space Shuttles ist erfahrungsgemäß nur mit durchdachten Testverfahren zu realisieren. Schon damals kamen viele Methoden zum Einsatz, die noch heute angewandt werden, wie etwa Coderewievs, formale Verifikationen und Systemtests (vgl. [12]). Sämtliche Ergebnisse wurden dokumentiert und festgehalten. Der Testplan für die Entwicklungsphase des PASS vor seiner Verifikation und Validation gliedert sich in insgesamt fünf inkrementelle Ebenen: Einheitentests (1. Stufe): In dieser Stufe werden vor allem Gleichungen und Algorithmen auf Richtigkeit und Genauigkeit überprüft und ihre Ergebnisse mit den Erwartungen verglichen. Funktionalitätstests (2. Stufe): Im Gegensatz zur ersten Phase werden nun mehrere Einheiten, die miteinander verbunden sind, auf ihre korrekte Zusammenarbeit hin getestet. Subsystemtests (3. Stufe): Hier zeigt sich, ob die Software auch tatsächlich den Anforderungen gerecht wird. Die kleinen Einheiten aus Teststufe 2 werden zu kompletten Subsystemen zusammengefaßt und daraufhin überprüft, inwieweit sie ihre jeweilige Aufgabe (z.b. eine bestimmte Flugbahn zu halten) erfüllen. Systemtests (4. Stufe): In Stufe 4 wird die Zusammenarbeit des gesamten Systems getestet, d.h., Datentransfers, Schnittstellen zwischen den Computern etc. Releasetests (5. Stufe): Die letzte Testphase umfaßt die Erprobung des Systems, das in einen Hardwaremassenspeicher geladen wird, unter möglichst realen Bedingungen in einer Testeinrichtung der Nasa, um sicherzustellen, daß die ausgelieferte Software tatsächlich funktioniert. Weitere Details zum Testmodell in Abbildung Missionsabbruch im Notfall Für den Fall, daß es zu Störungen oder Unfällen kommt, die einen Missionsabbruch erforderlich machen, unterstützt PASS insgesamt fünf verschiedene Abbruchmodi, von denen je nach Zeitpunkt des Unglücks einer gewählt wird. Allerdings ist kein Abbruch möglich, bevor die beiden äußeren Feststoffbooster ausgebrannt sind.[5] Für Fehler direkt nach dem Start ist eine Rückkehr zur Basis vorgesehen. Nach dem Abbrennen und Abwerfen der Booster wird das Shuttle gewendet. Bald darauf wird auch der externe Tank abgeworfen, so daß die Raumfähre im Gleitflug die Landebahn des jeweiligen Raumfahrtzentrums ansteuern kann. Wenn eine Rückkehr nicht mehr möglich ist, das Shuttle aber nicht auf eine sichere Umlaufbahn gelangen kann, ist eine Atlantiküberquerung mit anschließender Landung in Spanien oder Marokko vorgesehen. Im Modus Abort to Orbit wird versucht, das Raumschiff auf eine sichere, niedrige Umlaufbahn zu bringen, wenn es z.b. durch Triebwerksausfall nicht mehr auf die ursprünglich geplante Umlaufbahn kommen kann. Dies ist der einzige Abbruchmodus, der jemals aktiviert wurde, und zwar als sich während des Fluges STS-51F eines der Haupttriebwerke vorzeitig abschaltete.

7 Abbildung 3. Testmodell der Shuttle-Software [12, S. 924] Als vierte Abbruchmöglichkeit (bei Leistungsabfall, Lecks in der Außenhaut etc.) ist eine einmalige Weltumrundung mit anschließender Landung in der Luftwaffenbasis Edwards oder dem Kennedy Space Center vorgesehen. In Notfällen, wenn weder eine stabile Umlaufbahn erreicht werden kann noch eine sichere Landung durchführbar ist, besteht zudem die sehr riskante Möglichkeit einer Notwasserung Überwachung von der Erde aus Das Mission Control Center Seit 1965 überwacht das Mission Control Center der NASA in Houston sämtliche bemannten Raumflüge der US- Amerikaner, so auch die der Shuttle-Flotte. Obwohl die Bordcomputer der Besatzung einen großen Teil der Überwachungsarbeit selbst übernehmen, ist das Kontrollzentrum nicht überflüssig, sondern stellt einen wichtigen Beitrag zur Sicherheit der Missionen dar. Da zwei funktional identische Kontrollräume existieren, ist es möglich, zwei Flüge gleichzeitig zu überwachen. Während einer Mission sitzen in einem dieser Räume etwa 20 bis 30 Flugüberwacher, die ständig durch Daten aus dem Shuttle über den Zustand der Bordsysteme und den Fortgang des Fluges informiert sind und zusammen mit der Besatzung größere Manöver planen oder versuchen, möglichst schnell auf unvorhergesehene Ereignisse zu reagieren. Einige der wichtigsten Kontrolleure sind (jeweils mit amerikanischen Titeln): Der Flight director, der das Team leitet und für den Ausgang der Mission im Ganzen und alle sicherheitskritischen Entscheidungen zuständig ist. Der Space communicator, der als Ansprechparter für die Astronauten dient. Der Data processing systems engineer, der insbesondere die fünf lebenswichtigen GPCs, die Fehler- und Ausfallanzeigen und flugkritische Daten überwacht. Der Guidance, navigation and control systems engineer, von dem alle Kurs-, Navigations- und Kontrollsysteme des Shuttles überwacht werden. Der Instrumentation and communications systems engineer, der alle während des Fluges benutzten Kommunikations-, Televisions- und Instrumentensysteme kontrolliert Die Zuverlässigkeit des Shuttle Ground System (SGS) Das SGS ist die Software, die die Mitarbeiter des Kontrollzentrums in Houston bei der Überwachung und Steue-

8 rung des Space Shuttles unterstützt. Dazu untersucht und verifiziert es jede Aktion der Bordcomputer und führt Analysen durch, die deren Kapazität weit überschreiten würden. Um das SGS zu testen, werden vorwiegend zwei Verfahren angewandt: Verifikationen, um die korrekte Funktionalität von Programmteilen nach Beseitigung von Fehlern oder Hinzufügung von Features zu überprüfen, und Missionssimulationen, in denen komplette Missionen oder Teile davon durchgespielt werden können. Zwar würde das Shuttle, dessen Arbeit von SGS überwacht wird, bei dessen Ausfall nicht sofort abstürzen wie etwa bei einem Totalausfall von PASS und BFS, doch wäre es in seiner Operationsfähigkeit eingeschränkt. Zuverlässigkeit ist daher auch beim SGS oberstes Gebot. Daß das SGS sicher arbeitet, legt Tabelle 4 nahe, die die Summe der in 38 Wochen aufgetretenen Fehler nach Schwere enthält, von denen nur sehr wenige kritisch sind. Allerdings wird im zugrundeliegenden Text [13], einer Zuverlässigkeitsanalyse, nicht genannt, wann genau die Untersuchung durchgeführt wurde und wie die Fehlerklassen definiert sind. Während des Zeitraums dieser Datenerfassung fanden auch die Missionen STS-2 und STS-3 statt, für die das SGS benutzt wurde und die ohne Komplikationen zu Ende gingen. Abbildung 4. Anzahl der aufgetretenen SGS- Fehler nach Kategorie [13, S. 265] 2.6. Verbesserungen der Computersysteme Die Entwicklung der Raumfähren begann 1972, der Erstflug fand 1981 statt. Seitdem sind viele kleine und große Änderungen am System vorgenommen worden. Zwei der wichtigsten werden im folgenden kurz vorgestellt. Gläsernes Cockpit [7]: Zur Jahrtausendwende hielt auch im Cockpit des Space Shuttle Atlantis moderne Digitaltechnik Einzug. Insgesamt 32 Instrumente und elektromechanische Anzeigen sowie vier Röhrenbildschirme konnten durch nur 11 flache Farbbildschirme ersetzt werden. Dadurch werden die Piloten nicht mehr mit sämtlichen Informationen gleichzeitig konfrontiert, sondern nur mit den momentan wichtigen. Auch dies ist ein Beitrag zur Zuverlässigkeit der Shuttles, denn wenn keine Gefahr mehr besteht, daß Piloten durch die Informationsflut zu falschen Entscheidungen angeleitet werden, erhöht sich damit auch die Sicherheit des Raumschiffs vor dem menschlichen Faktor. Als Nebeneffekt reduziert das neue Cockpit das Gesamtgewicht um 34 Kilogramm, so daß auch weniger Energie verbraucht wird. Bis 2002 wurden alle Raumfähren mit den neuen Cockpits ausgestattet, und weitere Verbesserungen sind in Vorbereitung. Global Positioning System (GPS) [6]: Zuverlässige und exakte Positionsbestimmung ist bei Weltraumflügen und - manövern von höchster Wichtigkeit. Bereits Mitte der 70er Jahre wurde ernsthaft in Betracht gezogen, das damals neue Global Positioning System in der Shuttleflotte einzusetzen. Die enormen Kosten und der Aufwand, das System zu integrieren, verhinderten dies aber und ließen die Entwickler auf schon vorhandene Lösungen zurückgreifen. Erst in den 90er Jahren griff man das Thema GPS wieder auf, weil die bisherigen Navigationssysteme veraltet waren und zu Beginn des neuen Jahrtausends ausgemustert werden sollten. Man entschied sich für einen GPS-Empfänger, der bereits für das US-Militär produziert wurde. Ein Hauptvorteil besteht darin, daß er Daten von einem Trägheitsnavigationssystem nutzen kann. Bei der Genauigkeit der Geschwindigkeitsbestimmung werden allerdings die Anforderungen des Mission Control Center verfehlt, die hinsichtlich Manöverplanung und Rendezvous z.b. mit der internationalen Raumstation (ISS) gestellt wurden, so daß GPS nur genutzt wird, während sich das Shuttle auf einer stabilen Umlaufbahn befindet und keine Andockmanöver durchführt. Für die Navigation beim Wiedereintritt in die Atmosphäre wird weiterhin das PASS genutzt, das parallel zu GPS arbeitet. Die Testflüge mit einer Vorversion des GPS-Empfängers begannen im Dezember 1993, und erst im August 2002 wurde der Empfänger nach Einbau und Flügen in den vier Raumfähren endgültig zertifiziert. Inzwischen sind die eingebauten GPS-Geräte, die den technischen Stand Anfang der 90er Jahre repräsentieren, auch überholt und könnten durch bessere Empfänger ersetzt werden, die z.b. auch bei Rendezvous genutzt werden können. Was zur Zeit eingesetzt wird, stellt also keinesfalls das Optimum an Sicherheit und Zuverlässigkeit dar.

9 2.7. Angewandte Konzepte aus der Informatik im Überlick Das Shuttle-Programm wurde vor über 30 Jahren begonnen, so daß heutige Standards in der Informatik noch unbekannt waren oder es keine befriedigenden Möglichkeiten gab, sie umzusetzen. Dies betrifft vor allem den Bereich des Software-Engineering, wo objektorientierte Programmierung oder formale Modellierung z.b. in UML, die heute in den allermeisten Projekten zum Einsatz kommen, damals weit weniger üblich waren, oder aber die Ergonomie der Mensch-Maschine-Schnittstelle (Cockpit), der erst mit dem Einbau des Glas-Cockpits Rechnung getragen wurde. Von den damals bekannten Möglichkeiten wurden aber etliche auch genutzt, wie insbesondere während der Beschreibung von Hard- und Softwarearchitektur der Shuttles deutlich geworden sein sollte (siehe 2.2,2.3). Was an Konzepten angewandt wurde, soll an dieser Stelle kurz zusammengefaßt werden: Hardware: bis zu vierfache Redundanz aller kritischen Systeme zur Überbrückung von Ausfällen Prüfsummen, Failure votes, Timeouts, Selbsttestprogramme zur Erkennung falsch rechnender GPCs; zweifache Überwachung (Shuttle und Kontrollzentrum) Software: Modularisierung, Datenkapselung, klare Programmstrukturierung inkl. ausführliche Dokumentation zur Fehlervermeidung bei der Entwicklung inkrementelles Testmodell, Langzeittests, formale Verifikaton im Anschluß an die Entwicklung spezielle Backup-Software zur Fehlerüberbrückung während des Einsatzes zweifache Überwachung (s.o.) 3. Zuverlässigkeit in der Praxis Wie beurteilt man die Zuverlässigkeit der Space Shuttles? Bei einem derart komplexen System kann man sicherlich nicht von Unzuverlässigkeit sprechen, wenn für wenige Sekunden eine einzelne unkritische Softwarekomponente ausfällt. Es bietet sich vielmehr an, die von der NASA als erfolgreich gewerteten Missionen als Maßstab zu nehmen. Demnach waren die Shuttles in 108 von 113 Einsätzen zuverlässig. Zwei der fünf nicht erfolgreichen Missionen endeten bekanntermaßen mit dem Verlust des Raumfahrzeugs und der Besatzung. Die anderen drei gescheiterten Einsätze waren STS-46, bei dem eine Führungsleine für einen Satelliten klemmte, so daß dieser nicht ausgesetzt werden konnte, sowie STS-2 und STS-83, bei denen Problemen mit den Treibstofftanks auftraten [9]. Insgesamt ergibt sich eine Zuverlässigkeitsquote von 95, 6%. Vergleichen wir diesen Wert mit den insgesamt 17 bemannten Missionen des vorangegangenen Apollo- Programms. Apollo 1 und 13 scheiterten - bei Apollo 1 brach vor dem Start ein Feuer an Bord der Raumkapsel aus und tötete die Besatzung, Apollo 13 mußte nach zahlreichen Systemausfällen zur Erde zurückkehren und notwassern. Die Zuverlässigkeit beträgt bei 15 erfolgreichen Flügen 88, 2%. Bei gleicher Zuverlässigkeit wären von den insgesamt 113 Missionen nur 100 erfolgreich verlaufen. Somit stellt das Space Shuttle in Sachen Zuverlässigkeit und Sicherheit einen Sprung nach vorn da, wenngleich natürlich auch eine Zuverlässigkeit von 95, 6% für die zivile Luftfahrt völlig indiskutabel ist. Im Folgenden wollen wir uns noch mit den beiden tödlich verlaufenen Abstürzen, ihren Ursachen und ihren Konsequenzen beschäftigen. Das erste Unglück - die Explosion der Challenger am 28. Januar ereignete sich nicht etwa wegen eines Computerausfalls, sondern weil eine Dichtung am rechten Feststoffbooster Treibstoff austreten ließ, der sich an den Triebwerksstrahlen entzündete und eine Kettenreaktion auslöste, so die Schlußfolgerung der Untersuchungskommission [14]. Das Bauteil, das den Verlust eines viele Millionen Dollar teuren Raumschiffs verursachte, war also zugleich eines der einfachsten und billigsten. Als Folge dieses Unglücks wurden zahlreiche Veränderungen angemahnt und weitestgehend umgesetzt, um die Sicherheit der Shuttles und der Besatzungen zu gewährleisten. So wird ein neues Design für die Feststoffbooster verlangt, wobei explizit erwähnt wird, daß die NASA alle Scharniere, Dichtungen und Ventile vorher vollständig verstehen (sic!) und testen sollte. Daß eine derartige Selbstverständlichkeit explizit in einem offiziellen Bericht erwähnt wird, wirft kein gutes Licht auf die Arbeit der zuständigen Ingenieure. Ansonsten werden insbesondere die zu geringen Abstände zwischen einzelnen Flügen gerügt und ebenso die Praxis, bei Bedarf Teile von einem Shuttle zu entfernen und sie in ein anderes einzubauen. Das zweite Unglück geschah beim Wiedereintritt der Raumfähre Columbia in die Atmosphäre am 1. Februar Die diesbezüglich eingesetzte Untersuchungskommission [15] ermittelte als Auslöser des Absturzes ein etwa 750g schweres Schaumstoffteil, das vom Außentank abgerissen war und mit über 250 m s gegen die linke Tragfläche des Shuttles prallte. Dadurch wurden einige Kacheln

10 des Hitzeschutzschildes beschädigt, so daß der betroffene Teil der Raumfähre beim Eintritt in die Atmosphäre der extrem großen Reibungshitze ungeschützt ausgesetzt war. Infolge dessen wurde die Struktur der Columbia so stark beschädigt, daß diese auseinanderbrach und verglühte. Hier stellt sich die Frage, ob das Unglück nicht durch eine bessere Videoüberwachung des Fluges hätte verhindert werden können, wie sie auch von der Kommission empfohlen wird. Hätte man den Aufprall des Schaumstoffs 82 Sekunden nach dem Start sofort gesehen, hätte man einen sofortigen Missionsabbruch anordnen können (2.4). Wäre die Beschädigung des Hitzeschildes rechtzeitig erkannt worden, wäre es u.u. möglich gewesen, binnen weniger Tage ein zweites Shuttle hinterherzuschicken, um die Besatzung der Columbia ggf. zu evakuieren. (Wie in ausgeführt, kann das Kontrollzentrum zwei Flüge gleichzeitig überwachen.) Dies alles ist jedoch nicht geschehen - mit den allgemein bekannten Folgen. Unter anderem dürfte dabei die finanzielle Not der NASA eine Rolle gespielt haben, die - wie die Kommission findet [15] - mit sinkendem Budget immer mehr Projekte koordinieren muß (siehe Abbildung 5). Bei beiden Abstürzen fällt also auf, daß nicht hochkomplizierte Bauteile oder das hier vorgestellte Computersystem ihren Dienst versagt haben. Vielmehr waren es einfache, billige Komponenten, nämlich eine Dichtung und ein Stück Schaumstoff. Daß es in bislang 113 Flügen keinen kritischen Hard- oder Softwareausfall gab, der einen Missionsabbruch erforderlich gemacht oder die Besatzung in Gefahr gebracht hätte, läßt auf eine hohe Zuverlässigkeit der Systeme schließen. Hingegen scheint es bei Wartung und Überwachung gravierende Mängel gegeben haben, die inzwischen beseitigt sein sollten. 4. Zusammenfassung Wir haben aus der Sicht eines Informatikers untersucht, wie die für die Space Shuttles verantwortlichen Ingenieure die an Hardware, Software und Ergonomie gestellten Anforderungen bewältigt haben und möglichen Fehlern und Gefahren begegnet sind, um einen Flug mit einer der Raumfähren so sicher wie möglich zu machen. Wir haben gesehen, daß schon während der Entwicklung der Raumfähren, als es noch keine PCs gab, zahlreiche Techniken angewandt wurden, wie sie noch heute in Theorie und Praxis üblich sind. Und die Tatsache, daß noch nie eine Mission aufgrund defekter Rechner oder Programme fehlgeschlagen ist, zeigt, daß die beteiligten Informatiker ihren Beitrag zur Sicherheit der Shuttles erfolgreich geleistet haben. Jedoch scheint es, wie insbesondere die beiden tragischen Abstürze zeigen, an anderen Stellen, die wir aufgrund unseres Schwerpunktes nur am Rande betrachtet haben, erhebliche Defizite gegeben zu haben oder immer noch zu geben. Insgesamt kann man also nicht von einem rundrum sicheren System sprechen, wie es die NASA sich vorgestellt hatte. In finanzieller Hinsicht sind die wiederverwendbaren Raumfähren sogar ein Desaster. Schließlich sind die Kosten pro Flug von ehemals geplanten 10 bis 20 Mio. Dollar auf rund 500 Mio. gestiegen [9], obwohl es auch Ziel der NASA war, ein günstiges System zu entwickeln. Und die Flexibilität ist geringer als ursprünglich vorgegeben, weil nicht zuletzt durch die Unglücke die Wartungsintervalle zwischen den Einsätzen drastisch angestiegen sind. Nur aus wissenschaftlicher Sicht, auch in Anbetracht der vielen geglückten Experiment an Bord der Raumfähren, ist die bisherige Geschichte der Space Shuttles als sehr erfolgreich anzusehen. Literatur [1] James E. Tomayko et al., NASA Contractor Report : Computers in Spaceflight. The NASA Experience, NASA, März [2] J. R. Sklaroff, Redundancy Management Technique for Space Shuttle Computers, IBM Journal of Research and Development, Ausg.: Januar 1976, S. 20ff. [3] Paul Schneck, Architecture of the Space Shuttle Primary Avionics Software System, Communications of the ACM, Vol. 27, Nr. 9, September 1984, S. 926ff. Abbildung 5. Prozentualer Anteil der NASA- Gelder am US-Bundeshaushalt [15] [4] NASA Office of Logic Design 504/contents.htm, NASA SP-504, Space Shuttle Avionics System, aktualisiert: 16. März 2004, zuletzt besucht: 28. November 2004, Kontakt:

11 [5] NSTS Shuttle Reference Manual, NASA, 1988, Kontakt: Jim Dumoulin [6] John L. Goodman, A GPS Receiver Upgrade For The Space Shuttle - Rationale And Considerations, 40th AIAA/ASME/SAE/ASEE Joint Propulsion Conference and Exhibit, Fort Lauderdale, Florida, Juli [7] The 21st Century Space Shuttle, aktualisiert: 4. Juli 2002, zuletzt besucht: 30. Oktober 2004, Kontakt: John Ira Petty (HSFWeb- [8] Alfred Spector und David Gifford, The Space Shuttle Primary Computer System, Communications of the ACM, Vol. 27, Nr. 9, S. 874ff, September [9] Shuttle program, Space Shuttle program - Wikipedia, the free encyclopedia, aktualisiert: 29. Oktober 2004, letzter Besuch: 30. Oktober [10] HAL/S - Wikipedia, the free encyclopedia, aktualisiert: 3. September 2004, letzter Besuch: 30. Oktober [11] Autor unbekannt, STS-107, Report # 21, NASA, 3. Februar [12] William A. Madden und Kyle Y. Rone Design, Development, Integration: Space Shuttle Primary Flight Software System, Communications of the ACM, Vol. 27, Nr. 9, S. 914ff., September [13] P. N. Misra Software Reliability Analysis, IBM Systems Journal, Vol. 22, Nr. 3, [14] The Presidential Commission on the Space Shuttle Challenger Accident Report to the President, Vorsitzender: William P. Rogers, 1986/87. [15] Columbia Accident Investigation Board Report Volumes I - VI, Vorsitzender: Admiral Hal Gehman, letzter Besuch: 27. Januar 2005 Oktober [16] K. Echtle Fehlertoleranzverfahren, Springer Verlag, 1990, Kap. 1.

Software Engineering I Prof. Dr. Martin Glinz. Fallstudie: Ariane Flug 501. Universität Zürich Institut für Informatik

Software Engineering I Prof. Dr. Martin Glinz. Fallstudie: Ariane Flug 501. Universität Zürich Institut für Informatik Software Engineering I Prof. Dr. Martin Glinz Fallstudie: Ariane Flug 501 Universität Zürich Institut für Informatik Was geschah mit Flug 501? So hätte es aussehen sollen......und so sah es tatsächlich

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

Mehr

Welche Zukunft hat die bemannte Raumfahrt?

Welche Zukunft hat die bemannte Raumfahrt? Welche Zukunft hat die bemannte Raumfahrt? Gast: Alexander Gerst Mehr als fünf Monate lebte Alexander Gerst im Weltall auf der ISS. Wie verändert einen Menschen solch eine Weltraumerfahrung? Brauchen wir

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Anleitung zur Verwendung des Ruhezustandes Unter Windows 7:

Anleitung zur Verwendung des Ruhezustandes Unter Windows 7: Anleitung zur Verwendung des Ruhezustandes Unter Windows 7: Wenn Sie mit Windows Vista oder Windows 7 arbeiten, so werden Sie schon oft festgestellt haben, dass das Hochfahren des Betriebssystems einige

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

Das Handbuch zu KCM Tablet. Jörg Ehrichs Übersetzung: Burkhard Lück

Das Handbuch zu KCM Tablet. Jörg Ehrichs Übersetzung: Burkhard Lück Jörg Ehrichs Übersetzung: Burkhard Lück 2 Inhaltsverzeichnis 1 Wacom-Tablett-Einstellungen 5 1.1 Profilverwaltung...................................... 5 1.2 Allgemeine Tablett-Einstellungen und -Informationen.................

Mehr

Programmieren was ist das genau?

Programmieren was ist das genau? Programmieren was ist das genau? Programmieren heisst Computerprogramme herstellen (von griechisch programma für Vorschrift). Ein Computerprogramm ist Teil der Software eines Computers. Als Software bezeichnet

Mehr

6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ

6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ 6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ 6HKUJHHKUWH6RIW&OHDQ $QZHQGHU LQ XQVHUHP 6RIW&OHDQ 8SGDWHV 'RZQORDGEHUHLFK ILQGHQ 6LH ]ZHL $UWHQ YRQ 8SGDWHV 1DFKIROJHQGHUIDKUHQ6LHZHOFKHV8SGDWHI U6LHGDVULFKWLJHLVWXQGZLH6LHGDV8SGDWHDXI,KUHP$UEHLWVSODW]GXUFKI

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Betriebssysteme K_Kap11C: Diskquota, Raid

Betriebssysteme K_Kap11C: Diskquota, Raid Betriebssysteme K_Kap11C: Diskquota, Raid 1 Diskquota Mehrbenutzer-BS brauchen einen Mechanismus zur Einhaltung der Plattenkontingente (disk quotas) Quota-Tabelle enthält Kontingenteinträge aller Benutzer

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

IT Storage Cluster Lösung

IT Storage Cluster Lösung @ EDV - Solution IT Storage Cluster Lösung Leistbar, Hochverfügbar, erprobtes System, Hersteller unabhängig @ EDV - Solution Kontakt Tel.: +43 (0)7612 / 62208-0 Fax: +43 (0)7612 / 62208-15 4810 Gmunden

Mehr

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 9. Vorlesung 1 Pläne Kein Plan überlebt die erste Feindberührung - Feldmarschall Helmuth von Moltke Prognosen sind schwierig, besonders wenn sie die Zukunft

Mehr

Patchbericht zum Patch V1.1

Patchbericht zum Patch V1.1 Patchbericht zum Patch V1.1 Der Patch 1.1 hatte gleich mehrere Funktionen zu vollbringen. So wurde den Wünschen der Fans nach weiteren Features Rechnung getragen. Was für Features hinzugekommen sind, können

Mehr

Ein kleines Computer-Lexikon

Ein kleines Computer-Lexikon Stefan Edelmann 10b NIS-Klasse Ein kleines Computer-Lexikon Mainboard Die Hauptplatine! Sie wird auch Motherboard genannt. An ihr wird das gesamte Computerzubehör angeschlossen: z.b. Grafikkarte Soundkarte

Mehr

Vorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13.

Vorlesung Verteilte Systeme Sommersemester 1999. Verteilte Systeme. 13. Fehlertoleranz. Verteilte Systeme, Sommersemester 1999 Folie 13. Verteilte Systeme 13. Fehlertoleranz Motivation Kunde () Verteiltes System = Redundanz Rechnern Kommunikationsnetzen Grundidee Einzelne Komponente k fällt mit einer Wahrscheinlichkeit p aus Ausfallwahrscheinlichkeit

Mehr

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13 Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen?

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Umgebung Getestet wurde auf einem Linux-System mit voller invis-server Installation, auf dem eine virtuelle Maschine

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Handbuch Version 1.02 (August 2010)

Handbuch Version 1.02 (August 2010) Handbuch Version 1.02 (August 2010) Seite 1/27 Inhaltsverzeichnis 1. Einleitung 1.1. Begrüßung 03 1.2. Was ist PixelX Backup FREE / PRO 03 1.3. Warum sollten Backups mittels einer Software erstellt werden?

Mehr

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11 Datenbanksysteme WS 05/ 06 Gruppe 12 Martin Tintel Tatjana Triebl Seite 1 von 11 Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 3 2. Datenbanken... 4 2.1. Oracle... 4 2.2. MySQL... 5 2.3 MS

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Testdokumente Semesterarbeit von: Juli 2005 Mobile Data Monitor Seite 71 / 106 5.3 Testing Folgende Tests wurden durchgeführt.

Mehr

FACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen

FACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen FACHARTIKEL 2013 Software Programmierung, Testing und Implementierung zum Stichtag mithilfe von PERM-Domänen von Herbert Mittelbach Stichtage Von Herbert Mittelbach Stichtage haben stets eine besondere

Mehr

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Dipl.-Ing. Michael

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

KAPITEL 4: FALLSTUDIE DDOS-ANGRIFF AUF EINE WEBANWENDUNG DER GLOBAL THREAT INTELLIGENCE REPORT 2015 :: COPYRIGHT 2015 NTT INNOVATION INSTITUTE 1 LLC

KAPITEL 4: FALLSTUDIE DDOS-ANGRIFF AUF EINE WEBANWENDUNG DER GLOBAL THREAT INTELLIGENCE REPORT 2015 :: COPYRIGHT 2015 NTT INNOVATION INSTITUTE 1 LLC KAPITEL 4: FALLSTUDIE DDOS-ANGRIFF AUF EINE WEBANWENDUNG 1 DDOS-ANGRIFF AUF EINE WEBANWENDUNG LEHRE AUS DER FALLSTUDIE Im Falle eines Angriffs zahlt sich eine DoS-/DDoS-Abwehrstrategie aus. SZENARIO Das

Mehr

Verteilte Systeme F. Fehlertoleranz

Verteilte Systeme F. Fehlertoleranz Verteilte Systeme F. Fehlertoleranz Fachbereich Elektrotechnik und Informationstechnik Verteilte Systeme, Seite F.1 Fehlertoleranz Abhängigkeiten in einem verteilten System: Client! Server! Dienste! Software!

Mehr

und von mehreren PCs nutzen Nr. 070101

und von mehreren PCs nutzen Nr. 070101 Was ist denn eigentlich dieser SComm-Treiber? Der Saia Communication Driver kurz SComm-Treiber dient verschiedenen Programmen der Saia PG5 (z.b. Online Configurator, Debugger, Fupla, SEdit, Watch Window

Mehr

Softwarequalität: Einführung. 15. April 2015

Softwarequalität: Einführung. 15. April 2015 Softwarequalität: Einführung 15. April 2015 Überblick Warum ist Softwarequalität wichtig? Was ist Softwarequalität? Wie erreicht man Softwarequalität? Taentzer Softwarequalität 2015 8 Berühmte Software-Fehler

Mehr

Code-Quality-Management

Code-Quality-Management Code-Quality-Management Technische Qualität industrieller Softwaresysteme transparent und vergleichbar gemacht von Frank Simon, Olaf Seng, Thomas Mohaupt 1. Auflage Code-Quality-Management Simon / Seng

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Objektorientiertes Programmieren für Ingenieure

Objektorientiertes Programmieren für Ingenieure Uwe Probst Objektorientiertes Programmieren für Ingenieure Anwendungen und Beispiele in C++ 18 2 Von C zu C++ 2.2.2 Referenzen und Funktionen Referenzen als Funktionsparameter Liefert eine Funktion einen

Mehr

Einleitung 3. App Ideen generieren 4. Kopieren vorhandener Apps 4. Was brauchen Sie? 5. Outsourcing Entwicklung 6

Einleitung 3. App Ideen generieren 4. Kopieren vorhandener Apps 4. Was brauchen Sie? 5. Outsourcing Entwicklung 6 Inhaltsverzeichnis Einleitung 3 App Ideen generieren 4 Kopieren vorhandener Apps 4 Was brauchen Sie? 5 Outsourcing Entwicklung 6 Software und Dienstleistungen für Entwicklung 8 Vermarktung einer App 9

Mehr

QCfetcher Handbuch. Version 1.0.0.10. Ein Zusatztool zum QuoteCompiler. Diese Software ist nur für private und nicht-kommerzielle Zwecke einzusetzen.

QCfetcher Handbuch. Version 1.0.0.10. Ein Zusatztool zum QuoteCompiler. Diese Software ist nur für private und nicht-kommerzielle Zwecke einzusetzen. Seite 1 QCfetcher Handbuch Ein Zusatztool zum QuoteCompiler Diese Software ist nur für private und nicht-kommerzielle Zwecke einzusetzen. Die neuesten Informationen gibt es auf der Webseite: http://finanzkasper.de/

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

CS Software GmbH - Schiersteiner Strasse 31-65187 Wiesbaden - Tel.: 0611/ 890 85 33 - Fax 0611/ 890 85 56

CS Software GmbH - Schiersteiner Strasse 31-65187 Wiesbaden - Tel.: 0611/ 890 85 33 - Fax 0611/ 890 85 56 2010 CS Software GmbH - Schiersteiner Strasse 31-65187 Wiesbaden - Tel.: 0611/ 890 85 33 - Fax 0611/ 890 85 56 Wohin rollst Du, Tandemchen? Oder: NonStop: The Good, the Bad, the Weird CS Software GmbH

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter Referat Extreme Programming Von Irina Gimpeliovskaja und Susanne Richter 1.) Was ist XP? Überlegte Annäherung an Softwareentwicklung Prozessmodell für objektorientierte Softwareentwicklung erfordert gute

Mehr

Überwachen von Monitoring-Stationen mit R&S ARGUS SIS

Überwachen von Monitoring-Stationen mit R&S ARGUS SIS Überwachen von Monitoring-en mit R&S ARGUS SIS Ist bei den unbemannten Monitoring-en alles in Ordnung? Diese Frage, die sich den Verantwortlichen für Monitoring-Netze immer wieder stellt, beantwortet das

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Mindtime Online Backup

Mindtime Online Backup Mindtime Online Backup S e r v i c e L e v e l A g r e e m e n t Inhaltsangabe Service Definition... 3 1) Datenverschlüsselung... 3 2) Gesicherte Internetverbindung... 3 3) Datencenter... 4 4) Co- Standort...

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Software und die Folgen. Softwarefehler Update Upgrade. Hardware Software. Serviceverträge Warum Sie profitieren!

Software und die Folgen. Softwarefehler Update Upgrade. Hardware Software. Serviceverträge Warum Sie profitieren! Software und die Folgen Softwarefehler Update Upgrade Hardware Software Serviceverträge Warum Sie profitieren! Eine kleine Lektüre zum Nachdenken über die optimale Systemnutzung copyright@abacus-systemberatung2005

Mehr

Modes And Effect Analysis)

Modes And Effect Analysis) Gefahrenanalyse mittels FMEA (Failure Modes And Effect Analysis) Vortragender: Holger Sinnerbrink Betreuer: Holger Giese Gefahrenanalyse mittels FMEA Holger Sinnerbrink Seite: 1 Gliederung Motivation Einordnung

Mehr

INDUSTRIE 4.0. Sind Sie gewappnet für die nächste industrielle Revolution? Vortragsprotokoll Handelskammer Bremen 25. Februar 2015

INDUSTRIE 4.0. Sind Sie gewappnet für die nächste industrielle Revolution? Vortragsprotokoll Handelskammer Bremen 25. Februar 2015 INDUSTRIE 4.0 Sind Sie gewappnet für die nächste industrielle Revolution? Vortragsprotokoll Handelskammer Bremen 25. Februar 2015 LECLERE SOLUTIONS 2015 Protokoll vom 25.2.2015 1 Ablauf der Veranstaltung!

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

VIS 5. Elektronische Verwaltung so einfach wie nie. www.vis5.de

VIS 5. Elektronische Verwaltung so einfach wie nie. www.vis5.de VIS 5 Elektronische Verwaltung so einfach wie nie. www.vis5.de 2 Liebe auf den ersten Klick. Das neue VIS 5 einfach, leicht und schnell. Wenn die elektronische Verwaltungsarbeit Spaß macht, schafft das

Mehr

Tinytag Funk- Datenlogger- Software

Tinytag Funk- Datenlogger- Software Tinytag Funk- Datenlogger- Software Seite: 1 Tinytag Funk- Datenlogger- Software Tinytag Explorer ist die Windows- basierte Software zum Betrieb eines Tinytag Funk- Systems. Die Anwender können ihre Daten

Mehr

Sicherheit & Zuverlässigkeit

Sicherheit & Zuverlässigkeit Fakultät Elektrotechnik & Informationstechnik Institut für Automatisierungstechnik, Professur für Prozessleittechnik Sicherheit & Zuverlässigkeit Einführung VL PLT-2 Professur für Prozessleittechnik Übersicht

Mehr

Software Engineering Vorlesung für Medieninformatik

Software Engineering Vorlesung für Medieninformatik Software Engineering Vorlesung für Medieninformatik Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Das Degaussen Hintergründe und Produktinformationen

Das Degaussen Hintergründe und Produktinformationen Das Degaussen Hintergründe und Produktinformationen Was bedeutet Degaussen? Computerfestplatten benutzen Magnetfelder um Daten auf speziellen Scheiben, den sogenannten Platters, zu speichern. Beim Degaussen

Mehr

Spielregeln (die Vollversion mit den Optionen)

Spielregeln (die Vollversion mit den Optionen) Spielregeln (die Vollversion mit den Optionen) Ziel des Spiels Plyt Herausforderungen Spieler richtig multiplizieren (oder hinzufügen) eine Anzahl von Würfeln zusammen und Rennen entlang der Strecke der

Mehr

Kundeninformation Stand: Dezember 2014 Aktualisierung der ADDISON Software - Stand 3/2014

Kundeninformation Stand: Dezember 2014 Aktualisierung der ADDISON Software - Stand 3/2014 Kundeninformation Stand: Dezember 2014 Aktualisierung der ADDISON Software - Stand 3/2014 Information zu den, die wir für Sie mit dieser Aktualisierung vorgenommen haben. Die Installation der Aktualisierung

Mehr

Installation LehrerConsole (für Version 7.2)

Installation LehrerConsole (für Version 7.2) Dr. Kaiser Systemhaus GmbH Köpenicker Straße 325 12555 Berlin Telefon: (0 30) 65 76 22 36 Telefax: (0 30) 65 76 22 38 E-Mail: info@dr-kaiser.de Internet: www.dr-kaiser.de Installation LehrerConsole (für

Mehr

Die Mikroprogrammebene eines Rechners

Die Mikroprogrammebene eines Rechners Die Mikroprogrammebene eines Rechners Das Abarbeiten eines Arbeitszyklus eines einzelnen Befehls besteht selbst wieder aus verschiedenen Schritten, z.b. Befehl holen Befehl dekodieren Operanden holen etc.

Mehr

(früher: Double-Take Backup)

(früher: Double-Take Backup) (früher: Double-Take Backup) Eine minutengenaue Kopie aller Daten am Standort: Damit ein schlimmer Tag nicht noch schlimmer wird Double-Take RecoverNow für Windows (früher: Double-Take Backup) sichert

Mehr

Kurzanleitung. MEYTON Migrationstool. 1 Von 16

Kurzanleitung. MEYTON Migrationstool. 1 Von 16 Kurzanleitung MEYTON Migrationstool 1 Von 16 Inhaltsverzeichnis Sinn und Zweck des Migrationsprogramms...3 Die LIVE C D...3 START...3 Erste Schritte...4 Login...4 Einleitung...5 Die Bedienung...5 Das Hauptmenü...6

Mehr

RAID Redundant Array of Independent [Inexpensive] Disks

RAID Redundant Array of Independent [Inexpensive] Disks RAID Redundant Array of Independent [Inexpensive] Disks Stefan Wexel Proseminar Algorithms and Data Structures im WS 2011/2012 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik

Mehr

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren

- Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte. Version: 1.0. Nicole Scheeren - Planung und Steuerung: Risikoliste - Code-Generator für die Erstellung einer Lebenslaufakte Version: 1.0 Projektbezeichnung Projektleiter Verantwortlich Erstellung einer Lebenslaufakte Nicole Scheeren

Mehr

Marathon everrun TM Was kommt nach den Clustern? Abschätzung geschäftlicher Auswirkungen Die wahren Ausfallkosten

Marathon everrun TM Was kommt nach den Clustern? Abschätzung geschäftlicher Auswirkungen Die wahren Ausfallkosten Abschätzung geschäftlicher Auswirkungen Die wahren Ausfallkosten Produktivität Anzahl betroffener Mitarbeiter x Ausfalldauer x Arbeitsplatzkosten Produktionsstörungen Erträge Direkte Verluste Entschädigungszahlungen

Mehr

Mehr Erfolg für Ihre Projekte

Mehr Erfolg für Ihre Projekte Mehr Erfolg für Ihre Projekte 2007.Martin Moss Infopaper V2.3 / Seite 1 Projekte erfolgreicher abschließen Ihre Herausforderung Unsere Lösung Trotz bewährter methoden liefern 70 90% aller Projekte, nicht

Mehr

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015 Migrationsstrategien Dr. Thorsten Arendt Marburg, 22. Januar 2015 Re-Engineering Patterns [Demeyer et al.] 2 Software-Evolution WS 2014/2015 Überblick Probleme Wenn man ein bestehendes System re-engineered

Mehr

Verwendung der Report-Funktion in der ArtemiS SUITE (ab Version 5.0)

Verwendung der Report-Funktion in der ArtemiS SUITE (ab Version 5.0) Verwendung der (ab Version 5.0) In der ArtemiS SUITE steht eine neue, sehr flexible Reporting-Funktion zur Verfügung, die mit der Version 5.0 noch einmal verbessert wurde. Die vorliegende beschreibt den

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

Fault-Konzepte Fehlermana Fehl gement in ermana Rechnernetzen Rechne Christian Stroh

Fault-Konzepte Fehlermana Fehl gement in ermana Rechnernetzen Rechne Christian Stroh Fault-Konzepte Fehlermanagement in Rechnernetzen Übersicht 1. Rückblick auf FCAPS (Netzwerkmanagement) und SNMP (Netzwerkprotokoll) 2. Fehlermanagement (Definition, Struktur) 3. Fehlerbehandlung -Fehlererkennung

Mehr

Hinweis 1781277 - B2A: Fehlersuche BusinessConnector LStA, LStB, ELStAM

Hinweis 1781277 - B2A: Fehlersuche BusinessConnector LStA, LStB, ELStAM Hinweissprache: Deutsch Version: 1 Gültigkeit: gültig seit 29.10.2012 Zusammenfassung Symptom Der Hinweis bezieht sich auf die Lohnsteueranmeldung(LStA), Lohnsteuerbescheinigung(LStB) und die elektronische

Mehr

Quality Point München

Quality Point München Quality Point München Test webbasierter Applikationen - Vorgehen, Instrumente, Probleme Gestern habe ich mich wieder über eine fehlerhafte Webanwendung geärgert. Muss das sein? Test ist halt auch hier

Mehr

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung

Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Nichtfunktionaler Abnahmetest: Planung, Durchführung und Automatisierung Uwe Hehn TAV Februar 2005 Hochschule Bremen Uwe.Hehn@methodpark.de Abnahmetest: Warum brauchen wir denn so etwas? Projektabnahme

Mehr

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht.

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht DRESDEN Ermitteln von Sprunghöhen mit einem Windows Phone Felix Guttbier Schule: Gymnasium Brandis Jugend forscht 2014 ERMITTELN VON SPRUNGHÖHEN

Mehr

Einführung in Automation Studio

Einführung in Automation Studio Einführung in Automation Studio Übungsziel: Der links abgebildete Stromlaufplan soll mit einer SPS realisiert werden und mit Automation Studio programmiert werden. Es soll ein Softwareobjekt Logik_1 in

Mehr

Datensicherungskonzept Westfälische Hochschule

Datensicherungskonzept Westfälische Hochschule Datensicherungskonzept Westfälische Hochschule -ZIM- Rev. 1.00 Stand: 04.04.2014 Revisionsstände Revisionsstand Kommentar 1.00 Erste Version Seite 2 1 Einleitung Das Datensicherungskonzept dient zur Dokumentation

Mehr

Wurde eine Sammlung Werte übermittelt, so wird der örtliche Speicher des jeweiligen Moduls gelöscht und die Speicherung beginnt aufs Neue.

Wurde eine Sammlung Werte übermittelt, so wird der örtliche Speicher des jeweiligen Moduls gelöscht und die Speicherung beginnt aufs Neue. Um die Qualitätssicherung weiter zu verfeinern, wurde ein Modul entwickelt, welches die gemessenen Ölwerte während der Betriebszeit der Fritteuse kontinuierlich sammelt und diese dann auf Wunsch als E

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

MiniGPS. für X-Plane 10.32

MiniGPS. für X-Plane 10.32 MiniGPS für X-Plane 10.32 Version 1.2 by oe3gsu Inhalt: 1. Allgemein... 3 2. Installation... 3 3. Anzeigen... 3 3.1. Display minimieren... 4 3.2. Display verschieben... 4 3.3. Modus ändern... 5 3.4. Heading-Difference...

Mehr

Datenübernahme easyjob 3.0 zu easyjob 4.0

Datenübernahme easyjob 3.0 zu easyjob 4.0 Datenübernahme easyjob 3.0 zu easyjob 4.0 Einführung...3 Systemanforderung easyjob 4.0...3 Vorgehensweise zur Umstellung zu easyjob 4.0...4 Installation easyjob 4.0 auf dem Server und Arbeitsstationen...4

Mehr

Verschlüsselungsverfahren

Verschlüsselungsverfahren Verschlüsselungsverfahren Herrn Breder hat es nach dem Studium nach München verschlagen. Seine Studienkollegin Frau Ahrend wohnt in Heidelberg. Da beide beruflich sehr stark einspannt sind, gibt es keine

Mehr

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim Test- Grundsätzliches - - - Ablauf von Tests Grundsätzliche Test- -Tests Äquivalenzklassenbildung Randwertanalyse -Tests Man unterscheidet verschiedene Überdeckungsgrade: Statement Coverage Decision Coverage,

Mehr

visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation

visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation visionapp Platform Management Suite Save Event Version 2.0 Technische Dokumentation Copyright visionapp GmbH, 2002-2006. Alle Rechte vorbehalten. Die in diesem Dokument enthaltenen Informationen, Konzepte

Mehr