Einfach Komplex – Der Software- und IT-Podcast

Dr. Julian Weller, wissenschaftlicher Mitarbeiter am Fraunhofer-Institut für Entwurfstechnik Mechatronik IEM, ist unser Gast für das Thema „Condition Monitoring“. Promoviert hat er über Prescriptive Analytics, also darüber, wie sich aus Produktionsdaten konkrete Handlungsempfehlungen ableiten lassen. In der Praxis steht man davor allerdings meist ein paar Stufen weiter unten. Zustandsüberwachung klingt nach einem langweiligen Datenthema, ist aber die Voraussetzung für alles, was danach kommt. Die klassischen Leistungsstufen reichen von deskriptiv über Diagnose und Prädiktion bis zur Präskription, und wer die erste Stufe überspringt, scheitert zuverlässig an der vierten. Zuerst geht es also darum, Maschinendaten wie Motorstrom, Anpressdruck oder Vibration überhaupt zu erfassen und zu kontextualisieren, denn ein Fehlercode 100 ohne Bedeutung ist kein Zustand, sondern nur eine Zahl.
Technisch führt der Weg von der SPS über OPC UA und die Maschinennetze der Fabrik nach außen, oder eben über ein IoT-Device mit SIM-Karte direkt an der Anlage, das den Umweg durch sieben Sicherheitszonen umgeht. Welche Variante durchsetzbar ist, hängt stark von der Branche ab, denn Automobil und Medizintechnik ticken anders als Lebensmittel oder Möbelindustrie. Dazu kommt die Frage, wer die Überwachung überhaupt betreibt. Der Komponentenhersteller, der Maschinenbauer und der Betreiber haben jeweils eigene Interessen, und wer eine Presse mit eigener Plattform kauft, hat Ofen und Roboter davor und dahinter trotzdem nicht abgedeckt. Genau deshalb entstehen daneben immer wieder Retrofit-Lösungen über die gesamte Linie.
Bei der Datenanalyse gilt eine unbequeme Faustregel: Rund zwanzig Prozent der Projektzeit gehen dafür drauf, überhaupt herauszufinden, ob in den Daten etwas Verwertbares steckt. Das läuft hypothesengeleitet und über Gespräche an der Anlage, weil deutsche Maschinen so gebaut sind, dass sie zwanzig Jahre nicht ausfallen, und damit fehlen ausgerechnet die Labels für Fehlerfälle. Alte Serviceberichte werden hier wieder interessant, weil Sprachmodelle daraus nachträglich Ausfallzeitpunkte extrahieren können. Kurios ist dabei, dass der für Menschen optimale Wartungsbericht mit Ankreuzfeldern, Abkürzungen und rotem Stift für OCR und Sprachmodelle der Albtraum ist. Bei der Ablage der extrahierten Informationen zeichnet sich ab, dass reine Textähnlichkeit über Embeddings zu kurz greift und sich Ansätze durchsetzen, die eher wie Coding-Agenten funktionieren, also strukturierte Dateien in navigierbaren Ordnerstrukturen.
In der Realität scheitern anspruchsvolle Modelle oft an Concept und Context Drift, wenn sich Hallentemperatur, Material oder der Zustand nach einem Teiletausch ändern. Deshalb laufen auf vielen Anlagen bis heute Grenzwertüberwachungen mit E-Mail-Versand statt neuronaler Netze, weil der Mehrwert fast identisch ist. Auch mehr Sensorik ist nicht automatisch besser, denn technische Verfügbarkeiten multiplizieren sich und jeder zusätzliche Sensor kann selbst zum Stillstandsgrund werden. Vibrationsanalyse per Fourier-Transformation braucht zudem Auflösung und Rechenleistung, die vor Ort meist fehlen. Am Ende zählt, ob die Überwachung auf Qualität, Leistung oder Verfügbarkeit einzahlt. Sprachmodelle setzen sinnvoll als Layer darüber an, für Auswertung, Anpassung von Visualisierungen und Analysecode, aber eben erst, wenn die Datengrundlage steht.
Links zur Folge:
Dr. Julian Weller auf LinkedIn: https://www.linkedin.com/in/julian-le-weller
Fraunhofer IEM: https://www.iem.fraunhofer.de 
---
Einfach Komplex ist ein Podcast von Heisenware.
Heisenware kennenlernen: ⁠https://heisenware.com/einfach-komplex⁠⁠⁠⁠
Kontakt: ⁠podcast@heisenware.com⁠

