Archiv der Kategorie: Tipps & Tricks

KI-Leuchtturm-Projekt „FutureForest“ zum klimaangepassten Waldumbau wird mit 2.5 Millionen Euro gefördert

Das Projektteam

Unter der Leitung des Darmstädter Start-Ups wetransform GmbH sollen, zusammen mit den Projektpartnern FU Berlin, TU München sowie von ECOSOPH GmbH (München) und M.O.S.S. Computer Grafik Systeme GmbH (Taufkirchen), KI-Verfahren entwickelt werden, um Daten zum Zustand des Waldes zu erfassen und auszuwerten sowie Entscheidungsprozesse beim klimaangepassten Waldumbau zu unterstützen.

Unterstützt werden sie von assoziierten Partnern wie dem Thünen-Institut für Waldökosysteme, der forstlichen Versuchsanstalt Baden-Württemberg und das Julius-Kühn-Institut. Das auf drei Jahre ausgelegte Projekt wird vom Bundesministerium für Umwelt und Verbraucherschutz mit insgesamt 2.5 Millionen Euro gefördert.

Ziele des Forschungsvorhabens

Mit diesem Projekt gehen die Forschenden eine wichtige und dringende Herausforderung an: extreme Hitze, langanhaltende Trockenheit, Starkregen, Schädlingsbefall, aber auch Schadstoffe belasten den deutschen Wald.

Um Ökosystemleistungen wie die Nutz-, Schutz- und Erholungsfunktion unserer Wälder auch zukünftig zu erhalten, müssen Waldbesitzende und Forstfachleute in den nächsten Jahren weitreichende, waldbauliche Entscheidungen treffen:

  • Welche meiner Waldbestände sind besonders gefährdet?
  • Welche Baumarten können an diesem Standort zukünftig noch gedeihen?
  • Wie kann ich auch zukünftig Funktionen wie Artenvielfalt und den Erholungswert des Waldes sicherstellen?

Aufgrund der raschen Veränderung des Klimas können sie sich dabei nicht nur auf ihre Erfahrungen verlassen, sondern müssen alle zur Verfügung stehenden Daten kontinuierlich sammeln und auswerten können.

Ein Wald-Datenraum für ganz Deutschland

Konkret werden Daten zur Baumartenzusammensetzung und Vitalität, sowie Boden- und Klimadaten erfasst, vereinheitlicht und mit Hilfe der KI-Methoden analysiert. In einem weiteren Schritt werden für ganz Deutschland Waldumbaumaßnahmen im Klimawandel simuliert und analysiert.

Somit erhalten Waldbesitzende, Försterinnen und Förster, Consultants und Forschende Handlungsempfehlungen zu Bewirtschaftung und Baumartwahl, die an den jeweiligen Standort und den aktuellen Waldzustand angepasst sind. Da Verfahren der Erklärbaren KI zum Einsatz kommen, werden diese Empfehlungen nachvollziehbar und bewertbar sein. Damit wird ein aktiver Beitrag dazu geleistet, dass unsere Waldökosysteme den Herausforderungen des Klimawandels in Zukunft besser gewachsen sind.

Da KI-Methoden nur so gut wie die zu analysierenden Daten sein können, umfasst das Projekt auch die Errichtung eines Datenraums für Sensordaten, Fernerkundungsdaten, Klimadaten sowie Daten aus der Standortskartierung. Dieser Datenraum ermöglicht es allen Akteuren, ihre Daten miteinander zu teilen, ohne die Kontrolle und Souveränität über diese aufgeben zu müssen.

Allgemeine Informationen zur Förderinitiative

Die BMUV-Förderinitiative ist Teil des Fünf-Punkte-Programms „Künstliche Intelligenz für Umwelt und Klima“ und ein Beitrag zur Umsetzung der KI-Strategie der Bundesregierung mit dem Ziel, Deutschland und Europa zu einem führenden Standort für KI-Technologien zu machen und dabei eine verantwortungsvolle und gemeinwohlorientierte Entwicklung und Nutzung von KI voranzubringen. Das Bundesumweltministerium fördert damit Projekte, die Künstliche Intelligenz nutzen, um ökologische Herausforderungen zu bewältigen und beispielgebend sind für eine umwelt-, klima-, gesundheits- und naturgerechte Digitalisierung ("KI-Leuchttürme"). Weitere Informationen zur Initiative erhalten Sie unter

https://www.bmuv.de/themen/nachhaltigkeit-digitalisierung/digitalisierung/unsere-foerderinitiative-ki-leuchttuerme

Tipps & Tricks WEGA: Inbetriebnahme WEGA 10 Client und Parallelbetrieb mit WEGA 9 Client

