Nutzung von Entwurfswerkzeugen über das Internet

Transkript

1 Dresdner Tagung»Automatisierung des Schaltkreis- und Systementwurfs«, Dresden, Mai 2003, S Nutzung von Entwurfswerkzeugen über das Internet A. Schneider 1, E. Ivask 2 1 Fraunhofer-Institut für Integrierte Schaltungen, Außenstelle EAS Dresden 2 Technische Universität Tallinn Andre.Schneider@eas.iis.fhg.de Kurzfassung: Mit der wachsenden Komplexität der zu entwerfenden Systeme steigen die Anforderungen an den Entwurfsprozess selbst: hochqualifizierte Ingenieure müssen verstärkt in Teams zusammenarbeiten und effizient alle verfügbaren hard- und softwaretechnischen Ressourcen nutzen. Eine zentrale Rolle spielt hierbei das Internet. Es ermöglicht einerseits die direkte Zusammenarbeit zwischen Entwerfern unabhängig von geografischen Gegebenheiten. Andererseits gestatten heutige Internet-Technologien, Entwurfswerkzeuge auch über große Entfernungen remote zu nutzen bzw. für die Realisierung spezieller Entwurfsabläufe zu koppeln. Der vorliegende Beitrag stellt eine am Fraunhofer IIS realisierte Softwarearchitektur vor, die eine Internet-basierte Kopplung und Nutzung vorhandener Entwurfswerkzeuge (Simulatoren, Optimierungsprogramme, Synthese- und Testwerkzeuge) gestattet. Insbesondere werden dabei Lösungen zur Gewährleistung der Datensicherheit und zur transparenten Kopplung über Firewallgrenzen hinweg aufgezeigt. Schlüsselworte: Internet-basierter Entwurf, Simulation, Optimierung, Verschlüsselung von Entwurfsdaten, Firewall Betrachtet man die derzeitig sowohl im akademischen wie auch im industriellen Umfeld vorhandene Entwurfssoftware, fällt folgender Widerspruch auf: Nahezu alle etablierten Programme (Schaltungs-, Netzwerk-, FEM-Simulatoren, Synthese-, Test- und Verifikationssysteme, Schematic-Editoren, Programme zur Ergebnisanzeige) sind für den Standalone-Einsatz auf einem einzelnen, lokalen Arbeitsplatzrechner gedacht. Auf der anderen Seite sind in der Regel alle diese Arbeitsplatzrechner in lokale Netzwerke integriert und verfügen oft über einen direkten Zugang zum Internet. Obwohl quasi die modernen Kommunikationsmöglichkeiten und Web- Technologien de facto vorhanden sind, ist es noch immer schwierig, beispielsweise einen kommerziellen Simulator mit einem Open-Source-Optimierungsalgorithmus im LAN oder per Internet zu koppeln oder diese Werkzeuge zu nutzen, auch wenn sie nicht auf dem lokalen Rechner bzw. unter dem gleichen Betriebssystem installiert sind. Die Gründe für diese Diskrepanz sind unter anderem folgende: Im Zusammenhang mit der Verbreitung der Internetnutzung entwickeln sich sehr rasant neue Basistechnologien (verteilte Komponentenmodelle wie CORBA, EJB, DCOM; Architekturmodelle wie Web-Services,.Net-Framework; Programmiersprachen wie Java, C#). Etablierte Entwurfswerkzeuge sind in der Regel sehr komplex. Ihre Entwicklung erfolgte nicht selten kontinuierlich über viele Jahre hinweg. Oft ist es technisch nicht möglich bzw. aus Kundensicht nicht sinnvoll, kurzfristig die o.g. neuen Basistechnologien in diese Werkzeuge zu integrieren. Nach wie vor sind die Unternehmen, die ihre Produkte erfolgreich am Markt platziert haben, daran interessiert, mit den eigenen Werkzeugen ein komplettes Spektrum an Aufgabenbereichen abzudecken. Insofern besteht bei diesen Firmen oft nur ein sehr begrenztes Interesse an einer Koppelfähigkeit zu firmenfremden Produkten. 1 Motivation Solaris (Workstation) Linux (Cluster) LAN Solaris (Server) Internet Arbeitsplatz des Entwerfers Windows (PC) Bild 1: Plattformübergreifende Nutzung von Entwurfswerkzeugen über LAN und Internet. Auch in den kommenden Jahren wird sich diese Situation nicht grundsätzlich ändern. Zwar werden sich die Basistechnologien zur Unterstützung ver-

2 teilter Arbeitsweisen konsolidieren und viele kommerzielle Entwurfswerkzeuge werden zunehmend offene Schnittstellen bereitstellen und Internet-basiertes Arbeiten im Rahmen von Software-Leasing- Verträgen anbieten, für eine flexible Kopplung von Werkzeugen unterschiedlicher Hersteller und für die Nutzung dieser so entstehenden Workflows im Internet wird jedoch auch weiterhin ein nicht zu unterschätzender Bedarf bestehen. In der Außenstelle Entwurfsautomatisierung des Fraunhofer IIS wurde in den letzten Jahren diese Problematik aufgegriffen und Schritt für Schritt eine leistungsfähige Integrationsplattform entwickelt. Begonnen wurde 1998 mit einer Internet-basierten Kopplung von Simulations- und Optimierungswerkzeugen unter dem Namen MOSCITO. In den letzten Jahren wurde die dafür entwickelte Basistechnologie zur Toolkopplung vervollkommnet und für weitere Anwendungsgebiete erschlossen. MOS- CITO wird heute unter anderem im Umfeld der kollaborativen Testmustergenerierung im Digitalentwurf, bei der Simulatorkopplung und für Online- Simulationen in E-Learning-Systemen eingesetzt. Der Beitrag erläutert die grundlegenden Funktionsprinzipien von MOSCITO. Es wird exemplarisch gezeigt, wie Entwurfswerkzeuge in das System integriert werden können und welche Nutzerschnittstellen für den Anwender existieren. Weiterhin wird skizziert, wie MOSCITO über Firewallgrenzen hinweg kommunizieren kann und wie Entwurfsdaten bei der Übertragung vor unberechtigtem Zugriff geschützt werden. 2 Architektur Bei der Konzeption der MOSCITO-Koppelsoftware wurden von Anfang an drei Randbedingungen definiert: Die Software soll die Integration vorhandener Entwurfswerkzeuge erlauben. Ein Programm muss sich folglich als Ganzes (quasi als Blackbox) an die Koppelsoftware anbinden lassen. Damit sollte explizit die Integration verfügbarer kommerzieller Programme, für die in der Regel keinerlei Modifikationen der Schnittstellen möglich sind, unterstützt werden. Die einzige Einschränkung besteht darin, dass das eingebettete Werkzeug als Hintergrundprozess ohne GUI- Interaktionen lauffähig sein muss. Die Kommunikation zwischen den Werkzeugen untereinander und zwischen Werkzeug und Anwender soll plattformübergreifend mit einheitlicher Technologie realisiert werden. Für den Anwender müssen jeweils angepasste grafische Nutzerschnittstellen bereitgestellt werden, die unabhängig von den integrierten Werkzeugen plattformübergreifend realisierbar sind und die eine globale Ergebnisdatenhaltung und Ergebnisvisualisierung gestatten. Chain3 Cycle2 Cycle4 Workflow ANSYS Saber OPAL Agent... MOSCITO Kernel Text Chart Viewer Scope Desktop Betriebssystem mit Java Virtual Machine (Windows, Solaris, Linux, Mac OS X,...) Spice Saber Servlet TOMCAT Engine Bild 2: MOSCITO-Softwarearchitektur mit offenen Schnittstellen. Betrachtet man die genannten Randbedingungen im Detail, wird deutlich, dass MOSCITO entsprechend dem Model-View-Controller-Prinzip (MVC) konzipiert und strukturiert ist. Jedes integrierte Programm nutzt zunächst sein eigenes, internes Datenmodell (Model) für die Bearbeitung einer Aufgabe. Der MOSCITO-Agent kapselt dabei werkzeugspezifische Eigenheiten und stellt nach außen alle Daten über eine einheitliche Schnittstelle dem Gesamtsystem zur Verfügung. Die MOSCITO-Infrastruktur übernimmt die Steuerfunktion (Controller). Hierzu zählen unter anderem die steuernden Funktionen der im Hintergrund arbeitenden MOSCITO-Server (Master- und Slave-Server), die in der Agentenschnittstelle realisierten Synchronisationsfunktionen und die über das jeweilige Front-End bereitgestellten Steuer- und Bedienfunktionen. Die angepassten Front-Ends entsprechen letztlich den Views im MVC-Konzept. Die Darstellung ist somit vollkommen entkoppelt von den integrierten Programmen. Sie kann optimal an die jeweiligen Einsatzbedingungen angepasst und ggf. in verschiedene Frameworks integriert werden. Als Beispiel sei der Einsatz von MOSCITO im E-Learning-Umfeld genannt, wo die in MOSCITO integrierte Simulationswerkzeuge in WBT-Module (Web-based trainings) von Lernsystemen eingebettet werden können. Für die Realisierung von MOSCITO wurde Java gewählt. Damit konnte die Plattformunabhängigkeit sowohl für die Kommunikationsfunktionen als auch für die Front-End-Komponenten gesichert werden. MOSCITO ist heute unter Solaris, Linux und Windows erfolgreich im Einsatz und kann prinzipiell

3 auf allen Plattformen installiert werden, die über eine Java-Laufzeitumgebung (Java VM Java Virtual Machine) verfügen. Bild 3: MOSCITO Desktop: Front-End- Programm zur Steuerung und Visualisierung für den Einsatz im Systementwurf. Sowohl für die Integration von Werkzeugen als auch für die Anbindung angepasster Front-Ends wurden offene Schnittstellen konzipiert. Die MOS- CITO-Software besteht damit aus folgenden Teilen: Kernel-Klassen zur Realisierung der Kommunikation, zur Registrierung und zur netzwerkweiten Suche von Diensten (Agenten) sowie zur Datenverwaltung. Front-End-Klassen für die grafischen Nutzerschnittstellen (Desktop, Scope) und für die Anbindung an Web-Infrastrukturen (Engine). API-Klassen als offene Schnittstelle zur Integration von Entwurfswerkzeugen (Agent) sowie zur Anbindung verschiedener Front-Ends (Viewer, Servlet). Bild 4: In HTML-Seiten eingebettete MOSCITO- Applets für den Einsatz im E-Learning-Umfeld. 3 Infrastruktur Sollen Entwurfswerkzeuge über das Internet genutzt bzw. untereinander gekoppelt werden, wird eine Infrastruktur benötigt, die den Datenaustausch organisiert und die, wo erforderlich, die Synchronisation zwischen den einzelnen Werkzeugen realisiert. Weiterhin muss geklärt werden, wie überhaupt ein Anwender entfernte Dienste nutzen kann bzw. wie er veranlassen kann, welche Werkzeuge sich nach einer gewünschten Topologie miteinander verbinden. All diese Aspekte sind Gegenstand der MOSCITO-Infrastruktur. Seit einigen Monaten gibt es auf dem Gebiet der Internet-basierten Nutzung von Diensten eine rasante Entwicklung. Unter dem Stichwort Web-Services wird versucht, Architekturmodelle, Protokolle, Schnittstellen und Softwareplattformen zu standardisieren und zu etablieren. Momentan ist schwer abschätzbar, welche der vielen publizierten Lösungen technologisch sinnvoll und langfristig tragfähig sind. Außerdem wird es immer weniger kalkulierbar, welche der konkurrierenden Anbieter sich letztendlich mit welchen Produkten am Markt durchsetzen und damit entscheidend die weitere technische Entwicklung bestimmen. Zum gegenwärtigen Zeitpunkt ist es folglich sinnvoll, die weitere Entwicklung der Web-Services zu verfolgen und lediglich grundlegende konzeptionelle Ansätze in die eigene Entwicklung einfließen zu lassen. Für MOSCITO spielen deshalb wie bei den Web-Services folgende drei Fragen eine zentrale Rolle: Wie wird eine Dienst (nach außen) beschrieben? Wie kann ein Dienst so registriert werden, dass er netzwerkweit von Interessenten (Clients) gefunden werden kann? Wie kann eine Verbindung zu einem gewünschten Dienst aufgebaut werden und wie erfolgt der Datenaustauscht? Im Zusammenhang mit Web-Services werden diese drei Fragen im Wesentlichen mit drei Standards beantwortet: WSDL (Web Services Description Language), UDDI (Universal Description, Discovery and Integration protocol), SOAP (Simple Object Access Protocol). Für die Realisierung von MOSCITO wurden entsprechend den genannten Fragestellungen folgende Lösungen geschaffen: Jeder MOSCITO-Agent (vergleichbar mit einem Dienst) besitzt von vornherein eine einheitliche Kommunikationsschnittstelle. Alle von außen konfigurierbaren Eigenschaften werden in einer Agentenbeschreibungsdatei in XML-Syntax

4 zusammengefasst. Auf diese Weise kann zum Beispiel dem Saber-Agenten (Kapselung des Schaltungssimulators Saber) das Schaltungsmodell und die Simulationssteuerung übergeben werden. Jeder MOSCITO-Agent wird netzwerkweit registriert. Die Anmeldung erfolgt bei einem im LAN oder Internet bekannten MOSCITO-Master-Server. Dieser ist vergleichbar mit einer UDDI- Registry. Ein Anwender erhält über den Master- Server Auskunft zu allen registrierten Diensten (Agenten). Der Start eines Agenten erfolgt über einen MOS- CITO-Slave-Server. Sämtliche Daten zwischen den Agenten einerseits und zwischen Anwender und jedem einzelnen Agenten andererseits erfolgt mit Hilfe von serialisierten Objekten. Dies ist in Java die einfachste und effizienteste Methode, beliebige Daten zwischen zwei Punkten auszutauschen. Die MOSCITO-Infrastruktur implementiert damit zwar nicht die in den letzten Monaten verabschiedeten Standards WSDL, UDDI und SOAP, sie orientiert sich aber sehr stark an der Philosophie der Web- Services. Ziel von MOSCITO ist nicht, eine allgemeine Middleware-Plattform für beliebige Einsatzgebiete zu schaffen, sondern speziell für die Remote-Nutzung und die Kopplung von Entwurfswerkzeugen eine angepasste, möglichst effiziente Lösung zur Verfügung zu stellen. Insofern besteht kein zwingender Grund, nach allen Seiten standardisierte Schnittstellen anzubieten. Dennoch ist vorgesehen so künftig der Bedarf besteht, MOSCITO über Adapter um Schnittstellen zu erweitern, die die oben genannten Standards WSDL, UDDI sowie SOAP erfüllen und somit eine Ankopplung von MOSCITO an Web-Services-Infrastrukturen ermöglichen. 4 Firewalls und Datensicherheit Mit der zunehmenden weltweiten Vernetzung der Rechentechnik wachsen gleichzeitig auch die Anforderungen an die Sicherheit. Für ein im Internet verteilt arbeitendes System wie MOSCITO sind in dieser Hinsicht drei Aspekte von besonderer Bedeutung: Lokale Netzwerke werden in der Regel durch Firewalls vor Angriffen aus dem Internet geschützt. Der Nachteil besteht mitunter darin, dass auch der gewünschte Datenaustausch behindert wird. Die MOSCITO-Kommunikation muss aus diesem Grund so organisiert werden, dass Firewall-geschützte Netzwerke sicher und kontrolliert erreicht werden können. Da bei der Nutzung von MOSCITO im Systementwurf häufig geschütztes Know-how in Form von Modellen und Simulationsdaten über das Netzwerk übertragen werden muss, ist die Sicherheit der Übertragungskanäle durch das Internet mit Hilfe angepasster Verschlüsselungsverfahren zu gewährleisten. Die MOSCITO-Server müssen jederzeit zuverlässig netzwerkweit erreichbar sein. Sie müssen tolerant gegenüber fehlerhaften Anfragen und resistent bei gezielten Angriffen aus dem Netz sein. Firewall Bild 5: Firewalls verhindern oft direkte Kommunikationsverbindungen zwischen den Partnern. Für die Lösung des Firewallproblems können folgende Varianten in Betracht gezogen werden: Alle Ports werden für die Kommunikation geöffnet. Die Firewall würde damit komplett deaktiviert werden. Diese Variante ist damit in der Praxis wenig sinnvoll. Es wird jeweils genau ein Port für die MOS- CITO-Kommunikation geöffnet. Der Port wird von einem MOSCITO-Server (Proxy) bedient, der die Daten entsprechend weiterleitet. In diesem Fall muss lediglich geklärt werden, ob bzw. welcher Port ggf. nur für ganz bestimmte Domänen geöffnet werden darf. Als Proxy-Server wird ein HTTP-Server verwendet. Die Kommunikation kann damit über den in meist offenen Port 80 mit Hilfe des HTTP-Protokolls abgewickelt werden. Hierfür muss allerdings der Web-Server um entsprechende MOSCITO-Komponenten (Servlets) erweitert werden. Die gesamte für MOSCITO relevante Datenkommunikation wird per VPN (Virtual Private Network) getunnelt. Diese Lösung setzt allerdings voraus, dass alle beteiligten Partner vorher ein solches virtuelles, privates Netzwerk aufbauen.

5 Firewall Proxy proxy-host:5001 Bild 6: Kommunikation durch eine Firewall über einen offenen Port. Ein Proxy-Server organisiert die Datenweiterleitung zum Empfänger. Die Kommunikation wird vorwiegend so organisiert, dass neue Verbindungen bzgl. der Firewall von innen nach außen aufgebaut werden. Diese Kommunikationsrichtung wird von vielen Firewalls derzeit noch nicht eingeschränkt. Allerdings lassen sich mit dieser Variante nicht alle für MOSCITO erforderlichen Kommunikationsbeziehungen realisieren. Nicht alle Rechner müssen in der Praxis die gleichen Sicherheitsanforderungen erfüllen. Mitunter ist es sinnvoll, neben gut gesicherten Netzen auch weniger geschützte Netzwerke zu betreiben. In einem solchen public LAN können dann direkt erreichbare Dienste, die nicht durch Firewalls behindert werden, betrieben werden. Firewall protected LAN public LAN Bild 7: Weniger sicherheitsrelevante Dienste können in einem Public-LAN zur Verfügung gestellt werden. Alle die genannte Varianten haben Vor- und Nachteile. Insofern kam für MOSCITO nur eine Kombination aus den vielen Lösungen in Betracht. So wurde in den letzten Monaten in der Außenstelle Entwurfsautomatisierung des Fraunhofer IIS damit begonnen, ein public LAN mit Rechnern mit unterschiedlichen Betriebssystemen (Solaris, Windows, Linux) aufzubauen. Auf diesen Rechnern können unter anderem in MOSCITO integrierte Public-Domain-Programme (z.b. Spice) sowie eigene Programme (z.b. der Optimierer OPAL) zur Verfügung gestellt werden. Weiterhin wurde in Zusammenarbeit mit der Technischen Universität Tallinn ein MOSCITO- Proxy-Server implementiert, der die MOSCITO- Kommunikation über einen offenen Firewall-Port organisiert. Auf diese Weise wird es künftig möglich sein, dass Tools, die nur innerhalb der LANs der verschiedenen Projektpartner (z.b. Uni Bremen, TU Tallinn, EAS Dresden) verfügbar sind, mit Hilfe von MOSCITO auch über Firewall-Grenzen hinweg transparent genutzt bzw. gekoppelt werden können. Die Verwendung des HTTP-Protokolls in Verbindung mit einem Web-Server findet ebenfalls Anwendung bei MOSCITO. Diese Variante wird im Zusammenhang mit den MOSCITO-Applets im Rahmen von WBTs (Web-based trainings) eingesetzt. Bei diesem Szenario benötigt der Anwender (der Lernende) lediglich einen regulären Web- Browser mit Java-Unterstützung. Der Zugriff auf MOSCITO-Dienste erfolgt über einen Web-Server Firewalls sind insofern ohne Bedeutung. Schließlich wird gegenwärtig die Kommunikation zwischen dem MOSCITO Desktop (dem Front- End-Programm) und den MOSCITO-Servern und - Agenten so umgestellt, dass alle Verbindungen vom Front-End-Programm aus geöffnet werden. Die Funktionalität wird in der nächsten Version zur Verfügung stehen und ermöglichen, dass ein Anwender auf entfernte MOSCITO-Dienste auch dann zugreifen kann, wenn er selbst hinter einer Firewall sitzt. Das zweite große Problem besteht darin, die über das Internet übertragenen Daten vor dem Zugriff durch Unberechtigte zu schützen. Der ausschließliche Einsatz von VPN oder IPsec reicht in der Praxis oft nicht aus. Erforderlich ist die Bereitstellung eigener Schutzmechanismen für die Datenkommunikation. Für MOSCITO wurden aus diesem Grund auf Basis der Java Cryptography Extensions (JCE) Verschlüsselungsfunktionen in die Kommunikationsroutinen integriert. Damit ist es möglich, den gesamten Datenstrom vor der Übertragung über das Netzwerk zu verschlüsseln und damit für Fremde unleserlich zu machen. MOSCITO arbeitet dabei mit zwei verschiedenen Schlüsseln: dem Master- Key für die Kommunikation mit den MOSCITO- Servern und einem dynamisch generierten Session- Key, der genau für eine Session gilt und der für den

6 besonders sicherheitskritischen Datenverkehr zwischen den MOSCITO-Agenten und dem Front-End (MOSCITO Desktop) eingesetzt wird. Die beschriebenen Lösungsvarianten verdeutlichen, dass es trotz wachsender Sicherheitsbedürfnisse auch künftig möglich sein wird, Werkzeuge über das Internet zu koppeln und zu nutzen. Die MOSCITO-Infrastruktur unterstützt die in diesem Zusammenhang wesentlichen Funktionen. Bei Bedarf können künftig weitere Mechanismen wie beispielsweise die Authentifizierung der Anwender sowie die Zertifizierung der angebotenen Dienste ergänzt werden. MOSCITO wurde ursprünglich mit dem Ziel entworfen, Simulationsprogramme mit Optimierungsalgorithmen zu koppeln. Folglich gibt es für die simulationsgestützte Optimierung von elektronischen Schaltungen und Mikrosystemen zahlreiche Anwendungsbeispiele: Geometrieoptimierung eines Kraftsensors auf Basis eines FEM-Modells für ANSYS [5]; Optimierung einer Mehrzellenionisationskammer unter Verwendung eines Saber-Verhaltensmodells [1]; Parameteroptimierungen für Filterschaltungen auf Basis von Saber- und Spice-Netzwerkbeschreibungen; Optimierung eines Fertigungsprozesses mit Hilfe des Programms ISSOP von Dualis. Bei den genannten Beispielen konnten verschiedene Optimierungsprogramme wie OPAL (Fraunhofer IIS, EAS Dresden), MODOS (Universität Bremen, ITEM), ISSOP (Dualis GmbH) und Matlab mit unterschiedlichen Simulationswerkzeugen flexibel über Plattform- und Netzwerkgrenzen hinweg für den jeweils erforderlichen Simulations-Optimierungs-Zyklus im Verbund erfolgreich genutzt werden. Oft war die angestrebte Entwurfsverbesserung nur mit Hilfe von MOSCITO mit vertretbarem Aufwand erreichbar. Angewandt wurde MOSCITO auch für die Testmustergenerierung im digitalen Systementwurf. Hier bestand die Herausforderung darin, die von fünf europäischen Projektpartnern entwickelten Programme so über das Internet zu einem Workflow zu koppeln, dass jeder der Partner den kompletten Workflow von seinem Arbeitsplatz aus bedienen konnte [4]. Ein weiteres Anwendungsgebiet für MOSCITO konnte mit der Einführung der MOSCITO-Applets in den letzten Monaten erschlossen werden. Im Rahmen der Aktivitäten der Fraunhofer-Gesellschaft, das in den Instituten vorliegende Know-how für die berufsbegleitende Weiterbildung unter anderem in Form von E-Learning-Kursen zur Verfügung zu stellen, bestand insbesondere die Forderung nach Online-Simulationen. Diese soll der Lernende interaktiv steuern und somit erste praxisbezogene Erfahrungen sammeln können. Mit Hilfe von MOSCITO lassen sich solche Online-Simulationen als serverseitige Ergänzungen für ein Lernportal sehr leicht realisieren. Eine erste prototypische Implementierung konnte auf der LEARNTEC 2003 in Karlsruhe demonstriert werden. 5 Anwendungsbeispiele 6 Zusammenfassung Mit MOSCITO wurde in den letzten Jahren in der Außenstelle EAS Dresden des Fraunhofer IIS eine Internet-basierte Integrationsplattform geschaffen, die es gestattet, verfügbare Entwurfswerkzeuge netzwerkweit zu Workflows zu koppeln. Neben einer flexiblen Kommunikationsinfrastruktur ermöglichen die offenen Schnittstellen eine Integration neuer Werkzeuge in das System mit wenig Aufwand. Weiterhin wurden Möglichkeiten für einen sicheren Datenaustausch auch über Firewallgrenzen hinweg geschaffen. Neben dem Einsatz von MOS- CITO für den Systementwurf konnten erste Online- Simulationen für ein E-Learning-System realisiert werden. 7 Referenzen [1] Diener, K.-H.; Huck, E.; Schneider, P.; Schwarz, P.: Entwurfsunterstützung für ein radiometrisches Messsystem Kammerelektronik und Gesamtsystemmodell. OMID-Abschlussseminar, Karlsruhe, November 2002, [2] López, P. G.; Skarmeta, A. F. G.: ANTS Framework for Cooperative Work Environments. IEEE Trans. Computer, March 2003, pp 56 [3] Müller, W.; Schattkowsky, T.; Eikerling, H.-J.; Wegner, J.: Dynamic Tool Integration in Heterogeneous Networks. Proc. DATE 2003, Munich, March 2003 [4] Schneider, A.; Ivask, E.; Miklos, P.; Raik, J.; Diener, K.-H.; Ubar, R.; Cibáková, T.; Gramatová, E.: Internet-based Collaborative Test Generation with MOSCITO. DATE 02, Paris, March 4-8, 2002, , papers/2002/003 [5] Schneider, A.; Schneider, P.; Bastian, J.: MOSCITO Ein modulares, Internet-basiertes Programmsystem für die Optimierung von Mikrosystemen. OMID-Abschlussseminar, Karlsruhe, November 2002,