ZDB direkt Zuse 2005.pdf - Zentralverband Deutsches Baugewerbe

Direkt
Aktuelles vom Deutschen Baugewerbe.
2005
Sonderausgabe
Ein Bau-Produktmodell als Schlüssel
zur Software-Integration
Seite 6 – 8
Konrad Zuses
wissenschaftliches Werk
Seite 11 – 14
Konrad-Zuse-Medaille
des Zentralverbandes
des Deutschen
Baugewerbes
Laudatio für den Preisträger 2005
Seite 3 – 5
Mein Weg zu den
Bau-Produktmodellen
Seite 9 – 10
2005

2
Impressum:
V.i.S.d.P.:
Dr. Ilona K. Klein
Redaktion:
Carin Hollube
Fotos: Flughafen München
GmbH, ZDB.
Zentralverband des
Deutschen Baugewerbes,
Kronenstraße 55-58,
10117 Berlin-Mitte,
Telefon 030 / 20314-408,
Fax 030 / 20314-420,
eMail: presse@zdb.de
Zur Bedeutung der Konrad-Zuse-
Medaille für die Bauwirtschaft
Sehr geehrte Damen und Herren,
liebe Leserinnen und Leser,
diese Sonderausgabe unserer Zeitschrift ZDB-Direkt ist der Verleihung
der Konrad-Zuse-Medaille 2005 in Berlin gewidmet.
In zweierlei Hinsicht war dies eine Premiere. Nach langer Zeit wurde die
Konrad-Zuse-Medaille des ZDB wieder im Rahmen des Deutschen Baugewerbetages
verliehen und zum ersten Mal in Berlin.
Berlin ist eng mit Konrad Zuse verbunden. Hier studierte er von 1928 bis
1934 an der Technischen Hochschule Charlottenburg und legte 1935
sein Diplom – Hauptexamen zum Bauingenieur ab.
Zuse wird auf der ganzen Welt als Schöpfer des ersten programmgesteu-
erten und frei programmierbaren Rechners anerkannt. Diese Maschine
– Z3 genannt – vollendete er 1941 in seiner Werkstatt in Kreuzberg.
Mit der Verleihung der Konrad-Zuse-Medaille auf dem Deutschen Baugewerbetag
2005 spiegelt sich auch die Wertschätzung des Verbandes
für die Leistungen von Konrad Zuse wider. Diese Wertschätzung ist
angesichts der Potenziale, die die von Konrad Zuse angestoßene elektronische
Datenverarbeitung für die Bauwirtschaft hat, keine gepflegte
Nostalgie sondern hochaktuell.
Konrad Zuse ist gerade in dieser Zeit ein Vorbild. Er hat gegen vielerlei
Widerstände zielstrebig an der Umsetzung seiner Ideen bis zu deren
praktikabler Anwendung gearbeitet.
Bundespräsident Roman Herzog formulierte es bei der Vergabe des
Großen Verdienstkreuzes des Verdienstordens der Bundesrepublik mit
Stern und Schulterband 1995 an Konrad Zuse so:
„Trotz widriger Umstände – da war der Krieg, der Sie behinderte, da
war das Patentamt, das Ihre Erfindung nicht anerkannte – haben Sie
Ihre Ziele weiter verfolgt .... Hochachtung schließlich dafür, dass Sie
drei Dinge zusammengeführt haben: erstens die Idee, nämlich die des
programmierten Rechenautomaten, zweitens die Entwicklung zu einer
praktikablen Umsetzung, drittens die unternehmerische Nutzung.“
Der ZDB beabsichtigt, künftig regelmäßig die Konrad-Zuse-Medaille im
Rahmen des Deutschen Baugewerbetages zu verleihen. Dies ist ein würdiger
Rahmen, Persönlichkeiten zu ehren, die sich auf dem Gebiet der
Informatik im Bauwesen in hervorragender Weise ausgewiesen haben.
Ihr

Konrad-Zuse-Medaille 2005
Mit der Verleihung
der Konrad Zuse
Medaille ehrt der
Zentralverband des
Deutschen Baugewerbes
Persönlichkeiten
für herausragende
und zukunftsträchtige
Leistungen in der Informatik
im Bauwesen.
Damit halten wir auch
das Wissen um die
Verdienste von Konrad
Zuse wach, der seinen
Weg gerade hier in Berlin
begonnen hat.
Konrad Zuse studierte
von 1928 bis 1934 an
der Technischen Hochschule
Charlottenburg
und legte 1935 sein
Diplom – Hauptexamen
zum Bauingenieur ab.
Er wird auf der ganzen
Welt als Schöpfer des
ersten programmgesteuerten
und frei programmierbarenRechners
anerkannt. Diese
Maschine – Z3 genannt
– vollendete er 1941 in
seiner kleinen Werkstatt
in Kreuzberg.
Im Deutschen Technikmuseum
hier in Berlin
ist die Entwicklung des
Z3 sehr schön dokumentiert.
Prof. Zuse war denn
auch der erste Träger
der nach ihm benannten
Medaille.
Preisträger 2005
Prof. Richard Junge
Wir wollen auf Beschluss
der Kuratoriums
heute Prof. Richard
Junge aus München
mit der Konrad-Zuse-
Medaille auszeichnen.
Laudatio von Dieter Horchler
Prof. Junge hat mit
seiner Entwicklung
der Bau-Produktmodelltechnologie
eine
wesentliche Voraussetzung
dafür geschaffen,
dass weitere Rationalisierungspotenziale
im
Bauprozess erschlossen
werden können.
Sie werden sich sicherlich
fragen, was es
damit auf sich hat. Ich
werde versuchen, Ihnen
dieses an Hand eines
kurzen Beispiels zu erläutern.
Stellen Sie sich vor, auf
einem Konferenztisch
liegt ein Bauplan. Um
den Tisch herum sit-
.zen die am geplanten
Bauwerk beteiligten
Partner: der Bauherr,
der Architekt, der Bauingenieur,
der Baustofflieferant,
der Bauunternehmer
und der Polier.
Alle sehen den selben
Plan, aber keiner sieht
das Gleiche.
Schlussendlich sehen
alle die schwarzen Striche
einer Zeichnung,
ob durch CAD oder von
Hand sei dahin gestellt.
Der Bauherr stellt sich
seinen Einzug vor, der
Bauingenieur sieht
die statischen Berechnungen,
der Baustofflieferant
kalkuliert die
notwendigen Baustoffe
und der Bauunternehmer
plant den Bauablauf.
Jeder hat seinen
Teilbereich des Bauprozesses
vor Augen, der
eine die Funktion, der
andere das Material, jeder
etwas anderes.
Wie kann es also gelingen,
sämtliche Informationen,
die jeder der am
Bau beteiligten Partner
mit dem Plan verbindet,
verbindlich zu definieren
und den Daten beizufügen?
Denn der Schlüssel
zum effizienten und
erfolgreichen Bauen
liegt genau in der Gestaltung
dieses Informationsverarbeitungs-,
bzw. Kommunikationsprozesses;
dass nämlich
der Bauunternehmer
das baut, was sich der
Bauherr vorgestellt
und der Architekt auf
Papier niedergelegt hat,
und dieses möglichst
qualitativ hochwertig,
kostengünstig und in
kurzer Zeit.
Dazu bedarf es eines effizienten
Managements
des Kommunikationsprozesses
„Bauen“ – in
der realen wie in der
virtuellen Welt.
Hier beginnt der neue
Ansatz von Prof. Junge.
Er hat als erster den
Bauprozess als Kommunikationsprozessdefiniert.
1990 prägte er
den Begriff „Integration
durch Kommunikation“.
Bis dahin ging es nämlich
immer um Daten,
den Datenaustausch
und die Datenintegration.
3

