Themen Aktueller Stand der Entwicklung Geplante Entwicklungen ASAM ODS Aktivitäten Verteilte Systeme mit ASAM ODS

Transkript

1 ATHOS Benutzertreffen Report of the Lab Glashütten, 9. November 2011 HighQSoft GmbH, Karst Schaap / 9 November

2 Themen Aktueller Stand der Entwicklung Geplante Entwicklungen ASAM ODS Aktivitäten Verteilte Systeme mit ASAM ODS 9 November

3 Aktueller Stand der Entwicklung Abgeschlossene Entwicklungen Allgemeine Erweiterungen 9 November

4 Aktueller Stand der Entwicklung Abgeschlossene Entwicklungen Session Notification, Aufruf eines Plugins wenn eine Session sich an- oder abmeldet oder demnächst geschlossen wird. Optimierung von deleteinstances. Verwendung von IN-Table. Optimierung des Ladens von Werten von den LocalColumns bei ExternalComponents. Konfigurierbare LOG-Handler, neben EventViewer und File können die Fehler auch in einen LOG- Service geschrieben werden. 9 November

5 Aktueller Stand der Entwicklung Abgeschlossene Entwicklungen Schreiben mit ValueMatrix Interface. DB_PASSWORD in INI-File kodieren. Weitere Readonly Kontextvariablen, wie SESSIONID, IdlCompiledBy, CorbaImplementation... UTF-8 Support mit JacORB 9 November

6 Aktueller Stand der Entwicklung Database Windows 32-Bit Windows 64-Bit Linux 64-Bit Oracle 8.1 Ja Nein Nein MSVC 6.0 Oracle 9.2 Ja Nein Ja MSVC 6.0 Oracle 10g Ja Ja Ja MSVC 6.0 MSVC2005 Oracle 11g Ja Ja Ja MSVC2005 GCC 4.5 MSSQL 2008 Ja Nein Nein MSVC 6.0 MSVC November

7 Aktueller Stand der Entwicklung Weitere Randbedingungen: Java 1.5 oder 1.6 für 32-Bit oder 64-Bit. Oracle Client passend für die Datenbankversion mit 32-Bit oder 64-Bit Binaries. CORBA, SunORB oder JacORB Verwendung von SSL Verwendung von Portbereichen bei der Firewall. MDF 3 steht nur auf Windows für 32-Bit zur Verfügung. 9 November

8 Aktueller Stand der Entwicklung Programme für openmdm: Avalon, verwendet ATHOS Binaries. Notification, Voraussetzung JacORB CorbaFileServer NumberGenerator Die oben genannten Programme sind in Java geschrieben die sowohl mit Java 1.5 als auch mit Java 1.6 laufen. 9 November