Überblick

Der neue WEGA 10 Client kann problemlos parallel zum WEGA 9 Client betrieben werden. Beide Clienten nutzen die serverseitigen Komponenten von WEGA gemeinsam, also WEGA-RBA, -EMS, -PPS.

Der WEGA 10 Client ist der Web-Client der nächsten Generation auf Basis aktueller Web-Technologien:

  • react - JavaScript-Softwarebibliothek (Open Source): Grundgerüst für Ausgabe von User-Interface-Komponenten von Webseiten; Oberflächen auf Basis der react-Komponente "Material-UI"; Ablösung des „Dojo Toolkit“ (seit 2004 im Einsatz)
  • ArcGIS JS API 4 - JavaScript-Softwarebibliothek (Fa. ESRI): Erstellung von WebApps mit ArcGIS Inhalten u. Funktionen; Integration von 2D/ 3D, Abfrage von Layern und räumliche Analysen
  • Cesium: Realisierung der 3D Technologie (Open Source)

Auslieferung / Installation

Der WEGA 10 Client ist ab dem Herbstrelease 2021 Bestandteil des Lieferumfangs von WEGA und kann optional mitinstalliert werden. Dazu muss einfach die Komponente „WEGA-Client“ im WEGA Setup aktiviert werden.

Installation des WEGA 10 Clients im WEGA Setup
Installation des WEGA 10 Clients im WEGA Setup

Im Ergebnis werden zwei parallele Tomcat Servlets sowie zugehörige Verzeichnisse für die Web-Clienten installiert.

Parallel installierte WEGA-Clients
Parallel installierte WEGA-Clients

Konfiguration via WEGA RBA

Es erfolgt zunächst eine Basiskonfiguration mit einer Rolle sowie einer Datenquelle, damit der WEGA 10 Client grundsätzlich startet. Bei zusätzlich installiertem WEGA 10 Client sind insgesamt zwei Projekte vorhanden:

  • "wegabase" (=WEGA 9 Client)
  • "wegaclient" (= WEGA 10 Client)
RBA-Konfiguration der WEGA-Clients
RBA-Konfiguration der WEGA-Clients

Für das Projekt "wegaclient" ist zunächst eine Rolle zu erstellen sowie mindestens eine Datenquelle zu registrieren:

  • Auswahl des Projekts "wegaclient" -> Projekt bearbeiten
  • Karteireiter "Rollen" -> hinzufügen einer neuen Rolle (hier "Erfassung10")
WEGA RBA Rolle erstellen und Datenquelle registrieren
WEGA RBA Rolle erstellen und Datenquelle registrieren

Karteireiter "WMS" -> registrieren einer neuen WMS-Datenquelle

Registrierung der WMS-Datenquelle
Registrierung der WMS-Datenquelle

Nach der auch bei WEGA 9 bekannten Verfahrensweise wird die WMS-Datenquelle zur neuen Rolle als WMS-Datenquellengruppe registriert und anschließend in die Liste der Kartendienste eingetragen.

WMS-Datenquellgruppe registrieren
WMS-Datenquellgruppe registrieren

Nach Abschluss der RBA-Konfiguration sind die Änderungen freizuschalten.

Änderungen freischalten
Änderungen freischalten

Konfiguration Nutzerverwaltung

Der neu erstellten Rolle für den WEGA 10 Client muss ein Nutzer zugeordnet werden. Das Servlet muss danach neu gestartet werden. Beispiel für shiro.ini:

[users]
myUser = myUserPW, Erfassung10, nFUser

Aufruf WEGA Client

WEGA 9: http://localhost:8080/wega-base/
WEGA 10: http://localhost:8080/wega-client/

Fazit

Mit dem WEGA 10 Client ist der Web-Client der nächsten Generation verfügbar. Dies betrifft sowohl die überarbeitete Funktionalität mit fokussierter Nutzerführung, Homogenisierung der GUI bzgl. Diensttypen und Funktionalitäten, einheitlichem Sachdatenhandling und der Ablage/Portierung von Konfigurationen mittels Arbeitsprojekten, als auch die Nachhaltigkeit der verwendeten Frameworks. Der WEGA 10 Client kann parallel zum WEGA 9 Client betrieben werden. Die Administration sowie Konfiguration ist für beide Clienten mit der bereits bekannten GUI von WEGA-RBA möglich.

Tipps & Tricks novaFACTORY & WEGA – Transportverschlüsselung