4
Doch Prof. Junge ging
es nicht einfach darum,
nur den Austausch
von Daten zu organisieren.
Sein Ziel war
es, Schnittstellen zu
entwickeln, die nicht
nur die Daten von einer
Software zur anderen
transportieren, sondern
deren Bedeutung im jeweiligen
Kontext gleich
mitliefern. Denn die
nackten Daten erhalten
ihre Bedeutung immer
erst durch die Interpretation
des Fachmanns.
Und genau in dieser
Interpretation liegen
mögliche Fehlerquellen,
und damit Kostenfaktoren,
im Bauprozess.
Der Bauplan ist eine
klassische Zeichnung,
schwarze Linien auf
weißem Papier. Nichts
anderes enthält auch
ein CAD-Datensatz im
Computer.
Die Bedeutung fügt erst
der Betrachter hinzu,
sprich der Bauunternehmer,
der Baustofflieferant
etc. hinzu.
So wie in einer Baubesprechung
die Betei-
ligten Informationen
austauschen, so sollen
diese Informationen zusätzlich
den CAD-Zeichnungen
beigegeben
werden.
Sämtliche am Bauprozess
Beteiligten sollen
diese Informationen
verstehen und identisch
interpretieren. Mit der
Produktmodellierung
im Bauwesen hat Prof.
Junge die Basis geschaffen,
dass die Softwaresysteme
der am Bauprozess
Beteiligten eine
Verständigung finden.
Damit Daten im Bauprozess
durchlaufen
können – und nicht von
jedem Beteiligten in
dem von ihm verantworteten
Teilprozess
neu eingegeben werden
müssen – muss die
Bedeutung der Daten
für die Beteiligten jeweils
interpretierbar
sein.
Soll eine Kommunikation
zwischen unterschiedlichenSoftwaresystemen
ermöglicht
werden, genauso wie
es zwischen Bauherr,
Architekt, Bauingenieur,
Baustofflieferant
und Bauunternehmer
funktioniert, dann muss
man einen Weg finden,
diese fachlichen Modelle
abzubilden und auf
die Computerwelt zu
übertragen.
Die Entwicklung eines
solchen Modells – eines
Bau-Produktmodells als
Schlüssel zur Software-
Integration – ist das Verdienst
von Prof. Junge.
Wenn es heute angesichts
der modernen
Informationstechnologien
zurecht um die
Erschließung von Effizienzpotentialen
durch
gemeinsam genutzte
Datenpools geht, ist die
normierte Produktmodellierung
eine wesentliche
Voraussetzung.
Sie ist gleichermaßen
die Bedingung zur
Vermeidung von überflüssige
und doppelten
Informationen im Informationsverarbeitungsprozess
„Bauen“.
Auf seinem Weg zu
diesem Produktmodell
hat Prof. Junge frühzeitig
die Bedeutung
des Computereinsatzes
im Architekturbüro
erkannt. Er war einer
der ersten, der CAD in
seinem Büro eingesetzt
hat. Das Thema ließ ihn
nicht mehr los.
Er beteiligte sich daher
an der Normungsarbeit
im DIN und der ISO sowie
an verschiedenen
Forschungsprojekten.
Dabei reizte ihn besonders
das Thema
Gebäudeproduktmodell,
dessen heutige
Definition durch die IFC,
die Industry Foundation
Classes, er maßgeblich
beeinflusst hat. Damit
erwarb er sich sehr
schnell internationale
Anerkennung.

So war es nur folgerichtig,
dass er an der Gründung
des deutschen
Ablegers dieses Konsortiums
auch maßgeblich
beteiligt war. Er hatte
klare Vorstellungen
davon, wie ein Produktmodell
zu modellieren
und wie es gemeinsam
zu nutzen sein könnte.
Und ihm gelang es,
dieses zu etablieren. Es
glückte ihm auch, diese
Definitionen international
gegen Teils sehr
heftige Widerstände,
besonders in den USA,
durchzusetzen.
Immer wenn es nicht
weiterzugehen scheint,
wird es für Prof. Junge
erst richtig spannend.
Mit wenigen, allgemein
verständlichen Worten
schlägt er seine meist
praktikablen, mehrheitsfähigen
Lösungen
vor und hat so oft die
Weichen für weit in
die Zukunft gerichtete
Projekte gestellt. Sein
Motto ist: „Geht nicht,
gibt‘s nicht!“ Das war
schon in der Architektenpartnerschaft
so,
wo er stets gut war für
die großen, neuen und
schwierigen Aufträge.
Es gilt auch für seine
Arbeit an der Uni.
Prof. Junge ist in allen
Feldern der Coach, dem
es gelingt, durch Motivation
seine Mitstreiter,
Mitarbeiter oder Studenten
zur Höchstform
auflaufen zu lassen.
Dabei hilft im seine
sympathische Charaktereigenschaft,
sein
Humor, den er auch in
angespannten Situationen
nicht verliert.
Sehr geehrter Herr Prof.
Junge, das Kuratorium
hat sich dafür entschieden,
Ihnen im Rahmen
unseres Deutschen
Baugewerbetages die
Konrad-Zuse-Medaille
zur überreichen. Diese
öffentliche Anerkennung
Ihres Wirkens haben
Sie verdient, auch
wenn Sie sich gerne bescheiden
und geduldig
im Hintergrund halten
und das Rampenlicht
anderen überlassen.
Heute ist der Tag, Ihnen
unsere Anerkennung
für Ihre Leistungen für
die Bauwirtschaft auszusprechen.
Sie sind ein
würdiger Träger dieser
besonderen Auszeich-
nung. Nur wer auf dem
Gebiet der Informatik
im Bauwesen hervorragendes
leistet, erhält
die große Auszeichnung
mit der Konrad-Zuse-
Medaille.
Auf diese Weise wird
die Erinnerung an Konrad
Zuse auf das Beste
gewahrt. Das deutsche
Baugewerbe beglückwünscht
Sie dazu.
5

