TOP
SSV Software Systems Registrieren  Registrieren
Einloggen, um private Nachrichten zu lesen  Einloggen, um private Nachrichten zu lesen
Startseite FAQ Suchen Mitglieder Profil  Login 
SSV Support-Forum
SFS/BE1 Evaluation Kit ...

 
Neues Thema eröffnen   Neue Antwort erstellen    SSV-Forum Foren-Übersicht >>> SFS/BE1
<<< Vorheriges Thema - Nächstes Thema >>>  
Beiträge der letzten Zeit anzeigen:   
Autor Nachricht
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1454

BeitragVerfasst am: 08.12.2021, 16:01    Titel: SFS/BE1 Evaluation Kit ... Antworten mit Zitat

Hallo Forum.

Die offizielle Produktvorstellung Ende November auf der SPS 2021 in Nürnberg war ja nun leider nicht möglich, da die gesamte Veranstaltung in der letzten Minute Corona-bedingt abgesagt wurde. Unser erstes SSB-basiertes Produkt ist nun aber trotzdem lieferbar. Sie können somit nun jederzeit Ihre Secure-Sensor-Beacon- (SSB-) Evaluierung starten und eine einfache Steuerungsanwendung durch zusätzliche kontextbezogene Sensordaten in eine intelligente Applikation umwandeln.



Siehe auch: https://www.ssv-embedded.de/produkte/sfsbe1.php. Auf Wunsch ist auch jederzeit ein On-Demand-Webinar buchbar. Siehe https://www.ssv-embedded.de/events/ondemand/webinar_iot-retrofit/.

Um einen SFS/BE1 Evaluation Kit nutzen zu können, benötigen Sie einen Raspberry Pi 3 oder 4. Zum SFS/BE1-Lieferumfang gehört eine microSD-Karte für den Raspberry Pi mit einem bootfähigen Linux-Betriebssystem plus einer SSB-Firmware mit einer vollständig vorkonfigurierten SSB-Evaluierungsanwendung.



1) SFS/BE1 mit Sensormodul in Stecksockel. Zur Inbetriebnahme muss ein SFS/BE1-Evaluierungsboard nur mit Spannung versorgt werden. Konfigurationseinstellungen sind am SFS/BE1 nicht erforderlich. Ist die Versorgungsspannung vorhanden, versendet ein SFS/BE1 periodisch die jeweiligen Sensormesswerte als Bluetooth Low Energy (BLE) Advertising Broadcast im 2,4-GHZ-Frequenzbereich (Primary Advertising Channels 37, 38 und 39). Das zum Einsatz kommende BLE-Beacon-Datenformat entspricht den SSB-Spezifikationen (SSB Vers. 1, siehe https://github.com/SSV-embedded/Secure-Sensor-Beacon-Protocol_SSB).

2) Raspberry Pi 3 oder 4 (nicht im Lieferumfang enthalten). Zum SFS/BE1-Lieferumfang gehört allerdings eine microSD-Karte für den Raspberry Pi mit einem bootfähigen Linux-Betriebssystem plus einer SSB-Firmware mit einer vollständig vorkonfigurierten SSB-Evaluierungsanwendung. Der Raspberry Pi dient für den Evaluation Kit als SSB Collector und empfängt alle SSB-Daten der SFS/BE1, die sich jeweils in Funkreichweite befinden. Ist dem SSB Collector ein bestimmtes SFS/BE1 bekannt, werden die Messwerte in ein JSON-Objekt umgewandelt und anderen Anwendungen zur Verfügung gestellt. Um einen SSB Connector mit einem bestimmten SFS/BE1 zu verknüpfen, wird der 128-Bit Data Key des jeweiligen SFS/BE1 in die Konfigurationsdaten des SSB Collector eingetragen.

3) Raspberry-Pi-Software: Durch die Software auf der microSD-Karte wird der Raspberry Pi-LAN-Schnittstelle die IP-Adresse 192.168.0.126 zugewiesen. Um die SFS/BE1-Daten zu nutzen, muss lediglich von einem PC aus per Webbrowser der folgende Link aufgerufen werden: http://192.168.0.126:1880. Im Browserfenster erscheint dann eine Node-RED-Arbeitsoberfläche mit dem vorinstallierten SSB-Beispiel als Node-RED-Flow:



Ganz links ist der SSB-Bluetooth-Node (SSB Collector Node) zu erkennen, über den die per BLE-Funk empfangenen SFS/BE1-Sensordaten auf dem Raspberry Pi als JSON-Objekte (Sensor JSON) zur weiteren Nutzung durch andere Anwendungen zur Verfügung stehen. Um die Daten der SFS/BE1-Baugruppe aus dem Lieferumfang prüfen zu können, muss allerdings einmalig der 128-Bit Data Key (siehe Aufkleber in der Verpackung des SFS/BE1 Evaluation Kit) in die Konfiguration des SSB-Bluetooth-Node eingetragen werden.

VG KDW

P.S.: Das SFS/BE1-Handbuch findet man hier: https://www.ssv-embedded.de/doks/manuals/sr_sfsbe1_en.pdf


Zuletzt bearbeitet von kdw am 11.02.2022, 14:38, insgesamt 4-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1454

BeitragVerfasst am: 09.12.2021, 17:37    Titel: Der Anwendernutzen … Antworten mit Zitat

Hallo Forum.

Insgesamt haben wir unsere Wireless-Sensorik-Entwicklungen mit dem Motiv „Wir schaffen sichere intelligente Umgebungen“ gestartet. Dabei hatten wir in erster Linie an Maschinen, Anlagen und Gebäude gedacht. Insofern haben wir uns zunächst einmal die gute alte SPS vorgenommen. Sie ist ja praktisch in jeder Maschine, den meisten Anlagen und auch unzähligen Gebäuden zu finden. Vergleicht man hier den Stand der Technik mit einer Liste aktueller IoT-Technologien in anderen Bereichen, ergibt sich m. E. schon ein beachtlicher Handlungsbedarf. Um den Abstand nicht noch größer werden zu lassen, sollte zumindest in Bezug auf die Datennutzung das ein oder andere Retrofit auf den Weg gebracht werden.



Über ein IoT-Retrofit mit Bluetooth-basierter Sensorik können einer SPS z. B. Umgebungsdaten zur Verfügung gestellt werden, die bisher nicht existierten. Dazu haben wir einen Technologiedemonstrator angefertigt. Er orientiert sich an der Beispielanwendung „Energiekostenoptimierung per IoT-Sensorik“; siehe hierzu auch https://www.ssv-embedded.de/produkte/sfsbe1.php (User Story Luxmeter).



Bei dieser Aufgabenstellung haben wir uns von den unzähligen Praxisbeispielen „ineffizienter Steuerungslösungen“ leiten lassen: Eine SPS steuert „elektrische Verbraucher“ und nutzt als Führungsgröße einen Zeitplan (z. B. Beleuchtungssteuerungen per „Schaltuhr“). Die von der SPS erzeugte Stellgröße berücksichtigt weder das tatsächliche vorhandene Tageslicht noch die Anwesenheit von Personen.

Um den Anwendernutzen im Kontext der Aufgabenstellung zu verdeutlichen, betreiben wir ein SFS/BE1-OPT3001 als Luxmeter. Der aktuelle Lux-Messwert des OPT3001-Sensorelements wird per SSB-Protokoll periodisch als Bluetooth Low Energy (BLE) Advertising Broadcast im 2,4-GHZ-Frequenzbereich (Primary Advertising Channels 37, 38 und 39) verschickt. Die zum Einsatz kommende BLE-Datenübertragung basiert auf dem Standard-Version „Bluetooth 4“. Ein SSB-Collector empfängt die einzelnen Advertising-Broadcast-Fragmente des SSB-Protokolls über eine 2.4-GHz-BLE-Funkschnittstelle, extrahiert die Messdaten des OPT3001-Umgebungslichtsensors, führt mit dem zum jeweiligen SFS/BE1-Board gehörenden Data Key eine Datenauthentisierung durch und erzeugt nach erfolgreicher Prüfung ein JSON-Objekt zur Weitergabe an andere Anwendungen. Aus diesem JSON-Objekt wird der Lux-Messwert extrahiert und per RFC1006 (S7-Protokoll: ISO Transport Service on top of the TCP) an die SPS geschickt. Dort wird die Lux-Messung als erweiterte Führungsgröße benutzt. In einem nächsten Schritt werden wir den Technologiedemonstrator mit einer Sensorik erweitern, die die Personen in einem Raum zählt.