Transportverschlüsselung?
Transportverschlüsselung stellt in der IT-Sicherheit die Verschlüsselung der Daten während dem Transport der Daten zwischen zwei Servern oder einem Server und dem Client dar. Dabei handelt es sich um eine Punkt-zu-Punkt-Verschlüsselung. Bekanntestes Beispiel für eine Transportverschlüsselung ist HTTPS, bei dem das eigentlich unverschlüsselte HTTP durch einen TLS-Tunnel verschlüsselt übertragen wird.

Im Folgenden wird die Einrichtung von HTTPS für novaFACTORY und WEGA unter dem Betriebssystem Windows beschrieben.

Voraussetzungen
Die Verwendung von HTTPS setzt die Benutzung eines X.509-Zertifikats für den Server voraus. Mit diesem Zertifikat weist sich der Server gegenüber dem Client aus. Auf Basis des Zertifikats kann der Client beim Aufbau der Verbindung beurteilen, dass die Kommunikation mit dem richtigen Server aufgebaut wird. Dazu muss das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) explizit für den abzusichernden Server ausgestellt worden sein. Zum Zertifikat gehört grundsätzlich ein serverspezifischer, privater Schlüssel, auf dessen Basis die Anfrage bei der CA zur Ausstellung des Zertifikats gestellt wurde.

Bei der Zertifizierungsstelle kann es sich sowohl um eine öffentliche oder eine interne Stelle handeln. Eine öffentliche CA stellt Zertifikate aus, die von jedem Browser als vertrauenswürdig eingestuft werden. Diese Zertifikate kommen in der Regel bei Servern zum Einsatz, die aus dem Internet erreichbar sein sollen. Eine interne CA stellt in der Regel Zertifikate aus, die nur im Behörden- oder Firmenintranet akzeptiert werden. Eine CA besitzt ebenfalls ein Zertifikat, dem explizit das Vertrauen ausgesprochen werden muss. Bei öffentlichen Stellen, sind diese in der Regel bereits im Browser bzw. im System hinterlegt. Bei internen CAs muss dies durch die Systemadministration z.B. durch das Active Directory erledigt werden.
Für Zertifikate gibt es verschiedene Dateiformate, in denen das Zertifikat und der dazugehörige Schlüssel vorliegen können. Unter Windows hat sich das Format „PKCS 12“ als Standard etabliert. Dieses ist an der Dateiendung „.p12“ oder „.pfx“ erkennbar. Dieses Format enthält das Zertifikat und den dazugehörigen Schlüssel in einer einzelnen Datei, womit die Einrichtung stark vereinfacht wird.

Zertifikatsspeicher in Windows
Unter Windows gibt es zwei Zertifikatsspeicher: Einen Speicher für den Benutzer und einen Speicher für den Computer. Im Computerspeicher sind normalerweise die beglaubigten Zertifikate der CAs hinterlegt. Im persönlichen Speicher des Benutzers hingegen werden die Zertifikate hinterlegt, für die der Anwender einen privaten Schlüssel besitzt. Aus Sicht von novaFACTORY und WEGA handelt es sich bei „dem Benutzer“ um die Betriebssystembenutzer, unter dem die Windowsdienste – speziell der Apache Tomcat – laufen.

Für die Einrichtung von HTTPS für novaFACTORY und WEGA muss daher zuerst das Zertifikat mit dem dazugehörigen Schlüssel in den persönlichen Zertifikatsspeicher des Dienstebenutzers importiert werden. Bei Vorliegen einer pfx-Datei passiert dies am einfachsten durch Doppelklick auf die Datei. Alternativ kann die Konfigurationskonsole „certmgr.msc“ als Dienstebenutzer gestartet und der Import manuell durchgeführt werden. Es ist wichtig, dass das Zertifikat in den persönlichen Speicher des Benutzers importiert wird.

Windows Zertifikat

Nach dem Import wird das Zertifikat in der Zertifikatskonsole von Windows angezeigt. Dabei wird der Servername angezeigt, für den das Zertifikat ausgestellt wurde. Dabei handelt es sich um den sogenannten Common Name (CN). Dieser wird später noch benötigt.

Konfiguration in Apache Tomcat
Da sowohl novaFACTORY als auch WEGA die Servlet Engine Apache Tomcat für die Auslieferung der Weboberfläche benutzen, erfolgt die eigentliche Einrichtung von HTTPS in selbiger Software. Dazu ist in der Konfigurationsdatei conf\server.xml in der Installation des Apache Tomcat folgender „Connector“ zu konfigurieren:

<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
  sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
  maxThreads="150"
  SSLEnabled="true"
  scheme="https"
  secure="true"
  keyAlias="<CN_des_Zertifikats>"
  keystoreFile=""
  keystorePass=""
  keystoreType="Windows-My"
  clientAuth="false"
  sslProtocol="TLS"
  sslEnabledProtocols="TLSv1.2"
  keepAliveTimeout="200000" />

