TOP
SSV Software Systems Register  Register
Log in to check your private messages  Log in to check your private messages
Startseite FAQ Search Mitglieder Profile  Log in 
SSV Support-Forum
CAD-Funktionsblock …

 
Post new topic   Reply to topic    SSV-Forum Forum Index >>> DNP/8331, eDNP/8331
<<< Previous topic - Next topic >>>  
Display posts from previous:   
Author Message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 23.12.2022, 17:42    Post subject: CAD-Funktionsblock … Reply with quote

Hallo Forum.

Es wurde ja bereits mehrfach angekündigt, dass der DNP/8331 nicht nur physisch im DIL-40-Modulformat zur Verfügung steht, sondern darüber hinaus auch virtuell als Altium-CAD-Funktionsblock (mit Altium ist der Altium Designer gemeint, also das PCB-Design-System des gleichnamigen Unternehmens, siehe https://de.wikipedia.org/wiki/Altium_Designer). Inzwischen sind die Entwicklungsarbeiten soweit fortgeschritten, dass erste Integrationsergebnisse verifizier- und validierbar sind. Die folgende Abbildung zeigt ein Beispiel:



Rechts ist ein Foto des DNP/8331 zu sehen. Zu diesem DIL-40-Modul stellen wir über ein Lizenzverfahren sowohl das Schaltbild als auch das 6-Lagen-Layout als sogenanntes „Altium-Snippet“ zur Verfügung. Snippets sind im Altium Designer eine Methode, um ein Design wiederzuverwenden (Design Reuse).

Links daneben ist die Altium-CAD-Darstellung der Unterseite einer Anwenderschaltung abgebildet, in die das DNP/8331-Snippet integriert wurde. Auf der Oberseite dieser Baugruppe befindet sich ein M.2-Steckplatz für Kommunikationsmodule, die per USB mit dem S3-ARM-SoC verbunden sind.

Als Zubehör zum Snippet wird ein vollständig angepasstes Debian-Linux mit einem Embedded-Edge-Gateway-Firmware-Image für Mikro-SD-Karten angeboten. Zur Firmware gehört auch eine Python-3-Laufzeitumgebung. Damit lassen sich selbstentwickelte Firmware-Erweiterungen einfach in das Gesamtsystem einbinden.

Gerätehersteller, Maschinen- und Anlagenbauer, die für ihre Produkte eigene Elektronikbaugruppen entwickeln, werden durch den virtuellen DNP/8331 in die Lage versetzt, hochwertige IoT-Kommunikations- und Servicefunktionen mit dem maximal möglichen Kostenvorteil direkt in ihre Elektronik einzubinden. Als Stückkosten fallen je nach Lizenz lediglich die aktuellen Preise der elektronischen Bauelemente sowie der individuelle Bestückungskostenanteil an.

VG KDW


Last edited by kdw on 26.12.2022, 10:03; edited 1 time in total
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 26.12.2022, 10:02    Post subject: Kundennutzen … Reply with quote

Hallo Forum.

Beschäftigen wir uns einmal mit der Fragestellung „Warum sollte ein Gerätehersteller, Maschinen- und Anlagenbauer den virtuellen DNP/8331 in ein Produkt integrieren?“. Eine mögliche Antwort ist m. E. bemerkenswert einfach. Sie könnte „Um auch für den Rest dieses Jahrzehnts wettbewerbsfähig zu bleiben!“ lauten. Dabei denke ich an den EU-Cyberresilience-Act, der in den kommenden Jahren in jedem EU-Land als Gesetzt in Kraft tritt und in etwa die gleichen Auswirkungen für Produkthersteller verursachen wird, wie vor vielen Jahren die CE-Gesetzgebung hinsichtlich der elektromagnetischen Verträglichkeit. Damals war u. a. jedes Produkt, das irgendwie mit Elektrizität zu tun hatte, betroffen. Der EU-Cyberresilience-Act wird Veränderungen an allen Produkten mit digitalen Elementen (also Hard- und Software) bewirken. Dadurch wird jedes Gerät bzw. jede Maschine eine IoT-Schnittstelle benötigen, über die dann z. B. auch Software-Updates möglich sind.



Mit Hilfe eines CAD-Funktionsblocks lässt sich diese Schnittstelle in die eigene Elektronik integrieren und mit Funktionen ausrüsten, die dem Anwender einen echten Mehrwert bieten. Neben sicheren Fernzugriffen im Servicefall, Over-the-Air (OTA)-Software-Updates über den gesamten Produktlebenszyklus lassen sich damit auch das digitale Typenschild gemäß EN 61406 sowie ein digitaler Zwilling realisieren. Und das alles, ohne das die Anwender ein zusätzliches Edge-Gateway oder sonstige kosten- und problemintensive Zusatz-Hardware eines weiteren Anbieters installieren müssen …

VG KDW
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 28.12.2022, 12:14    Post subject: Anwendungsbeispiel Wärmepumpen … Reply with quote

Hallo Forum.

Wärmepumpen gelten als das klimafreundlichste und effizienteste Heizsystem für Gebäude unterschiedlicher Größe. Sie sind nicht nur zum Erreichen der nationalen CO2-Reduktionsziele von größter Bedeutung. Auch bei der aktuellen Energielieferkettendiversifizierung spielen sie eine wichtige Rolle. Aus diesem Grund ist es nicht weiter verwunderlich, dass die Anschaffung ab 1.1.2023 im Rahmen der Bundesförderung für effiziente Gebäude besonders subventioniert wird. Förderfähige Wärmepumpen müssen allerdings über spezielle Schnittstellen automatisiert netzdienlich aktiviert und betrieben werden können. Zum Beispiel anhand der Standards „SG Ready“ oder „VHP Ready“.

Mit Hilfe des virtuellen DNP/8331, dem dazugehörenden Firmware-Stack plus einigen Funktionen aus der Backend Function Library lassen sich besondere innovative Lösungen schaffen, die nicht nur die Förderbedingungen erfüllen, sondern darüber hinaus auch einen hocheffizienten Wärmepumpenbetrieb ermöglichen. Die hier folgende Abbildung illustriert ein mögliches Konzept, das auf IoT-Technik basiert.



Wärmepumpen sind besonders dann sehr kosteneffizient, wenn der für den Verdichter- bzw. Kompressorbetrieb benötigte elektrische Strom mit Hilfe einer Photovoltaikanlage (PV-Anlage) selbst erzeugt wird und zwischen der PV-Anlage und der Wärmepumpe auch noch eine Batterie als Stromspeicher existiert.

Eine solche Sektorenkopplung ist allerdings beim derzeitigen Stand der Energieanlagentechnik eine echte Herausforderung. Der in den Förderbedingungen angesprochene „SG Ready-Standard“ des Bundesverband Wärmepumpe e. V. (BWP) beschreibt lediglich eine Variable für vier verschiedene Betriebszustände:

Zustand 1: Wärmepumpe ausschalten (maximal zwei Stunden). Dieser Betriebszustand ist abwärtskompatibel zur s. g. EVU-Sperre und umfasst maximal zwei Stunden „harte“ Sperrzeit.

Zustand 2: Normalbetrieb. Wärmepumpe läuft im energieeffizienten Normalbetrieb mit anteiliger Wärmespeicherfüllung für die maximal zweistündige EVU-Sperre.

Zustand 3: Verstärkter Betrieb für Raumheizung und – falls vorhanden – Warmwasseraufbereitung. Das Eingangssignals zu diesem Zustand ist nicht als Einschaltbefehl, sondern lediglich als Einschaltempfehlung zu verstehen. Die Entscheidung liegt beim Wärmepumpen-internen Regler.

Zustand 4: Definitiver Betrieb (das Eingangssignal ist als Einschaltbefehl zu interpretieren); hier sind allerdings verschiedene Varianten möglich. Z. B. Einschalten der Wärmepumpe oder höhere Soll-Temperaturen bzw. Heizstab-Einsatz.

Da die SG Ready-Spezifikationen bereits seit 2012 existieren, gibt es am Markt zahlreiche Wärmepumpenmodelle, die eine SG Ready-Fähigkeit mit Hilfe von zwei digitalen Eingängen realisieren, um die vier Zustände als Eingangsdatenbild zu erfassen. Eine Kosteneffizienz für den Betreiber ist damit zwar noch nicht möglich (die neuen Förderbedingungen wäre allerdings erfüllt, da wohl nur vorausgesetzt wird, dass die SG Ready-Schnittstelle vorhanden ist).

Das mit den hinter SG Ready steckenden Ideen mehr möglich ist, zeigt unser Anwendungsbericht „Digitale Zwillinge für Wärmepumpen“, den jeder bei Interesse anfordern kann. In dieser Beschreibung kommt er DNP/8331-CAD-Funktionsblock als IoT Device zum Einsatz, die über einen digitalen Zwilling kommunikationstechnisch mit einer Wärmepumpe und den Wechselrichtern einer PV-Anlage und Batterieeinheit verbunden ist. Auf das Gesamtdatenbild wird eine zyklisch ablaufende Klassifizierungsfunktion angewendet, die als Ausgangswert einen SG Ready-Zustand liefert, der von der IoT Device (intern) an den Wärmepumpenregler übermittelt wird.

VG KDW

Anmerkung zum Begriff des „digitalen Zwillings“: Da zu diesem Thema aktuell sehr viel geforscht wird, existieren inzwischen verschiedene Arten von digitalen Zwillingen. Das in London ansässige Ingenieurbüro Arup hat 2019 dazu eine hilfreiche Klassifizierungsmetrik veröffentlicht (siehe „Digital Twin. Towards a meaningful framework” unter https://research.arup.com/publications/digital-twin-towards-a-meaningful-framework/). Der in unserem Anwendungsbericht beschriebene digitale Zwilling entspricht demnach einem „Low-level digital Twin“ (Level 1 bzw. Level 2).
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 05.01.2023, 17:19    Post subject: Virtuelle Serviceassistenten … Reply with quote

Hallo Forum.

Ein weiterer Anwendungsschwerpunkt, auf den wir uns im Zusammenhang mit dem virtuellen DNP/8331 konzentrieren werden, ist „Remote Assistance“.

Wir alle kennen die folgende Situation: Man steht vor einer Maschine oder Anlage, die nicht einwandfrei funktioniert. Eine rote Leuchte blinkt und auf einem kleinen Display ist lediglich „Fehler 4711“ zu lesen (vielfach gibt es auch nur eine rote LED mit der Beschriftung „Error“). Was genau ist zu tun? Häufig ist der Weg zur Antwort mühevoll.

Auf jeden Fall hat ein solches Erlebnis keinen positiven Einfluss auf die Kundenzufriedenheit. Deshalb sollten Maschinen- und Anlagenbauer in allen Branchen mit Hilfe moderner IoT-Technologie zielgerichtete Maßnahmen ergreifen, um negative Kundenerfahrungen bei Störungen und ähnlichen Zuständen möglichst zu vermeiden.



Der DNP/8331-CAD-Funktionsblock kommt als Device Condition Sensorik (DCS) in einer Maschinen-internen Baugruppe zum Einsatz. Es gibt zwei externe Kommunikationsschnittstellen:

1.) Eine IP-basierte und entsprechend gesicherte Verbindung zu einem digitalen Zwilling. An diesen sendet der DCS fortlaufend oder bei relevanten Veränderungen aktuelle Zustandsdaten, die vom digitalen Zwilling in einer Zeitreigendatenbank gespeichert werden.

2.) Eine Bluetooth Low Energy (BLE) Nahbereichsfunkschnittstelle. Der DCS in der Maschine versendet periodisch BLE-Beacons mit dem aktuellen Maschinenzustand. Ein Smartphone in Funkreichweite mit der dazu passenden (Assistenten-) App kann die Meldungen empfangen und an Hand eines an der Maschine angebrachten QR-Codes oder des BLE-RSSI-Werts feststellen, ob sich der Benutzer im Nahbereich des Beacon-Senders befindet. Ist das der Fall, wird die App in den Vordergrund gebracht, der Zustands-Beacon ausgewertet und eine deutlich informativere Meldung mit Hintergrundinformationen und Verhaltenshinweisen auf dem Smartphone visualisiert. Gleichzeit fragt die Assistenten-App, ob ein Fernsupport (Remote Assistance) benötigt wird. Falls der Benutzer diese Unterstützung wünscht, übermittelt die App die Maschinenzustandsdaten an einen Cloudservice. Von dort kommt dann nach einer Datenanalyse die gewünschte Hilfe. Bei Bedarf wird sogar ein digitaler Zwilling einbezogen, um die Ursachenforschung kontextbezogen zu vertiefen.

