Wir überlegen in der Firma, ein Sortiment von (einfachen - keine HighEnd-Messtechnik) Sensoren (Temp, Hygro, Bewegung, Lärm usw...) mit Ethernet-Anschluss zu entwickeln, weil wir einen Partner haben, der die für uns evtl. herstellt und im Bereich Gebäudetechnik einsetzt bzw. verkauft ... Derzeit sind das nur ERSTE konzeptionelle Überlegungen, quasi auf Stammtischniveau. 2 Fragen and die Erfahrenen hier: a) Gibts dafür Standard-Protokolle (vergleichbar mit IMAP oder Internet Printing), oder macht da jeder sein eigenes Ding? b) Mikrocontroller (nicht Mikrocomputer) und Verschlüsselung sind nicht direkt die besten Freunde (Speicherbedarf für HTTPS, STARTTLS oder SSL, Zertifikate), dazu noch ohne Internet-Zugang ... hat man damit im Sensorbereich auch ohne Verschlüsselung eine Marktchance? Mir ist klar, dass so ein Projekt nicht ohne umfassende eigene Recherche abgeht, ich erwarte jetzt vom Forum keine tiefgründige Auskunft. Nur fürs Erste eine Aussage, ob's überhaupt Sinn hat, in die Richtung weiter zu denken ... Danke für Tips!
Frank E. schrieb: > a) Gibts dafür Standard-Protokolle (vergleichbar mit IMAP oder Internet > Printing), oder macht da jeder sein eigenes Ding? Ethernetbasierte Feldbusprotokolle gibt es ja zuhauf. Vielleicht irgendwas Richtung IO-Link oder Ethernet Powerlink? Ich weiß aber nicht inwieweit das mit der Gebäudetechnik passt... Gruß Dennis
Frank E. schrieb: > Gibts dafür Standard-Protokolle Diverse. BACnet ist eines, das gerne auch herstellerübergreifend verwendet wird. OPC/UA ist (mittlerweile) inhaltlich recht ähnlich (und ältere OPC-Varianten will man noch nicht mal mit 'ner Zange anfassen).
>> Gibts dafür Standard-Protokolle
EtherCAT. Dessen Erfinder Beckhoff bewegt sich doch ebenfalls im
Gebäudesektor.
Ich entwickle auch für die Gebäudetechnik. Bei einem aktuellen Projekt verwende ich Modbus. Aber RTU. Am Anfang wollte ich TCP nehmen. Aber da ist es blöd von UP-Dose zu UP-Dose es durchzuschleifen, da man ja dann einen 3-Port-Switch-IC braucht. Und der hat einfach zu viele Beinchen und verschwendet Platz. Deshalb hab ich mich dann für RTU entschieden. TCP kommt dann in die nächst höhere Ebene um das ganze an die SPS zu bringen.
Frank E. schrieb: > b) Mikrocontroller (nicht Mikrocomputer) und Verschlüsselung sind nicht > direkt die besten Freunde (Speicherbedarf für HTTPS, STARTTLS oder SSL, > Zertifikate), dazu noch ohne Internet-Zugang ... hat man damit im > Sensorbereich auch ohne Verschlüsselung eine Marktchance? Nur weil ihr das ohne Internerzugang konzeptioniert heißt das nicht, das es der Kunde auch so einsetzt. Also mindestens ne sichere Authentifizierung würde ich schon verlangen, ansonsten kann ja jeder (intern) an den Werten rumspielen.
Mathias O. schrieb: > ... Am Anfang wollte ich TCP nehmen. Aber da > ist es blöd von UP-Dose zu UP-Dose es durchzuschleifen, da man ja dann > einen 3-Port-Switch-IC braucht. Du meinst, wenn die Sensoren Netzwerkanschlüsse, z.B. in Büros, belegen, weil ihr Einsatz vorher nicht geplant war? So wie man das z.B. bei IP-Tischtelefonen macht, um die eine Leitung für den PC durchzuschleifen? Denn ansonsten gehen die Sensoren an einen Switch-Port und gut ist ... was soll man da durchschleifen? Ich würde übrigens UDP nehmen, wenn z.B. bei der Raumtemperatur mal ein Wert verloren geht - was solls? Dafür benötigt es wesentlich weniger Resurcen im MC ... selbst dann noch, wenn man auf UDP-Ebene ein Handshake mit einem Server nachbildet.
Ne. Ich wollte Leitungswege sparen und nicht immer zum Switch gehen. Also sollte jeder Tastsensor einen Switch mitdraufhaben, um dann zum nächsten gehen zu können. Aber Ethernet für einen Tastsensor wäre sowieso zu Oversized gewesen. Die SPS kann nur Modbus TCP, kein Modbus UDP.
>Die SPS kann nur Modbus TCP, kein Modbus UDP.
Dann kann die SPS auch reines TCP und UDP. Alles andere setzt ja nur
darauf auf.
ich halte nicht viel von Sensoren die DIREKT Ethernet Anschluss haben.. sowas kostet dann, wenns fertig ist, 150€ https://shop.netways.de/ueberwachung/hersteller/hw-group/messgeraete/hwg-ste-netzwerk-thermometer-set.html im Bereich Gebäudetechnik wohl eher nicht durchsetzbar (die kosten) ums selbe Geld kannst unzählige 1-wire Sensoren verteilen.. Realistischer wäre wohl (pro Raum) ein "Master" und die Sensoren per Telefonleitung angeschlossen (aber das gibts ja auch schon alles..)
Matthias L. schrieb: >>Die SPS kann nur Modbus TCP, kein Modbus UDP. > > Dann kann die SPS auch reines TCP und UDP. Alles andere setzt ja nur > darauf auf. Kann sie auch. Nur unterstützt es Modbus-TCP schon von der Firmware her. Sodass man nicht extra mit Hilfe von Beusteinen, einen Server aufsetzen muss und für jede Funktion noch einen extra Baustein. Da gibts dann nur eine Seite, wo man die Teilnehmer anlegen kann und welche Register beschrieben oder gelesen werden sollen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.