6
Ein Bau-Produktmodell als Schlüssel
zur Software-Integration
Universitätsprofessor Dipl. Ing. Architekt Richard Junge
Fachgebiet CAAD, Fakultät für Architektur der TU München
Wenn man in einer
Baufirma aufgewachsen
ist, von
Kindesbeinen
an das Büro, den
Bauhof, die Baustellen
kennt und dann den
Beruf des Architekten
ergreift, dann kann es
einem nur ums Bauen
gehen. Der architektonische
Entwurf ist dazu
der erste Schritt.
Bauen ist ein vielschichtiger
Prozess, mit vielen
Beteiligten. Die HOAI
weist dem Architekten
bereits in der Phase des
Entwurfes das „Integrieren
der Leistungen
anderer an der Planung
fachlich Beteiligter“
zu. Bei der Ausführungsplanung
heißt
es: „Erarbeiten der
Grundlagen für die
anderen an der Planung
fachlich Beteiligten
und Integrierung
ihrer Beiträge
bis zur ausführungsreifen
Lösung“. Das
stellt nicht nur einen
hohen Anspruch an
Wissen und Können,
sondern im Zeitalter
der Software lässt
es ganz mächtig den
Wunsch, den Druck
nach Software-Integration
entstehen.
Mein erster ernsthafter
Anlass mich mit
Computern zu befassen
datiert von 1978.
Seinerzeit sah ich mich
in einem sehr großen,
komplexen Auftrag
gezwungen, Kostenplanung,
–steuerung und
–kontrolle auf der Basis
von Kostenelementen
durchzuführen. Der
Gedankengang war
folgender, einfacher:
Plant man Kosten mit
Kostenelementen und
setzt dann CAD-Systeme
ein, die wiederum
mit Bauteilen arbeiten
(und nicht mit purer
Geometrie), dann müsste
doch der Computer
schon dieses und jenes
Faktum kennen, das
mit diesen Bauteilen
verknüpft ist. Als Folge
daraus wäre zu schließen,
dass man diese
Fakten nicht nochmals
irgendwo anders wieder
neu eingeben muss.
Mengenermittlungen
klappten schon sehr
gut, die Zuweisung der
Mengen zu Kostenelementen
oder LV-
Positionen auch. Kostenelemente
bestehen
letztlich aus LV-Positionen
nach einer ganz
bestimmten „Rezeptur“.
Man kann also eine so
aufgebaute Kostenberechnung
umsortieren
und erhält ein Roh-LV.
Das funktionierte auch.
Verzweiflung kam
allerdings auf, als die
ja gerade erst in Entwicklung
befindliche
Codierungsstruktur
des Mutter –LV und
des Kostenelemente
-Kataloges verbessert
werden mussten. Unmöglich
war es, die im
Raum- und Gebäudebuch
festgelegten Qualitäten
automatisiert,
z.B. für die Kostenberechung,
auszuwerten.
Warum? Weil alles nur
in Form von Daten vorlag,
deren Bedeutung
nicht mitabgespeichert
wurde. Diese kam erst
durch den mit den Programmen
arbeitenden
Menschen dazu. Das
zeigte sich besonders,
als es die ersten Versuche
gab, mit Ingenieuren
außerhalb des eigenen
Büros zusammen
zu arbeiten.
Dieselben Probleme
oder Grenzen gab es
natürlich auch in dem
Projekt ISYBAU – Integrierter
System BAU
– des Bundesbauministerium
und der Landesbauverwaltungen
Bayern, bei dem ich
beratend tätig war.
Wir machten halt alle
denselben Fehler. Wir
glaubten, dass eine solche
Integration über Daten,
die in Datenbanken
gehalten werden, wenn
man sie nur gescheit genug
codiert, möglich sei.
Zu einem neuen Gedankengang
kam ich,
als ich in einem Soziologiebuch
die Definition
von Kommunikation
las. Daraufhin stellte
ich einen Vortrag unter
den Slogan „Integration
durch Kommunikation“.
Das Übertragen von
Worten erfolgt über
Schallwellen. Kommunikation
kann aber
erst stattfinden, wenn
die Bedeutung dieser
Worte im jeweiligen
Zusammenhang richtig
verstanden werden.
Erst dann kann darauf
sinnvoll geantwortet
oder gefragt werden.
Man kann das deutlich
machen, wenn man
sich die Runde eines
Bau- Jour-Fixe vorstellt.
Jeder in dieser Runde
hat sein, von seiner
Disziplin und Aufgabe
geprägtes, fachliches
Modell. Was er sieht,
interpretiert er demgemäss.
Dennoch aber
können sich diese
Fachleute in aller Regel
gut untereinander verständigen.
Sie kommunizieren.
Zwischen diesen
fachlichen Modellen
existieren offensichtlich
Verbindungen,
ein Verständnis, auf
dessen Grundlage
man kommunizieren,