VG KDW


Zuletzt bearbeitet von kdw am 22.12.2021, 13:00, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1454

BeitragVerfasst am: 14.12.2021, 08:25    Titel: Die Funkübertragung … Antworten mit Zitat

Hallo Forum.

Die Bluetooth Low Energy- (BLE-) Spezifikationen beschreiben u. a. sogenannte Advertising PDUs (PDU = Protocol Data Unit), die als Packet Payload (Nutzdaten einer PDU) über eine Bluetooth-Funkverbindung übertragen werden. Der Bluetooth 4-Standard ermöglicht hier eine Nutzdatenlänge von 2 bis maximal 39 Bytes. Diese Nutzdaten werden auch als Advertising Data (ADV Data) bezeichnet. Die gesamten Daten des Secure-Sensor-Beacon- (SSB-) Protokolls sind im ADV Data-Bereich untergebracht (siehe hierzu auch https://github.com/SSV-embedded/Secure-Sensor-Beacon-Protocol_SSB).



Die Abbildung weiter unten liefert ein Beispiel mit den Details der Funkübertragung eines OPT3001-Lux-Messwerts vom SFS/BE1-OPT3001 zum Raspberry Pi. Insgesamt geht es um die folgenden Bytes in hexadezimaler Darstellung und im „Low Byte First“-Zahlenformat (Little Endian Byte Order):

5900 = Manufacture ID. Vorzeichenlose 16-Bit-Zahl mit einer Herstellerkennung, die von der Bluetooth Special Interest Group (SIG) vergeben wurde. Sie wird im „Low Byte First“-Zahlenformat übertragen. D. h., die hexadezimale 16-Bit Zahl „0059“ (0x0059) wird als Bytefolge „5900“ (0x5900) übermittelt.

40 = Packet Type. 8-Bit-Typkennung. Aus dem Packet Type geht her, welche kryptografischen Algorithmen vom Sender zur Sicherung dieses SSB angewendet wurden. Der hexadezimale Wert 40 (0x40) bedeutet, dass der HMAC (Hash-based Message Authentication Code) in diesem SSB mit einem BLAKE2s-Hash-Algorithmus erzeugt wurde und aus insgesamt 48 Bits besteht.

F09B6A01 = Sequence Number. 32-Bit-Zahl mit einer Sequenz- und Fragmentnummer. Die Sequenznummer dient zum Erkennen von Replay-Attacken. Über die Fragmentnummer werden die SSB-Fragmente verkettet. Auch hier kommt das das „Low Byte First“-Zahlenformat zur Anwendung.

04A07B145642 = Sensor Data. Gemäß den SSB-Protokollspezifikationen bilden die ersten beiden Bytes 04 (0x04) und A0 (0xA0) die Value Length und den Value Type Der eigentliche Sensormesswert ist somit 7B145642 (0x7B145642). Diese vier Bytes bilden eine 32-Bit-Fließkommzahl im IEEE 754-Format mit dem OPT3001-Messwert in Lux (ungerechnet ergibt sich daraus bei einer Nachkommstelle 49,3 Lux). Beachten Sie bitte aber auch wieder das „Low Byte First“-Zahlenformat. Die 32-Bit-IEEE-Zahl ist 4256147B (0x4256147B).

61C160BEB9D3 = HMAC. 48-bit-Hashwert zur Sicherstellung der Datenauthentizität. Zur Berechnung des Hash-based Message Authentication Code (HMAC) wird neben den Sensordaten auch der 128-Bit Data Key einer SSB-Sensoreinheit benutzt. Über diesen HMAC kann der Empfänger die Datenauthentizität prüfen. Dazu muss der Empfänger allerdings den Data Key des jeweiligen SFS/BE1-Boards kennen (dieser 128-Bit-Schlüssel lässt sich z. B. in den SSB-Node-RED-Node der Raspberry-Pi-Software eintragen).



Würde man die SFS/BE1-OPT3001-Bluetooth-Daten mit einem Sniffer analysieren, so wird deutlich, dass direkt vor der zuvor beschriebenen SSB-Bytefolge immer drei weitere Bytes als „Flag“ gesendet werden (z. B. 02 01 04). Diese drei Flag-Bytes sind Pflichtfelder für einen Bluetooth Low Energy Beacon. Der darauffolgende ADV-Data-Bereich einer BLE Advertising PDU besitzt eine variable Länge von bis zu 28 Bytes. Die ersten beiden Bytes Payload Length und ADV Type sind allerdings ebenfalls fest vorgegeben. Payload Length dient als Längenangabe für ADV Data. ADV Type muss 0xFF enthalten, um zu kennzeichnen, dass es sich bei diesem Payload um herstellerspezifische Beacon-Daten (Manufacture Specific Data) handelt. Die verbleibenden restlichen 26 Bytes des ADV-Data-Bereichs eines BLE Beacon werden gemäß den SSB-Spezifikationen genutzt.

Code:

Len....    Type   Value.......................................   Comment......
02         01     04                                             Flags 3 Bytes
14 (20)    FF     5900 40 F09B6A01 04 A0 7B145642 61C160BEB9D3   SSB ADV Data


VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1454

BeitragVerfasst am: 20.12.2021, 18:09    Titel: BLE2MQTT ... Antworten mit Zitat

Hallo Forum.

Innerhalb eines SSB Collector wird die SSB-Bytefolge (SSB ADV Data) mit einigen Zusatzinformationen erweitert, in ein SSB-JSON-Objekt (SSB JSON) umgewandelt und an einen MQTT Broker übertragen. Die dafür verwendete BLE2JSON-Softwarefunktion sind in der Raspberry-Pi-Software vollständig vorkonfiguriert auf der microSD-Karte enthalten.



Über den MQTT Broker greift der SSB Collector Node der Raspberry-Pi-Software auf die JSON-basierten Fragmente (SSB JSON) zu, fasst die Fragmente zu einem einzigen Objekt zusammen, prüft die Datenauthentizität mit Hilfe des HMAC und erzeugt nach erfolgreicher Prüfung ein JSON-Objekt mit dem jeweiligen Sensormesswert (Sensor JSON).



Zusammenfassend gilt somit: Die Daten eines SFS/BE1 werden von der SSB Collector Firmware (in diesem Fall die Raspberry-Pi-Software) als BLE Beacon per SSB-Protokoll empfangen (SSB ADV Data) und mit Hilfe eines MQTT Broker in ein JSON-Objekt mit Sensormessdaten umgewandelt (Sensor JSON). Das neue JSON-Objekt steht direkt am Ausgang des SSB Collector Node in der Node-RED-Laufzeitumgebung des Raspberry Pi zur Verfügung. Es kann bei Bedarf wieder an den MQTT Broker übermittelt werden, damit andere Anwendungen darauf zugreifen können.

VG KDW


Zuletzt bearbeitet von kdw am 05.01.2022, 07:52, insgesamt einmal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kdw



Anmeldedatum: 05.05.2006
Beiträge: 1454

BeitragVerfasst am: 23.12.2021, 07:51    Titel: Node-RED ... Antworten mit Zitat

Hallo Forum.

Der sichtbare Funktionsbaustein im Node-RED-Teil einer SSB-Collector-Firmware ist der SSB Collector Node (linker Teil der folgenden Abbildung):



Jedem einzelnen Sensor einer SSB-Anwendung wird unter Node-RED jeweils ein eigener SSB Collector Node zugeordnet. Der jeweilige Node wird mit der MAC-Adresse und dem 128-Bit Data Key einer SFS/BE1-Baugruppe konfiguriert und liefert anschließend nur die Daten der zugeordneten Baugruppe als Sensor JSON am Ausgang.

In der Abbildung ist ein für ein SFS/BE1-OPT3001 mit OPT3001-Sensorelement konfigurierter SSB Collector Node mit einem Debug Node verbunden. Der Debug Node gibt die vom SSB Collector Node empfangenen Lux-Messwerte als SSB JSON-Objekte im Debug-Tab am rechten Rand der Node-RED-Arbeitsfläche aus.



VG KDW
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    SSV-Forum Foren-Übersicht >>> SFS/BE1 Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Sie können keine Beiträge in dieses Forum schreiben.
Sie können auf Beiträge in diesem Forum nicht antworten.
Sie können Ihre Beiträge in diesem Forum nicht bearbeiten.
Sie können Ihre Beiträge in diesem Forum nicht löschen.
Sie können an Umfragen in diesem Forum nicht teilnehmen.

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