VG KDW
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 08.01.2023, 16:05    Post subject: DNP/8331 und eDNP/8331 … Reply with quote

Hallo Forum.

Was hat es mit den beiden Namen auf sich? Die Antwort ist relativ einfach: Der DNP/8331 ist ein physisches Stück Hardware (linker Teil der folgenden Abbildung). Ein DNP/8331 lässt sich daher als Embedded-Linux-Modul für Prototypen, Proof of Concept (PoC)-Projekte und Kleinserien einsetzen. Das Primärziel für eine DNP/8331-Anwendung ist in der Regel die schnelle Realisierbarkeit, also der Zeitfaktor.

Mit dem eDNP/8331 ist das Intellectual Property (also ein CAD-Funktionsblock) des DNP/8331 gemeint, dass sich z. B. als Snippet in ein Altium Designer-Projekt einbinden lässt (siehe rechten Teil der folgenden Abbildung). Bei der Schaltungsentwicklung für die Leiterplatte einer Baugruppe wird der eDNP/8331-Funktionsblock mit einer DC-Spannungsversorgung, den jeweils benötigten I/O-Funktionen sowie den erforderlichen Steckverbindern kombiniert. Das Ergebnis ist eine Leiterplatte, in der die benötigten Funktionen kostenoptimiert realisiert wurden.