sinnvoll Fragen stellen
und Antworten geben
kann. Nur ein ganz einfaches
Beispiel: Wenn
ein Statiker mir als
Architekten sagt, eine
bestimmte Wand müsse
eine aussteifende
Funktion übernehmen,
aus Beton bestimmter
Qualität sein usw., dann
braucht er mir keine
grundlegenden Erläuterungen
geben. Es wird
sofort und unmittelbar
verstanden. Seine Information
wird bestimmte
Konsequenzen im weiteren
Planungs- und
Bauprozess haben und
es ist auch ziemlich klar
welche. Es muss also
heißen: Integration
zwischen fachlichen
Modellen läuft über
Kommunikation.
Jetzt kommt etwas
Neues dazu: Jeder dieser
Fachleute benutzt
Computer für seine
Tätigkeiten. Und hier
scheitert die Kommunikation.
Das, was diese
Fachleute noch fertig
bringen, nämlich zu
kommunizieren, geht
nun mit ihren Computern
nicht mehr. Hier
liegen nur noch Daten
vor, die einer Interpretation
durch den Fachmann
bedürfen.
Eine Zeichnung ist lediglich
ein Stück Papier
mit Strichen darauf.
Wenn wir, Bauingenieure,
Architekten darin
lesen, dass beispielsweise
aufgrund einer
bestimmten Schraffur
dieses Mauerwerk, jenes
Beton ist, oder dass
hier eine Treppe, dort
ein Aufzugsschacht ist,
können wir das Dank
unseres fachlichen Mo-
dells. Gegenprobe: Was
sieht denn der Laie, der
Nichtfachmann auf diesem
Blatt?
Der Sprung von dieser
Papierzeichnung hin
zu einem computergestützten
Design ist
gleich null. Auch wenn
ein CAD-System benutzt
wird, das nur auf
Geometrien basiert,
ist das Ergebnis nur
ein Datensatz, der nur
Geometrie enthält. Die
Bedeutung entsteht
erst im Kopf des Betrachters.
Es ist kein Unterschied
zur händisch
erstellten Zeichnung
vorhanden.
Soll eine Kommunikation
zwischen den
Software-Systemen
ermöglicht werden, genauso
wie es zwischen
Personen geschieht,
dann muss man einen
Weg finden, diese fachlichen
Modelle abzubilden
und auf die Computerwelt
zu übertragen.
Und das ist möglich!
Aber auch hier ging es
zunächst mit untauglichen
Mitteln weiter, bis
ich die im STEP Umfeld
entwickelte Technik
der Produktmodelle
anwandte. Über mehrere
Schritte kam ich zu
einer Modelarchitektur,
die es erlaubt, Bauprodukt-Modelle
zu bauen,
ohne vorab die Größe
oder Entwicklungsrichtung
des Modells zu
kennen. So konnte man
also mit dieser ungeheuren
Aufgabe eines
Bauprodukt- Modells
beginnen und auch
nach kurzer Zeit schon
Ergebnisse nutzen.
Im folgenden soll nun
gezeigt werden, dass
die Arbeit an diesen
Konzepten den Forschungsbereichverlassen
hat und in die
industrielle Umsetzung
gegangen ist.
Internationale Standardisierung
– IFC
Man kann sich vorstellen,
dass man auf
dieser Basis intelligentere
Software schaffen
kann. Um zu breiten
Anwendungen zu kommen,
muss noch ein
sinnvoller Standard gefunden
werden. Ohne
diesen würde statt einer
gemeinsamen Sprache,
ein babylonisches
Gewirr entstehen.
Diesen Standard zu
schaffen, bemüht sich
ein Industriekonsortium
unter dem Namen
„International Aliance
for Interability“ – IAI.
Ich war einer der Initiatoren
dieser Vereinigung
und nach diversen
technischen, und später
organisatorisch politischen
Aufgaben, bin
ich heute Ehrenvorstand.
Der dort geschaffene
Standard nennt
sich „Industrie-Foundation-Classes“
– IFC.
Das Konsortium hat elf
Chapter – in Deutschland,
Skandinavien,
Großbritannien, Frankreich,
Italien, Spanien,
USA, Australien, Singapore,
Korea und Japan.
Das deutsche Chapter
hat ca. 60 Mitglieder,
international sind es ca.
650. Sie kommen aus
Ingenieur- oder Baufirmen,
aus Softwarehäusern
oder auch Verbänden.
Mit den Beiträgen
der Mitglieder wird die
Standardisierung finanziert.
Gerade in diesem
Jahr ist ein deutlicher
Zuwachs des Interesses
an IFC zu verzeichnen.
Es beginnt sich am
Markt durchzusetzen
als ein Format, das den
Vorgängern deutlich
überlegen ist.
Baugenehmigung
per Internet
Eine revolutionäre Weiterung
dieses Ansatzes
für integrierende Systeme
ist das sogenannte
Corenet-Plan-Checking-
System. Es geht dabei
darum, Bauanträge
über das Internet einzureichen
und von einem
Computer automatisch
zu prüfen und zu genehmigen.
Ein solches
Projekt betreibt die Regierung
von Singapore.
Als ich 1995 zu diesem
Projekt um Rat gefragt
wurde, glaubte man,
dass sich die grafischen
Elemente der CAD-Datensätze
so interpretieren
lassen würden, dass
man darauf die Prüfung
der Regelkonformität
aufbauen könnte. Man
war ziemlich entsetzt,
als ich sagte, das würde
nicht gehen. Ich schlug
einen anderen Weg vor.
Man hat dann zwar den
Prototypen nach dem
alten Projektplan fertig
gestellt, aber doch
langsam begonnen, den
neuen Weg parallel zu
verfolgen, weil der alte
Prototyp nicht hielt,
was er sollte.
Man kann sich, denke
ich, vorstellen, dass
wenn man eine Baueingabe
als einen Datensatz
bekommt, der
nicht nur Geometrien
7

8
enthält sondern auch
deren Bedeutung, eine
Prüfung und Genehmigung
durch den Computer
möglich wird.
Heute steht dieses
Projekt in der Erprobungsphase.
Wie aber
funktioniert das in der
Praxis? – Wird im Plan
ein Mangel festgestellt,
erscheint ein Kommentarfenster
mit dem
Hinweis, um welche
Nichtübereinstimmung
mit einem bestimmten
Paragraphen der
Bauordnung es sich
handelt. Dies geschieht
nicht erst, wenn die
Baupläne zur formalen
Prüfung eingereicht
werden, sondern bei
einer Vorprüfung. Das
Internet erlaubt es, zusätzlich
nachzufassen,
Das Ziel war hier nicht,
den Beamtenapparat
zu verringern. Man ist
vielmehr zu der Ansicht
gekommen, dass man
diese Beamten viel besser
einsetzen kann als
für Routineprüfungen.
Der Experte soll Zeit
dafür bekommen, Dinge
mit den Bauwilligen
zu klären. Das ist der
Beweggrund der technischen
Entwicklung.
Kommunikationsplattform
für den Bau
Ein drittes Projekt ist
die Kommunikationsplattform
zur Abbildung
und Abwicklung
des gesamten Bauprozesses.
Diese beruht
auf einem EU-Projekt,
das vor zwei Jahren
abgeschlossen wurde.
Es nannte sich VEGA.
Dort ging es um eine
wie weit die Bearbeitung
gediehen ist.
Es geht hier nicht um
die politische Prüfung,
ob der Bau an dieser
Stelle etwa aus Sicht
der Ortsentwicklung
richtig ist. Es geht allein
um die baurechtliche
Seite, also die Fragen:
sind Brandschutz, sind
Abstandsregeln usw.
eingehalten.
Software, die – so das
Schlagwort – „Virtual-
Enterprises“ ermöglicht,
also Netzwerke von virtuellen
Unternehmen.
Das ist genau die Situation,
die wir im Bereich
des Bauwesens haben.
Deswegen wurde auch
das Bauwesen als Modellfall
genommen.
Wir haben jeweils projektbezogen
eine ganz
unterschiedliche Zu-
sammensetzung vieler
mitwirkender Firmen.
Ich will jetzt nicht
darauf eingehen, wie
das im einzelnen funktioniert.
Basis ist eine
Datenbank, die unter
anderem projektbezogene
fachliche Modelle
enthält und einen
Kommunikationsbus,
der die einzelnen Applikationen
miteinander
verbindet. Das ganze
nennt sich eine Middleware,
in diesem Falle
eine Kommunikationsplattform,
auf die die
unterschiedliche Bau-
Software aufgesetzt
werden kann. Als industrielleWeiterentwicklung
der Nemetschek
AG nennt sich diese
Plattform O.P.E.N. für
Open Produkt-Model
Engineering Network.
Damit ist dann auf die
Computerwelt übertragen,
was meine Ausführungen
zu Kommunikation
gemeint haben.
Integrierte Anwendung
im Fertigteilwerk
Konkret geht es hier
um Gasbetonbauteile,
also großformatige
Blöcke für Decken und
Wände. In der gängigen
Praxis muss der
Entwurf eingelesen,
oder im schlimmsten
Fall nochmals eingeben
werden. Schließlich
geht das Ganze an das
Fertigungsplanungssystem.
Dann ist noch
die Logistik integriert,
diese liefert nicht nur
Parameter für den Fertigungsablauf,
sondern
es werden im Rhythmus
der Baustelle auch die
einzelnen Lieferungen
inkl. aller Klein- und
Verbindungsteile zusammengestellt
und
letzten Endes die Lastwagen
zur Baustelle in
Gang gesetzt.
Hier sind unterschiedlicheSoftware-Komponenten
miteinander zu
verbinden. Hier leistet
O.P.E.N. diese spezielle
Integration oder Kommunikation.
Ziel war es,
die technische Produktionsplanung
bzw. Produktionssteuerung
mit
dem kaufmännischen
System von SAP zu verbinden,
das vorhandene
CAD-System und die
statische Berechnung
mit einzubinden.
Ich war lange Jahre in
der ISO Vorsitzender
eines Normungsgremiums,
das solche Produktmodelle
zur Datenintegration
baut. Dort
sind im wesentlichen
andere Industrien, namentlich
die Automobilindustrie
und Flugzeugindustrie,
führend.
Als ich von unseren Entwicklungen
einem der
ehemaligen Kollegen
aus der Automobilindustrie
berichtet habe,
meinte der: „Ihr seid ja
zum Teil weiter als wir!“
Das zeigt: Wenn man
diese Themen anpackt,
kann man auch in der
Bauwirtschaft eine
ganze Menge erreichen.
Was wir dazu brauchen,
sind die Grenzgänger.
Also nicht die
Spezialisten, die nur
ihr Fachgebiet kennen,
sondern die, die zwischen
solchen Fachwelten
wandern, Brücken
bauen können. Der Informatiker
allein kann
das ebenso wenig wie
der Bauingenieur oder
der Architekt, wenn sie
nur ihre ursprüngliche
Ausbildung haben.
Für den Fortschritt im
Bauwesen bleibt daher
als Kernfrage: Wie kommen
wir zu mehr solchen
Grenzgängern.