Zu Gast ist Yannick Reinke, IT-Freelancer aus dem Allgäu mit eigener IT-Beratung und Schwerpunkt auf Microsoft-Technologie. Es geht um eine Sortierung des Portfolios entlang von drei Blöcken: Power Platform, Fabric samt Power BI sowie Copilot. Microsoft deckt gefühlt alles ab und die Tools greifen sauber ineinander, nur kann kaum jemand noch sagen, welches davon für welchen Fall das richtige ist.
In der Power Platform ist Power Apps das Frontend, Power Automate die Prozessengine und Dataverse die Datenhaltung. Programmiert wird in Power FX, allerdings eigenschaftsweise am jeweiligen Element und nicht als zusammenhängender Code, der sich versionieren oder am Stück von einer KI korrigieren ließe. Solange SharePoint oder Microsoft Lists als Quelle dienen, ist die Standardvariante in der E3-Lizenz enthalten, mit Dataverse wird es lizenzpflichtig und als Speicher schnell teuer. Bei den Daten ist Power BI das Visualisierungswerkzeug und Fabric die Plattform darunter, die Azure Data Factory, OneLake und Synapse zusammenfasst. Der Kern der Arbeit liegt dabei nicht im Dashboard, sondern im semantischen Modell samt Row Level Security, die bis auf Zeilenebene regelt, wer was sieht, und sich bis in die Copilot-Antworten durchzieht.
Beim dritten Block hilft es, die verschiedenen Dinge auseinanderzuhalten, die Microsoft alle Copilot nennt: den integrierten Copilot in Word, Excel, Teams und Outlook, den Copilot Chat mit Webwissen, Copilot Studio für Agenten auf eigener Knowledge Base und Microsoft Foundry, früher Azure AI Foundry, als Pro-Code-Plattform mit freier Modellauswahl. Dazu kommen die Frage nach Determinismus, wenn die Antwort eigentlich eine belastbare Zahl sein soll, und der Hinweis, dass acht von zehn vermeintlichen KI-Fällen in Wahrheit regelbasierte Workflows sind.
Links zur Folge:
IT-Beratung Reinke: https://www.it-beratung-reinke.de
Yannick Reinke auf LinkedIn: https://www.linkedin.com/in/yannick-reinke-7688b2198/
------
Einfach Komplex ist ein Podcast von Heisenware.
Weitere Infos und ein kostenloser Test: https://heisenware.com/einfach-komplex
Kontakt: podcast@heisenware.com

TypeScript ist keine eigene Programmiersprache, sondern ein Typsystem über JavaScript, das beim Kompilieren wieder verschwindet. Am Ende läuft Vanilla JavaScript. Genau daran hat sich Burkhards jahrelange Skepsis entzündet: C++ zwingt Euch, alles zu typisieren, JavaScript wurde unter anderem erfunden, um diesen Ballast loszuwerden, und TypeScript schraubt ihn wieder obendrauf. Entstanden ist es bei Microsoft unter Anders Hejlsberg, dem Architekten hinter Turbo Pascal, Delphi und C#, von Anfang an öffentlich unter Apache-2.0-Lizenz.
Anders als die nominalen Typsysteme von Java oder C++ typisiert TypeScript strukturell, umgangssprachlich Duck Typing: Wenn die Form stimmt, passt der Typ. Der Compiler tsc führt nichts aus, er prüft nur die Konsistenz und meldet Fehler bereits in der IDE statt erst zur Laufzeit. Damit verschwinden die Klassiker, die Ihr sonst erst im Betrieb seht, etwa ein undefined mitten in der UI-Maske oder eine weiße Seite im Frontend. Wer nicht erzwingen will, kann bei JavaScript plus JSDoc bleiben und Typen nur dokumentieren. Testabdeckung ersetzt das übrigens nicht, Typisierung und Tests sind zwei orthogonale Dimensionen.
Der Auslöser für die Umstellung der Heisenware-Engine von Node.js mit Vanilla JavaScript auf TypeScript war allerdings KI. TypeScript ist alt genug für massive Präsenz in den Trainingsdaten, der vorhandene Code ist durch den Compiler-Check überdurchschnittlich sauber, und semantische Typnamen wie User oder ProductionOrder machen eine Codebase für ein LLM lesbar wie Fließtext. Ein durchdefinierter Typ lässt der KI keinen Interpretationsspielraum, und für Tool Calling und MCP lassen sich JSON-Schemata direkt aus den Typen ableiten. Wie schnell sich hier etwas bewegt, zeigt der Compiler selbst: Unter dem Codenamen Corsa nach Go portiert, um echtes Multithreading zu nutzen, ist TypeScript 7.0 am 8. Juli 2026 allgemein verfügbar geworden, mit Beschleunigungsfaktoren von acht bis zwölf bei vollen Builds.
Links zur Folge:
https://www.typescriptlang.org
https://github.com/microsoft/TypeScript
https://github.com/microsoft/typescript-go
---
Einfach Komplex ist ein Podcast von Heisenware.
Heisenware kennenlernen: https://heisenware.com/einfach-komplex
Kontakt: podcast@heisenware.com