Das schnelle Prototyping mit dem DNP/8331 wird durch umfangreiches Zubehör unterstützt. So steht über das MB/941 beispielsweise eine Trägerbaugruppe mit einem 40-poligen DNP/8331-Steckplatz sowie verschiedenen I/O- und Erweiterungsfunktionen zur Verfügung, zu der auch ein passendes DIN-Hutschienengehäuse lieferbar ist. Darüber hinaus existierten umfangreiche Backend-Cloudservice, mit denen sich VPN-Server für sichere Fernzugriffslösungen, Over-the-Air (OTA)-Software-Update-Server, ein generischer digitaler Zwilling sowie ein PKI-Konzept für die sichere und vertrauenswürdige Kommunikation innerhalb einer industriellen Anwendung auf der Basis von X.509-Zertifikaten.



Durch die Kombination aus DNP/8331 und eDNP/8331 plus einem umfangreichen Zubehörset ist eine echte Parallelentwicklung möglich. Die Softwareentwicklung in der tatsächlichen Laufzeitumgebung des Endprodukts kann sofort beginnen. Hierfür wird lediglich das zum DNP/8331 gehörende Debian-Linux-Betriebssystem auf eine MicroSD-Speicherkarte kopiert und in den dafür vorgesehenen Steckplatz gesteckt. Nach dem Anlegen der Versorgungsspannung ist die Kommunikation per Webbrowser (SSV/WebUI) sowie per SSH/SFTP möglich. In das Linux-Dateisystem ist bereits eine Python 3-Laufzeitumgebung eingebunden. Ein Entwickler kann daher auf seinem Arbeitsplatzrechner Visual Studio Code (VSC, siehe auch https://de.wikipedia.org/wiki/Visual_Studio_Code) starten, einige Zeilen Python-Code erstellen, per SFTP zum DNP/8331 laden und dort ausführen. Mit einem DNP/8331 Evaluierungs- bzw. Starter Kit dauert es somit nach dem Auspacken keine 30 Minuten, um z. B. als „Hallo Welt“ einen in Python selbst geschrieben HTTP-Server zu erstellen und auf dem DNP/8331 zum Laufen zu bringen.



Die ersten echten Herausforderungen in einem realen Projekt sind häufig spezielle I/Os, die natürlich den Softwareentwicklern möglichst schon in der Projektstartphase zur Verfügung stehen sollten (schließlich ist die Integration spezieller Schnittstellen in einem Embedded-Systems-Projekt eine zeitintensive Teilaufgabe). Die Lösung ist vielfach der MiniPCIe(xpress) Connector J2 oder der System I/O Connector J8 der MB/941-Trägerbaugruppe. An J2 steht die DNP/8331-USB-Schnittstelle zur Verfügung. Sie kann über einen MiniPCIe-to-USB-Adapter mit zusätzlichen I/Os verbunden werden. Über J8 sind I2C und die TX/RX-Signale einer seriellen Schnittstelle für externe I/O-Anbindungen nutzbar.

Während die Softwareentwicklungsphase inklusive eines PoC-Feldtests läuft, können die zuständigen Schaltungsentwickler mit dem eDNP/8331-Snippet die Leiterplatte für die vollständige Baugruppe entwerfen, das PCB-Layout erzeugen, erste Prototypen bauen und die erforderlichen EMV-Messungen durchführen.

VG KDW
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 10.01.2023, 07:22    Post subject: Der gesamte Baukasten bzw. Technologie-Stack … Reply with quote

Hallo Forum.

Ein eDNP/8331 ist mitnichten nur ein Funktionsblock, der sich mit Hilfe einer CAD-Software in die eigene Schaltung integrieren lässt. Es ist vielmehr ein Baukasten bzw. Technologie-Stack für integrierbare Embedded-Systems-Lösung. Der Anwendungsschwerpunkt liegt dabei auf dem Datenfluss und dem KI-Einsatz (KI = künstlicher Intelligenz); also beispielsweise eine intelligente Energiemanagementlösung, die anhand eines möglichst umfassenden Datenbilds mittels KI die Energieflüsse einer Anlage unter Ausnutzung dezentraler Energieressourcen steuert. Der Anwendernutzen einer solchen Lösung wäre eine höhere Energieeffizienz im Vergleich zum konventionellen Betrieb. Die einzelnen Funktionen lassen sich in ein Schichtensystem einordnen:



Backend Function Library: Verschiedene Serverfunktionen, z. B. VPN-Server für den Aufbau einer Fernzugriffslösung, SDU-Server (SDU = Secure Device Update) für Over-the-Air (OTA)-Software-Updates, generischer digitaler Zwilling mit digitalem Typenschild, Public Key Infrastruktur (PKI, Baugruppen werden bereits ab Werk mit einem vorinstallierten X.509-Zertifikat ausgeliefert). MQTT-Broker, modulares REST-Interface u.a. Die einzelnen Funktionen erfordern die Integration der korrespondierenden Plug-in-Codebausteine in den Firmware Stack.

Firmware Stack: Boot Loader (bei Bedarf inkl. Secure Boot). Debian Linux. SSV/WebUI. Python 3 Laufzeitumgebung für die Anwendungsentwicklung. Plug-in-Softwarebausteine, um zusätzliche Funktion aus der Backend Function Library und I/O Function Library zu nutzen. Dazu gehört auch der TensorFlow Lite Runtime für den Inferenzbetrieb.

I/O Function Library: Schaltbilder zu den Baseboards MB/935A und MB/941. Power-over-Ethernet (PoE)-Interface als Schaltungsbeispiel. 4G-Mobilfunk für den weltweiten Einsatz. Verschiedene Beispielschaltungen zu 868/915 MHz und 2,4 GHZ-Nahbereichsfunkschnittstellen für die Sensor- und Aktorintegration. Generischer Sensor mit STM32, A/B-Boot und OTA-Software-Update. BLE-2-Smartphone-Bausteine, um BLE-Token in einer Smartphone-App auszuwerten uva. Die einzelnen Funktionen erfordern die Integration der korrespondierenden Plug-in-Codebausteine in den Firmware Stack.

Altium Snippet: Schaltbild und 6-Lagen-Layout zum eDNP/8331 als CAD-Funktionsblock zur Nutzung in eigenen Leiterplattenentwürfen mit dem Altium Designer. Snippets sind im Altium Designer eine Methode, um ein Design wiederzuverwenden (Design Reuse).

VG KDW
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    SSV-Forum Forum Index >>> DNP/8331, eDNP/8331 All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

SSV Software Systems GmbH

Dünenweg 5
30419 Hannover

Fon: +49(0)511  ·  40 000-0
Fax: +49(0)511  ·  40 000-40

sales@ssv-embedded.de


Impressum    ·    Datenschutz    ·    AGB

© 2023 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.

ISO 9001:2015