Zur Person
Prof. Richard Junge: Mein Weg zu den
Bau-Produkt-Modellen
Das Bauen ist mir wohl
schon in die Wiege
gelegt worden. Meine
Familie mütterlicherseits
ist seit ca. 1750 als
Maurermeister oder als
Baumeister urkundlich.
Aufgewachsen bin ich
also auf dem Bauhof
– oder dicht dabei- einer
typisch kleinstädtischen
Baufirma an der
holsteinischen Ostseeküste.
Meine Begeisterung
zum Bauen entdeckte
ich erst später. Zunächst
war ich eher
flugbegeistert. An
meinem 14 Geburtstag
hatte ich meinen A-
(Flug)Schein. Das ging
damals. Die Zeit in der
ich nicht auf dem Flugplatz
war, verbrachte
ich mit Flugmodellbau,
wurde sogar Landesjugendmeister.
Zum Modellbau
muss man ein
wenig Wissen über die
Gesetze der Aerodynamik
haben, zuvorderst
aber muss man sich
technisches Zeichnen
beibringen. Für die
Schule bleibt da natürlich
keine Zeit übrig!
Aber irgendein Schutzengel
hat mir doch
zum Abitur verholfen.
Klar, dass ich immer
Flugzeugbau studieren
wollte – meine konstruktive
Seite. Ganz
kurz vorm Abi setzten
sich dann aber doch
meine Gene durch. Ich
studierte Architektur in
München.
Architekturentwurf war
und ist für mich immer
ein ersten Schritt zum
Bauen, so bin ich im
klassischen Sinne Baumeister
geblieben. Zwei
Dinge begeistern mich
dabei immer wieder:
–Jeder Strich eines
Entwurfes hat eine
Konsequenz in der
Ausführung.
–Ich bin immer ein
Mitglied des Teams
von Ingenieuren und
Ausführenden.
Und dennoch kann man
„Wettbewerbsarchitekt“
sein. Also einer,
der seine Aufträge über
Wettbewerbe holt und
so seine berufliche Karriere
aufbaut.
Flughafen München
Einer dieser Wettbewerbe
war das „Betriebsgelände
Nord“
auf dem neuen Münchner
Flughafen, einem
ca. 2 Km langen Band
mit all den Gebäuden,
die von Energieversorgung,
über Catering
und Polizeidirektion
bis zu Werkstätten und
Unterstellhallen für die
Geräte der Flughafengesellschaft
reichen.
Übrigens war dies ein
Auftrag als Generalplaner,
d.h. alle Fachplaner,
bis hin zu den Algenplanern
waren meine
Subplaner.
Mit diesem Auftrag
begann 1978 für mich
das Computerzeitalter.
Der Bauherr verlangte
Kostenplanung mit
Kostenelementen, also
Bauteile die mit Qualitäten
und dazugehörigen
Kosten verbunden
sind. Das geht nur mit
Computer.
1981 wurde auf dem
Klagewege ein Baustop
für den Flughafen
erreicht. Für uns eine
ganz schwierige Zeit.
Die Erlösung kam mit
dem Beschluss der Partner
unseres Büros, ins
CAD einzusteigen. Da
ich bereits mit Computern
zu tun hatte, wurde
mir das übertragen.
So wurde, nach kurzem
experimentieren mit
einem 2D-CAD, 1983/84
die Einführung des bauteilorientierten
3D-CAD
„RIBCON“ durchgeführt.
Meine Vision war, dass
über die Bauteile, wie
sie mir bereits aus der
Kostenplanung und
AVA bekannt waren, eine
Integration der einzelnen
EDV- gestützten
Arbeiten im Büro möglich
sein müsste. (Inzwischen
ist das auch so.
Nur nicht so kurzfristig
wie damals gedacht).
Der Einstieg in CAD war
wie ein Sprung ins Wasser,
ohne zu wissen, ob
man schwimmen kann.
Es war durchaus nicht
klar, ob CAD im Architekturbüro
Sinn macht.
CAD erforderte enorme
Investitionen. Der erste
Arbeitsplatz: Rechner,
Plotter, ein
Industrie-
Magnetbandspeicher,
kostete 250 TDM.
Der PC war gerade
erfunden und noch in
keiner Weise für CAD
9