Wir begrüßen Stefan Herrmann, VP Product bei Cybus, als unseren Gast für das Thema Unified Namespace, kurz UNS. In vielen Industrieunternehmen wächst die IT- und OT-Landschaft über Jahre hinweg organisch, was meist in starren Punkt-zu-Punkt-Verbindungen, Gateways mit unterschiedlichen Softwareständen und unstrukturierten Daten endet. Ein Unified Namespace löst dieses Integrationschaos, indem er als standardisiertes, integriertes Konzept alle Geräte, Senkrechten und Datenströme innerhalb eines Netzwerks einheitlich benennt und organisiert. Daten erhalten dadurch einen festen, vorhersehbaren Platz, wodurch Applikationen von direkten End-zu-End-Verbindungen entkoppelt werden.
Im Gegensatz zu einer klassischen Datenbank fungiert ein Unified Namespace als reiner Live-Datenstrom für Echtzeitdaten, an den Langzeitspeicher wie Historians oder Analysetools modular angedockt werden. Technisch basiert diese Architektur auf MQTT und einem zentralen Broker als Drehscheibe im Publish-Subscribe-Verfahren. Über hierarchisch verschachtelte Adressierungen, sogenannte Topics, lassen sich Datenstrukturen vom Werk über die Linie bis hin zum einzelnen Sensor logisch abbilden. Das ermöglicht eine eventgetriebene Kommunikation, bei der Funktionen wie Retained Messages den letzten bekannten Zustand puffern oder Last Will and Testament automatische Offline-Meldungen bei Verbindungsabbrüchen absetzen.
Da im industriellen Umfeld strenge Sicherheitsvorgaben gelten, wird die Zugriffssteuerung über ein rollenbasiertes Access-Management bis auf den einzelnen Datenpunkt granular geregelt und an bestehende IT-Benutzermanagements wie LDAP oder Entra-ID gekoppelt. Um diese menschliche und technische OT-IT-Konvergenz in Eurer Fertigung erfolgreich umzusetzen, ist eine klare Konvention notwendig. Hierfür empfiehlt sich der Aufbau einer übergreifenden Taskforce oder eines Center of Excellence, das OT, IT und die fachlichen Prozessverantwortlichen an einen Tisch bringt.
Links zur Folge
Cybus https://cybus.io
Stefan auf LinkedIn https://www.linkedin.com/in/stefanhermannberlin
---
Einfach Komplex ist ein Podcast von Heisenware.
Heisenware kennenlernen: ⁠https://heisenware.com/einfach-komplex⁠⁠⁠⁠
Kontakt: ⁠podcast@heisenware.com

Wer Software, Firmware oder digitale Komponenten für die Industrie auf den Markt bringt, haftet künftig über den gesamten Produktlebenszyklus für die IT-Sicherheit. Der Cyber Resilience Act (CRA) der EU macht Cybersicherheit von der optionalen Produkteigenschaft zur harten gesetzlichen Pflicht. Das betrifft Embedded-Systeme im Schaltschrank genauso wie SCADA-Plattformen oder industrielle Cloud-Anwendungen. Gemeinsam mit Benjamin Becker von abl solutions ordnen wir die rechtlichen und technischen Anforderungen ein.
Das akuteste Thema des CRA ist die neue Meldepflicht, die bereits im September 2026 in Kraft tritt. Aktiv ausgenutzte Schwachstellen müssen innerhalb von nur 24 Stunden an die europäische Cybersicherheitsbehörde ENISA gemeldet werden, was vollkommen neue interne Prozesse in den Unternehmen erfordert. Dabei gilt im Audit ein unerbittliches Prinzip: Was nicht dokumentiert ist, existiert regulatorisch nicht. Jede Risikoanalyse und jede Architekturentscheidung muss lückenlos nachweisbar sein.
Ein zentraler Baustein ist das kontinuierliche Schwachstellen-Management über eine automatisierte Software Bill of Materials (SBOM). Damit lassen sich Abhängigkeiten und bekannte Sicherheitslücken in externen Komponenten oder Open-Source-Bibliotheken fortlaufend überwachen. Entscheidend ist dabei die Frage, wie sich diese automatisierten Risikoanalysen so in die CI/CD-Pipeline integrieren lassen, dass sie die Entwicklungsgeschwindigkeit nicht blockieren und die gesetzliche Konformität innerhalb der dreijährigen Übergangsfrist sichergestellt wird.
Links zur Folge
Benjamin auf LinkedIn: https://www.linkedin.com/in/benjaminbecker2/
Website abl solutions: https://abl-solutions.com/
Website Pallax-Plattform: https://pallax.io/
------
Einfach Komplex ist ein Podcast von Heisenware.
Kontakt: ⁠podcast@heisenware.com⁠
Heisenware kennenlernen: ⁠https://heisenware.com/einfach-komplex⁠⁠⁠⁠