Beim Parameter keyAlias ist der Common Name des Zertifikats einzutragen. Der keystoreType „Windows-My“ stellt den persönlichen Zertifikatsspeicher des Dienstebenutzers dar, in den das Zertifikat vorher importiert wurde. Die leeren Parameter zum Zertifikatsspeicher sind aufgrund eines Bugs notwendig. Die aktivierten Protokolle („sslEnabledProtocol“) sind mit der IT-Administration abzustimmen. Beim Einsatz moderner Browser kann die o.a. Konfiguration verwendet werden.
Zusätzlich muss die Java-Ausführungsumgebung für den Apache Tomcat so angepasst werden, dass die Windows-Zertifikatsspeicher verwendet werden können. Die Konfiguration erfolgt im Tomcat-Monitor im Reiter „Java“. Dort müssen folgende Parameter unter „Java Options“ ergänzt werden

-Djavax.net.ssl.trustStoreProvider=SunMSCAPI
-Djavax.net.ssl.trustStoreType=Windows-ROOT
-Djavax.net.ssl.keyStoreProvider=SunMSCAPI
-Djavax.net.ssl.keyStoreType=Windows-MY
-Dcom.sun.security.enableAIAcaIssuers=true

Hier wird festgelegt, dass für die beglaubigten CA-Zertifikate der Zertifikatsspeicher des Computers verwendet wird („Windows-ROOT“). Zusätzlich wird nochmals der Zertifikatsspeicher des Dienstebenutzers für die Zertifikate mit privatem Schlüssel angegeben („Windows-MY“). Der letzte Parameter ermöglicht eine zusätzliche Suchmöglichkeit nach CA-Zertifikaten, die die AIA-Erweiterung der Zertifikate nutzt. Diese Erweiterung ist z.B. für den OpenStreetmap-WMS von Terrestris notwendig.

Mit diesen Konfigurationsoptionen wird der integrierte Zertifikatsspeicher der Java JRE deaktiviert und nur noch auf die in Windows eingebauten Speicher zugegriffen. Wenn Sie Zertifikate in Java importiert haben, müssen diese damit in Windows importiert werden. Vorteil ist, dass die Zertifikate und Schlüssel auch ein Update der JRE überstehen, das den dortigen Zertifikatsspeicher überschreibt.
Nach einem Neustart des Apache Tomcat stehen die Weboberflächen von novaFACTORY und / oder WEGA damit unter HTTPS zur Verfügung.

WEGA-AuthService
Wenn Sie den WEGA-AuthService mit einem Active Directory verbunden haben, dann kann auch dort die Transportverschlüsselung für die Kommunikation mit den Domänen Controllern konfiguriert werden. Dabei kommt im Gegensatz zur Kommunikation im Browser das Protokoll LDAPS zum Einsatz.

Ausgehend von obiger Konfiguration im Apache Tomcat ist nur eine Zeile in der Konfigurationsdatei shiro.ini des WEGA-AuthService zu ändern und eine Zeile hinzuzufügen.

ldapContextFactory.environment[java.naming.security.protocol] = ssl
ldapContextFactory.url = ldaps://<DC-Servername>:636

Die erste Zeile aktiviert dabei die Transportverschlüsselung für die Kommunikation mit dem Active Directory. Der Wert „ssl“ ist hier historisch zu sehen. Auf modernen Systemen wird tatsächlich ein Tunnel mittels TLS aufgebaut. In der zweiten Zeile ist die Adresse des Domain Controllers eingetragen Wichtig sind hier der Protokollname „ldaps“ und der Port 636 über den anschließend die verschlüsselte Verbindung läuft.

Nach der Änderung der Konfiguration ist ein Neustart des Apache Tomcat notwendig. Da die Clients nicht direkt mit dem Active Directory kommunizieren, sind dort keine Änderungen notwendig. Wenn der WEGA-AuthService per HTTPS erreichbar ist, kann aber dort die URL zum Dienst entsprechend angepasst werden.

Schlusswort
Die Einrichtung einer verschlüsselten Kommunikation ist in modernen Infrastrukturen problemlos möglich. Dabei können sowohl öffentliche Zertifikate für das Internet als auch private Zertifikate im Intranet zum Einsatz kommen.
Wenn Sie Fragen haben, kommen Sie gerne auf uns zu.

Tipps&Tricks Inbetriebnahme von WEGA unter Docker

Tipps&Tricks novaFACTORY 3D preVIEW

Tipps&Tricks novaFACTORY und WEGA