10
geeignet. Glücklicherweise
kamen 1983
gerade die Unix- Workstations
von Apollo auf
den Markt. So musste
man nicht schon beim
ersten Arbeitsplatz entscheiden,
welche Zahl
von Arbeitsplätzen man
im Endausbau haben
werde. Man konnte
mit einer Workstation
beginnen und über
ein Netzwerk, damals
revolutionär neu, beliebig
viele weitere dazu
schließen.
Wir gewannen aus den
um München angesiedeltenHigh-Tech-Branchen
viele Bauherren,
die in uns ebenbürtige
Partner sahen- vom
gleichen Geist getriebene.
Berufspolitisches
Engagement
Mein berufspolitisches
Engagement brachte
mich in diverse Arbeitsgruppen
der Architektenkammer
auf Landes-
und Bundesebene, in das
DIN und ab 1989 auch in
die ISO.
Dieses Engagement
führte Ende 1985 zu
einer an Konsequenzen
reichen Nebentätigkeit,
der Gründung der CAB
(Computer Anwendung
im Bauwesen Beratung
GmbH) und des EDV-Labor
Bayern.
Das Bundesforschungsministerium
hatte über
viele Jahre die Software-
Entwicklung im
Bauwesen gefördert,
dann aber doch festgestellt,
dass die in den
Anträgen beschriebenen
Erfolge, vor allem
in der Durchdringung
des Marktes, nahezu
völlig ausblieben. Das
Programm wurde abgesetzt.
Nur eine letzte
Maßnahme wurde
noch durchgeführt: ein
Know-how-Transfer-
Projekt namens EDV-
Labor. Das Ziel bestand
darin, dass diejenigen,
die Computer in der
Praxis einsetzten, ihr
Know-how ihren Kollegen
in Seminaren und
Schulungen vermitteln
sollten.
Das gab mir Mittel an
die Hand, mit denen ich
die ersten eigenen Forschungen
betrieb.
Ab 1990 war ich Vertreter
des Bundesministeriums
Bau bei
UN-EDIFACT (United
Nations Directories for
Electronic Data Interchange
for Administration,
Commerce and
Transport). Von 1991-
95 war ich Vorsitzender
der AEC Gruppe in ISO-
STEP (Standard for the
Exchange of Product
Model Data). In dieser
Zeit wuchs die Gruppe
von ca.12-16 Mitgliedern
auf über 100 an.
Dies machte 1995 die
Aufspaltung in die Ar-
beitsgruppen Schiffbau,
Offshore- und petrochemische
Anlagen
und Bauwesen sinnvoll
und möglich. Hier lernte
ich die Technik der
Produktmodellierung
verstehen.
Integration durch
Kommunikation
1990 prägte ich als Titel
eines Vortrages an der
University of Wisconsin
das Schlagwort „Integration
durch Kommunikation“.
Bis dahin ging
es immer um Daten,
Datenaustausch und
Datenintegration, wie in
allen anderen Vorhaben
dieser Zeit auch. Mein
Schlagwort meinte, es
geht nicht nur um die
Daten sondern auch
oder gerade um deren
Bedeutung im jeweiligen
Kontext.
Daten erhalten ihre
Bedeutung immer erst
durch die Interpretation
durch den Fachmann.
Der Datensatz der
klassischen Papierzeichnung
besteht aus
schwarzen Linien auf
weißem Papier. Nichts
anderes enthält der
CAD-Datensatz. Bedeutung
tut der Betrachter
hinzu. Niemals kann so
Integration entstehen.
Integration kann erst
entstehen, wenn die
beteiligte Software
„versteht“ was sie empfängt,
und darauf sinnvoll
reagieren kann.
So wie in meiner
Karikatur einer Planungsbesprechung
die
Architekten und Ingenieure
kommunizieren, so
sollte auch die Software
kommunizieren können.
Soweit die Idee. Aber, es
braucht seine Zeit, ehe
der radikalere Durchbruch
gelingt.
Der Weg dahin führte
über die EU- Projekte
COMBI und VEGA, sowie
Entwicklungen für die
Industrie.
Das Produktmodellbasierte
Projekt IFC des
internationalen Konsortiums
IAI (International
Alliance for Interoprability)
verwendet die von
mir 1996- 97 vorgestellte
Modellarchitektur,
wie sie in VEGA, OPEN
und NextCAAD bereits
verwendet wurde. Nach
langem Anlauf ist IFC
auf gutem Wege sich
durchzusetzen.
Das Projekt zur automatischen
Prüfung von
Baueingabeplänen des
Staates Singapore wurde
von mir erfolgreich
umgesetzt.
Man braucht Ausdauer!

Professor Roland Vollmar, Universität Karlsruhe (TH)
Konrad Zuses technische Erfindungen
Vorsitzender der Konrad-Zuse-Gesellschaft
Während Konrad Zuse
als Pionier auf dem
Gebiet vollautomatischer
Rechenanlagen
auch den gebildeten
Nichtfachleuten heute
zumindest dem Namen
nach bekannt sein
dürfte, ist das Wissen
um den Umfang seines
erfinderischen Werkes
noch nicht durchgedrungen.
Über die Ausführungen
zu Konrad Zuses Werk
stelle ich eine Aussage
von E. A.
Poe:
„Die Geistesgaben,
die als die analytischen
bezeichnet werden,
sind für sich selbst der
Analyse wenig zugänglich.
Wir betrachten sie
lediglich ihren Wirkungen
nach.“
Da mir diese Auffassung
erst recht für
die Erfindungsgabe
angemessen erscheint,
beschränke ich mich
im folgenden auf die
Darstellung der wichtigsten
technischen Erfindungen
von Konrad
Zuse und ihre Rezeptions-
und Wirkungsgeschichte.
Mein Thema erlaubt
es mir nicht, auf die
Person Konrad Zuses
einzugehen, den ich als
zunächst eher spröden
und reservierten, bald
aber überaus warmherzigen,
humorvollen
und gelegentlich sanft
ironischen Menschen
kennen lernen und verehren
durfte. Ihm wäre
es sicherlich unangenehm
gewesen, wenn
im weiteren im wesentlichen
nur sein Name
genannt wird, hat er
doch immer daraufhingewiesen,
wie vielen
Menschen er für ihre
Unterstützung Dank
schuldete, wobei insbesondere
seine Eltern
und seine Schwester
und seine Frau Gisela
Zuse, geb. Brandes, im
Mittelpunkt standen,
aber auch zahlreiche
Freunde und Mitarbeiter.
Viele von ihnen hat
er in seiner Autobiographie
) gewürdigt,
deren Lektüre allen, die
ihn und sein Werk näher
kennen lernen wollen,
ans Herz gelegt sei.
Ebenso nachdrücklich
sei auf die von seinem
ältesten Sohn Horst
zusammengestellte
Multimedia-CD
) hingewiesen,
auf der wertvolle und
weiterreichende Informationen
über das
Leben und das Werk
Konrad Zuses sowie
Videosequenzen und
zahlreiche Abbildungen
seiner Karikaturen und
Bilder zu finden sind.
Auch eine noch so kurze
Betrachtung über
Computer und ihre
Entwicklung sollte nicht
ohne die Nennung
von Charles Babbage
(1791-1871) erfolgen
– und dies nicht zuletzt
deshalb, weil Konrad
Zuse ihn als seinen
kongenialen Vorläufer
anerkannte, wenn er
auch zu Beginn seiner
Beschäftigung mit
Rechnern nichts von
ihm wusste.
In den dreißiger Jahren
des 19. Jahrhunderts,
noch während der
Bemühungen um den
Bau eines Prototyps
seiner Difference Engine
begann Babbage
die Konzeption seiner
Analytical Machine,
in der sich bereits alle
Ingredienzien einer
vollautomatischen
Rechenanlage fanden.
Herstellungsprobleme
und vor allem Geldmangel,
teilweise durch
das nicht immer diplomatische
Vorgehen von
Babbage verursacht,
verhinderten zu seinen
Lebzeiten eine Realisierung
der Analytical
Machine, während er
eine auf seinen Ideen
beruhende von dem
schwedischen Drucker
George Scheutz und
dessen Sohn Edward
gebaute Differenzmaschine
1855 in Funktion
sehen konnte.
Im letzten Abschnitt
seiner Biographie von
Charles Babbage drückt
seine
Bewunderung für ihn
Hyman
mit folgenden Worten
aus:
...war Babbage, abgesehen
von der Unterstützung
durch seine
Gehilfen und gelegentlicher
Hilfe von Seiten
seiner Söhne, in seiner
Arbeit auf sich gestellt
und dem zeitgenössischen
Bewusstsein
weit voraus. Er musste
nicht nur die Entwürfe
ausarbeiten, sondern
auch die Konzepte für
die Ausführung, ja,
sogar das Instrumentarium
zur Fertigung
der Teile entwickeln. Er
musste die Mathematik
entwickeln, seine technische
Schreibweise in
ihren verschiedenen
Stadien, die Anfänge
des Mikroprogrammierens
und Kodierens,
– sogar erst einmal
überhaupt auf die Idee
kommen. Charles Babbage
steht in einsamer
Größe da: als Urvater
des Computers.“
Diese Situationsbeschreibung
trifft leicht
modifiziert auch auf
Konrad Zuse zu, wie im
folgenden skizziert sei.
Während Babbage am
Beginn der Industriellen
Revolution nahezu
selbstverständlich in
der Tradition der mechanischen
Rechner
bleibt, wie sie von
Schickard, Pascal und
Leibniz entwickelt
wurden und auf handwerkliches
Können
angewiesen war, gilt
dies erstaunlicherweise
auch für Konrad Zuses
erste Maschine, die
Z1. Der entscheidende
Unterschied zu Bab-
11