9 Aktueller Stand der Entwicklung OSGi-Komponenten Basierend auf Declarative Services (OSGi #112) ConfigAdmin (OSGi #106) Zentrales Logging (OSGi #101) Preferences (OSGi #104) CORBA Registry ODS Zugriff Scheduler 9 November

10 Aktueller Stand der Entwicklung Kundenprojekte Archivierung für AUDI, BMW, Daimler Bosch - AFB, Importer und Exporter Bosch - PLCD, Host und Testbedserver auf Basis von OSGi. Catwalk Pflege für Bosch und Daimler 9 November

11 Aktueller Stand der Entwicklung Allgemeine Erweiterungen Weitere interne Optimierungen Weitere Tests (junit) für Avalon Neue Regeln für ModelMapper Tools für ODS konforme Modifikation der Datenbank Ablage. 9 November

12 Geplante Entwicklungen Prototyp für ASAM ODS 5.3. Weitere OSGi Komponenten. Kundenprojekte. 9 November

13 ASAM ODS Aktivitäten Maintenance für 5.2 ist abgeschlossen ist FVD für 5.3. mit UTF8 Unterstützung Managed files, Filetransfer und Löschen von Dateien Erweiterungen für MDF 4 (Bit-Lesen) Neue Basisattribute für Administration Suchen auf Werte bei LocalColumn zusammen mit 'Nested Queries' Notification Disable von Benutzern 9 November

14 Verteilte ODS Systeme Durch Zunahme der verteilten Entwicklung und Zugriff auf gemeinsame Daten werden die verteilten ODS Systeme immer wichtiger. Hinzu kommen Tests (z.b Testfahrten) außer Haus, die in eine gemeinsame Ablage gespeichert werden müssen. Entwicklung oder Erprobung bei Zulieferfirmen, die auch Auswertung durchführen müssen, jedoch ohne Zugriff auf OEM Netzwerk. 9 November

15 Verteilte ODS Systeme Zentrales Prüffeld mit zentralem ODS Server zusammen mit mehreren dezentralen Prüfbänken oder Prüffeldern. Die Datenmenge einzelner Messungen ist gering. Die Auswertung muß zentral und dezentral mit den gleichen Werkzeugen möglich sein. Daten werden in der zentralen Datenbank gespeichert. Netzwerk ist zwischen dem zentralen und den dezentralen Prüffeldern dauernd vorhanden. Dezentral werden häuptsächlich die lokalen Messungen ausgewertet. 9 November

16 Verteilte ODS Systeme Lösung: Zentral und dezentral jeweils einen eigenen ODS Server mit Oracle Datenbank. Die Daten werden mit Oracle Tools von der dezentralen Datenbank in die zentrale Datenbank kopiert. Voraussetzung: Alle ODS Server verwenden die gleichen Sequenzen zur Vergabe der Id der Instanzen, damit diese über alle Datenbanken eindeutig (unique) sind. 9 November

17 Verteilte ODS Systeme An verschiedenen Standorten gibt es große Datenaufkommen. Auswertung wird im Allgemeinen am jeweiligen Standort gemacht. Kleine Teile dieser Daten werden an allen Standorten ausgewertet. MixedMode wird verwendet. Netzwerk ist zwischen den Standorten vorhanden. Lösung: Eine zentrale Datenbank und an allen Standorten ein ODS Server mit lokalen Dateien. Die verschiedenen ODS Server können auf die lokale Dateien der anderen Standorte zugreifen. 9 November

18 Verteilte ODS Systeme Voraussetzung: Dateien werden in FILE_MODE=MULTI_VOLUME abgelegt. Jeder ODS Server hat ein andere FILE_ROOT und die Symbols sind so eingestellt, dass auf die Dateien der jeweils anderen Standorte zugegriffen werden kann. Gute lokale Auswertungen damit sichtbar wird, welche Teile der Daten von Bedeutung sind. Intelligente Clients, die nur die interessanten Teile der Daten laden. 9 November

19 Verteilte ODS Systeme Zentrale Ablage für Messdaten von Testfahrten. Testfahrten werden entfernt von der Zentrale durchgeführt. Auswertungen müssen identisch sein. Verwendung der Kataloge aus der zentralen Ablage. Vergleiche mit SOLL-Werten aus der zentralen Ablage sind auch entfernt notwendig. Es gibt kein Netzwerk mit der zentrale Ablage. 9 November

20 Verteilte ODS Systeme Lösung: Auf einem mobilen System eine identische Installation wie in der Zentrale. In der Zentrale wird das mobile System aufgesetzt und die SOLL-Werte und Kataloge werden aus der zentralen Ablage kopiert. Während der Testfahrt werden die Messergebnisse ins mobile System importiert und lokal ausgewertet. Nach Beendigung der Testfahrten werden die Messergebnisse dann in die zentrale Ablage kopiert. 9 November

21 Verteilte ODS Systeme Voraussetzungen: Skalierung der eingesetzten Software. Installer um mobiles System schnell aufzusetzen. Kopieren von Katalogen und SOLL-Werten muss implementiert werden. Schneller Import, damit große Menge an Messergebnisse zeitnah importiert werden. Wenn während der Testfahrten bereits Messergebnisse an die Zentrale gesendet und dort importiert wurden, muss der Importer dieses erkennen. 9 November

22 Vielen Dank für Ihre Aufmerksamkeit