12
bages Konzeption liegt
in der Verwendung des
Dualsystems. Heute
mag dies geradezu
trivial erscheinen, aber
damals arbeiteten
zumindest alle kommerziell
verfügbaren
mechanischen und
elektromechanischen
Rechner im Dezimalsystem.
Mit dieser Entscheidung
war Konrad
Zuse nicht mehr auf
Zahnräder, Staffelwalzen
oder Sprossenräder
angewiesen, deren
Fertigung – zumindest
in genügender Zahl und
mit hinreichender Präzision
– nicht im Wohn-
zimmer seiner Eltern
möglich gewesen
wäre,
im Unterschied zu den
gelochten Blechen, mit
denen er (weitgehend)
auskam.
Ab 1934 machte er sich
Gedanken über die Mechanisierung
des Rechnens.
Ausgangspunkt
waren Formulare, in
die Zahlen einzutragen
waren und Grundrechenarten
darauf
anzuwenden waren
). Zunächst
wollte er diesen
Prozess automatisieren,
ging dann aber neue
Wege, indem er ähnlich
wie etwa zur gleichen
Zeit Turing feststellte,
dass die zweidimensionale
Anordnung in
eine lineare übertragen
werden kann. Mit mechanischen
Rechnern
hatte er sich wohl nicht
eingehender beschäftigt,
sondern wurde
von Dr. Pannke, dem
Inhaber einer Rechenmaschinenfabrik
darauf
hingewiesen, dass es
auf diesem Gebiet ohnehin
nichts mehr zu
erfinden gebe. Unter
Mithilfe seines Vaters
und von Freunden wurden
Metallplättchen
zurechtgeschnitten, aus
denen er 1936 einen
mechanischen Speicher
vollendete, der eine
Kapazität von 64 Wörtern
hatte. In Abbildung
2 ist ein Baustein zur
Speicherung eines Bits
dargestellt. Besondere
Beachtung verdient die
Tatsache, dass die Bleche,
die untereinander
durch Stifte und Hebeln
verbunden sind, nur in
zwei zueinander senkrechten
Richtungen
bewegt werden.
Mich beeindruckt diese
erfinderische Leistung
in höchstem Maße,
insbesondere wenn
man sich bewusst
macht, dass Binärdarstellungen
keineswegs
üblich waren. Sie war
wohl nur möglich, weil
Konrad Zuse ein hervorragendes
räumliches
Vorstellungsvermögen
hatte und durch seine
frühe Beschäftigung
mit mechanischen
Baukästen und sein
Studium entsprechend
geschult war. Nach
den gleichen Prinzipien
wurden auch eine
arithmetische Einheit
und eine Steuereinheit
gebaut; ihre (logische)
Trennung vom Speicher
war dabei nicht selbstverständlich
(aber auch
schon von Babbage
geplant). Bei der ersteren
kamen die Vorteile
eines binären Systems
bei der Realisierung der
Multiplikation zum Tragen:
Der bei (elektro-)
mechanischen Rechnern
häufig verwandte
Einmaleins-Körper hat
im Dualsystem eine
sehr einfache Struktur.
Die Maschine arbeitete
mit Gleitkommazahlen.
Eine Besonderheit war
des weiteren der von
Konrad Zuse realisierte
einschrittige Übertrag.
1938 funktionierte
Konrad Zuses erste
Maschine, die Z1, – allerdings
mehr schlecht
als recht: Während die
Informationsübertra-
gung auf elektrischem
Wege nahezu trivial realisierbar
ist, sieht dies
bei Verwendung mechanischer
Teile anders
aus; es müssen Stangen
bewegt werden, und
Änderungen der Bewegungsrichtung
und Synchronisationsnotwendigkeiten
führen leicht
zu Verklemmungen.
Die Z1 erfüllte aber insofern
ihren Zweck, als
sich an ihr zeigte, dass
das Konzept richtig
war. Als Ingenieur war
Konrad Zuse jedoch
an einem zuverlässig
arbeitenden Gerät interessiert;
folgerichtig
entwickelte er eine weitere
Maschine, die Z2,
in der das Rechenwerk
aus Relais aufgebaut
war, die aber weiterhin
einen mechanischen
Speicher besaß. Bei dieser
“Umsetzung” zeigte
sich die Weitsicht und
die Professionalität, mit
der Konrad Zuse auch
das Erfinden in Angriff
nahm: Er hatte bereits
während der Überlegungen
zur Z1 eine sog.
“abstrakte Schaltgliedtechnik”
entwickelt
– im wesentlichen Teile
der Aussagenlogik
–, so dass die in dieser
Art dargestellten Basisschaltungen
leicht
sowohl mechanisch als
auch elektromagnetisch
realisierbar waren.
Wichtig für die weitere
Arbeit von Konrad Zuse
war die Z2 auch dahingehend,
dass er sie
Prof. Teichmann von der
Deutschen Versuchsanstalt
für Luftfahrt 1940
erfolgreich vorführen
konnte und danach von
dieser Institution die

Nachfolgemaschine Z3
teilfinanziert erhielt.
Die Z3 nimmt eine
besondere Stellung als
„erste vollautomatische,programmgesteuerte
und frei programmierbare,
in binärer
Gleitpunktrechnung
arbeitende Rechenanlage“
im Werk von
Konrad Zuse ein. Um
nicht den Eindruck aufkommen
zu lassen, dies
sei eine rein deutsche
Einschätzung noch ein
Zitat aus einem Standardbuch
zur Computergeschichte
: „The Z1 and
Z2 count as working
versions of an automatic
controlled calculating
machine, but the
Z3 was the first machine
in the world that
could be said to be a
fully working calculator
with automatic control
of its operations. There
was, of course, no internally
stored program
and no way to easily
implement conditional
branch instructions, but
both of these were se-
veral years away from
being developed anywhere
in the world.“
Es sei noch angemerkt,
dass R. Rojas
nachwies, dass
man mit ihr trotz des
Fehlens einer bedingten
Sprunganweisung sehr
wohl entsprechende
Programmkonstruktionen
hätte realisieren
können.
Von noch größerer
Wichtigkeit für Konrad
Zuse selbst war die
nächste fertiggestell-
te Maschine, die Z4,
die er in den letzten
Kriegswochen aus Berlin
ins Allgäu bringen
konnte und die später
(in leicht modifizierter
Form) an die ETH Zürich
vermietet wurde.
Trotz der inzwischen
umfangreichen Erfahrungen
mit
Relaistechnik
besaß die Z4
wieder einen
mechanischen
Speicher, weil
dieser sich
als zuverlässig
erwiesen
hatte und
Konrad Zuse
einen entsprechenden
Relaisspeicher
hinsichtlich
Größe und
Gewicht als
inadäquat betrachtete.
Die aus der
Vermietung
resultierenden
Einnahmen
erlaubten 1949 die
Gründung der ZUSE
KG. Hier soll nicht
näher auf deren Entwicklung
eingegangen
werden, sondern es
sollen lediglich zwei
Geräte erwähnt werden,
die Z22 und der
Graphomat Z64.
Mitte der fünfziger
Jahre hatte sich in der
Computerindustrie
auch in Deutschland
die Elektronik durchgesetzt,
so dass auch
die ZUSE KG von
Relaiscomputern zu
Elektronenrechnern,
zunächst zu Röhrenrechnern,
wechseln
musste. Die von T.
Fromme konzipierte Z22
hatte eine sehr einfache
Grundstruktur, dem sog.
“Minima”-Prinzip folgend,
wie von W.L. van
der Poel in den Niederlanden
verwandt. Durch
F.R. Güntsch wurde es
im Hinblick auf Adressenumrechnungenetwas
modifiziert. Ihre hohe
Flexibilität verdankte
sie dem analytischen
Befehlscode, der über
10000 Befehlsarten ermöglichte.
Der Speicher
bestand aus 15 bzw. 31
Kernspeicherzellen und
8 K Wörtern à 38 Bits
auf einer Magnettrommel
mit einer mittleren
Zugriffszeit von 5 msec.
Um einen Vergleich mit
heutigen Rechnern zu
ermöglichen, seien Ausführungszeiten
(in msec)
einiger arithmetischer
Befehle genannt: Addition
und Subtraktion
50-70, Multiplikation
50, Division 80, Quadratwurzelziehen
220.
Diese relativ langen
Zeiten sind auch durch
die sequentielle Arbeitsweise
der Z22 bedingt.
Ein Achtel der Trommel
war mit arithmetischen
Grundprogrammen und
Schreib-/Lese-Programmen
belegt. Der “leeren”
Maschine wurden über
Tasten des Bedienpultes
ein “Urprogramm” eingegeben,
das das (sehr
kleine) Betriebssystem
über einen Lochstreifenleser
einlas. Die Resultate
wurden über einen
Fernschreiber mit angeschlossenemLochstreifenstanzer
ausgegeben.
Das “Minima”-Prinzip
war durch die Situation
Europas nach dem Zweiten
Weltkrieg geprägt: Es
13

14
herrschte ein allgemeiner
Mangel, die Industrie
befand sich in einer
Wiederaufbauphase
und für Deutschland
galten noch zusätzliche,
von den Alliierten
auferlegte Beschränkungen.
Auch dank der Unterstützung
der DeutschenForschungsgemeinschaft
konnten
in Deutschland 50
Maschinen dieses Typs
ausgeliefert werden
(fünf weitere gingen ins
Ausland), wodurch die
Z22 für die ZUSE KG ein
wirtschaftlicher Erfolg
war.
Katasterämter waren
für Aufgaben der Flurbereinigung
nicht nur
an Rechnern sondern
auch an automatischen
Zeichenmaschinen
interessiert, ein Grund
für Konrad Zuse sich intensiver
mit einer Konstruktion
zu befassen
– übrigens die letzte in
der Rechenmaschinenlinie.
Sein wesentlicher
Beitrag hierzu ist im
Entwurf eines Planetengetriebes
bzw. eines
“Binärstufengetriebes”,
wie er es selbst nennt,
zu sehen. Mit ihm
waren 15 Geschwindigkeitsstufen
des Zeichenkopfes
erreichbar.
Gesteuert wurde das
transistorisierte Gerät
über Lochstreifen oder
-karten oder in direkter
Verbindung mit Rechnern.
Ab 1961 wurden
Graphomaten in zweierlei
Größen recht erfolgreich
verkauft.
Damit sind nur die herausragendenErfindungen
und Entwicklungen
Konrad Zuses skizziert.
Er befasste sich in den
Kriegsjahren auch mit
Geräten, die heute als
Spezialprozeßrechner
bezeichnet würden
und mit Analog-Digital-
Wandlern.
Auch das Pipeline-Prinzip
hat er bereits etwa
1950 vorweggenommen.
Zuse: „Wir entwickelten
eine Konstruktion
mit einer Serie von
hintereinander geschalteten
Addierwerken,
durch die die einer
Lochkarte zugeordneten
Operationen hintereinander
weg hindurch
liefen. Dabei wurde die
Serie der Rechenwerke
simultan durch die Operationen
für mehrere
Lochkarten belegt. Dieses
Verfahren entsprach
genau dem heutigen
Pipelining.“
Bemerkenswert an Konrad
Zuses Leben als Erfinder
ist das Schließen
eines Kreises: Der von
ihm gegen Ende seines
Lebens konzipierte
sog. “Helixturm” ist als
Modell aus Blechen
zusammengesetzt, von
denen man sich ihrer
Ähnlichkeit mit den
Schalt- und Speicherelementen
der Z1 wegen
vorstellen kann, dass
er auch sie ausgesägt
hätte. Bei einer Realisierung
sollen allerdings
in einem integrierten
Reservoir wesentlich
größere, gleichartige
Stahlelemente verfügbar
sein, die dort
(durch Motorenkraft)
herausgenommen bzw.
wieder eingefügt werden.
Dadurch wird es
möglich die Höhe des
Turmes zu variieren, z.B.
in Abhängigkeit von
der Windlast. Ebenso
wie die frühen mechanischen
Geräte ist
auch das Modell dieses
Turmes ästhetisch überaus
ansprechend, so
dass es sich hinter den
anderen künstlerischen
Werken von Konrad Zuse
nicht zu verstecken
brauchte.
Dieser Artikel erschien in leicht veränderter
Form zuerst in dem von der Ernst-Freiberger-
Stiftung herausgegebenen Buch
W. Mons, H. Zuse, R. Vollmar “Konrad Zuse”,
Berlin, 2005.
Dort finden sich auch eine ausführliche
Darstellung der theoretischen Arbeiten
Konrad Zuses sowie genaue Quellenangaben
und weiterführende Literatur.

Die Träger der Konrad-Zuse-Medaille des ZDB
1981
1983
1985
1987
1989
1991
1993
1995
1997
2000
2002
2005
Konrad Zuse
Fridolin Hallauer
Heinz Nixdorf
Volker Hahn
Hermann Fleßner
Johannes Jänike
Leonhard Obermeyer
Kurt W. Pauli
Georg Nemetschek
Ernst Riffel
Klaus Schiller
Richard Junge
15

Sportarena?
Brücke?
Messegelände?
Geniale Ideen werden meist erst mal verworfen. Wenn sie wirklich genial sind, lassen sie uns aber nicht mehr los.
So lange, bis wir sie verwirklichen: www.go-evolution.com
freelance marketing