Moin, die Frage richtet sich vor allem an Automatiker, die vermutlich in dieser Rubrik noch am ehesten unterwegs sind: Wie schaetzt ihr die Akzeptanz einer Webbrowserloesung als Prozess-Ueberwachung in der Industrie ein? Bisher gab es da bei den div. Projekten mehrere Kontras (insbesondere von Seiten der Entwicklungspartner) gegen Firefox/Chrome, usw., im Grunde genommen ist der Tenor: Unsicher, hackbar, kann haengen, etc. Inzwischen wuerde ich allerdings - unter der Annahme, dass eine TCP-Verbindung schon mal grundsaetzlich als 'stabil' angesehen wird, die Browserloesung nicht verteufeln, im Gegenteil, teils sogar robuster ansehen als im Betrieb befindliche manche Uralt-Loesungen. Das Thema Wartbarkeit ist vor allem immer wieder auf dem Tisch und SPS, Labview und Konsorten keine Option. Ich gehe ansich davon aus, dass der Techniker irgendwann mit dem Androiden unterwegs ist, und sich die teuren 'gehaerteten' Tablets eruebrigen..
Das kommt darauf an, wie sicher das zugrunde liegende SCADA-Netz ist, bzw. was damit gesteuert wird. Bei sowas wie einer Solar- oder Windkraftanlage oder der häuslichen Pumpstation/Druckerhöhung etc. wäre es mir egal, aber bei manntragenden Anlagen oder Atomreaktoren wird das bestimmt kritischer gesehen.
Webbrowser sind wandelnde Speicherlecks mit einem obendrein nicht bestimmbaren Eigenleben. Niemand wuerde dafuer garantieren, dass eine vom Browser gerenderte Seite tatsaechlich aktuell ist und nicht schon eine Stunde alt. Oder das der Browser ploetzlich kalte Fuesse bekommt und sich mit einem core dump verabschiedet. Den kannst du gerademal fuer deine heimische Heizungssteuerung benutzen. Und das auch nur weil dir zu Hause das niemand verbieten kann.
svedisk ficklampa schrieb: > Webbrowser sind wandelnde Speicherlecks mit einem obendrein > nicht bestimmbaren Eigenleben. > Niemand wuerde dafuer garantieren, dass eine vom Browser > gerenderte Seite tatsaechlich aktuell ist und nicht schon > eine Stunde alt. Oder das der Browser ploetzlich kalte Fuesse > bekommt und sich mit einem core dump verabschiedet. Das kannst du aber bei anderen üblichen SCADA-Systemen die auf einem Windowsrechner laufen, auch nicht.
vn nn schrieb: > Das kannst du aber bei anderen üblichen SCADA-Systemen die auf einem > Windowsrechner laufen, auch nicht. Ich erinnere mich da immer gerne an einen Bahntechnik Leitstand von Siemens. Irgendwo an der Seite vom Bildschirm gab es zwei Balken, die im Sekundentakt hin- und her blinkten. Die waren einzig und allein dafür gut, damit der Bediener erkennen konnte ob die Oberfläche eingefroren ist. Das ist zwar durchaus sinnvoll, sagt aber irgendwie auch viel über die Software dahinter aus. Deswegen denke ich da inzwischen ein bisschen wie der TO. Browser sind eigentlich Rendering Experten. Wenn man da keine total abgefahrene CSS & Javascript Orgie veranstaltet, kommt es eigentlich praktisch nie vor daß eine Seite nicht richtig funktioniert. P.S. ich weiß aus eigener Erfahrung von einer kommerziellen Generator Steuerung, bei der die SPS eine Benutzeroberfläche als HTML ausliefert. Zusätzlich zur üblichen Windows Software. Über diese Webseite kann man die ganze Anlage komplett steuern, nach Login sogar am Gasgemisch rumspielen. Explodiert ist da noch nichts und das sind Anlagen bis 400kW.
Moin, svedisk ficklampa schrieb: > Webbrowser sind wandelnde Speicherlecks mit einem obendrein > nicht bestimmbaren Eigenleben. > Niemand wuerde dafuer garantieren, dass eine vom Browser > gerenderte Seite tatsaechlich aktuell ist und nicht schon > eine Stunde alt. Oder das der Browser ploetzlich kalte Fuesse > bekommt und sich mit einem core dump verabschiedet. > Genau hier vollzieht sich seit einigen Jahren ein Paradigmenwechsel. Deswegen frage ich ja.. Ich habe da selbst auch einige Loesungen mit Valgrind getestet. Firefox und Chrome schneiden da sehr gut ab, wogegen eine kommerzielle 'professionelle' Loesung schon mal rausfliegt. Natuerlich wird damit keine SIL-4 Anlage gebaut, die ganze Safety ist sowieso in harter Logik verarztet. Am Rande: Es gibt auch eine nicht irrelevante Browserloesung fuer die Finanzwelt, welche auf hohe Verfuegbarkeit baut. Warum also nicht auch fuer SCADA.. OpenMCT sehe ich mir gerade mal an, danke an den Tippprovider (wollte schon immer mal ein Wort mit 3p schreiben :-) ). Das sieht schon mal sehr ansprechend aus. Grafana ist hier bereits mit im Spiel, allerdings nur fuer Visualisierung und nicht Prozessparameter. Sicher muss man da auch noch ein paar SCADA-Widgets einbauen. Das Problem mit der Aktualitaet einer Seite ist natuerlich ein Dauerbrenner. Der eine will latency-Timer und einen Alarm, der andere eine nervige Animation... Die Crux ist momentan vor allem die TCP-Verbindung. Da Echtzeit im Bereich <0.5s aber am Frontend kein Kriterium ist, gibt's eigentlich kein Argument dagegen. Alles echtzeitkritische laeuft sowieso auf einem andern Netz (UDP/modbus).
Wenn Du die Lösung zu großen Teilen selbst planst und entwickelst (und Dich nicht in ein vorhandenes System einklinken musst), könntest Du folgendes machen: - Jede Browsersitzung wird beim Start/Login etc. einmal an einem Überwachungssystem angemeldet - Im Browser läuft ein Javascript, welches das DOM ausliest und prüft, von wann die letzten dargestellten Daten sind. Es zieht einen Zeitstempel oder vom Server mitgesendeten Counter oder ähnliches. - Dieser Zeitstempel/Counter wird vom Javascript regelmäßig an das Überwachungssystem gemeldet - Wenn von einer angemeldeten Browsersitzung keine aktuellen Zeitstempel mehr kommen, schlägt das Überwachungssystem Alarm. Einziges Problem könnte dann sein daß der Browser in sich durcheinander gekommen ist und zwar das DOM aktualisiert, aber dennoch alte Daten darstellt. Man könnte das noch auf die Canvas-Funktionen des Browswers erweitern um den Bildschirminhalt auszulesen, ich denke da hat man dann schon einen sehr großen Teil der Fehlermöglichkeiten innerhalb des Browsers abgedeckt.
Gerd E. schrieb: > - Jede Browsersitzung wird beim Start/Login etc. einmal an einem > Überwachungssystem angemeldet > - Im Browser läuft ein Javascript, welches das DOM ausliest und prüft, > von wann die letzten dargestellten Daten sind. Es zieht einen > Zeitstempel oder vom Server mitgesendeten Counter oder ähnliches. > - Dieser Zeitstempel/Counter wird vom Javascript regelmäßig an das > Überwachungssystem gemeldet > - Wenn von einer angemeldeten Browsersitzung keine aktuellen Zeitstempel > mehr kommen, schlägt das Überwachungssystem Alarm. Das finde ich eine sehr gute Idee. So weit habe ich den Prototypen (den ich mal fuer Android-Browser angeschmissen habe) noch gar nicht getrimmt. Ginge aber vermutlich per Websockets ohne Overkill. Bisher geht das System nur in den WARN-Mode wenn eine Weile keine Daten mehr abgefragt wurden (= besagter Latenzzaehler). Zwischen Web-Server und Ueberwachungssystem gibt es also bereits einen Handshake. Es gab da auch schon andere lustige Ideen mit Nonce als 2D-Barcode, der per VNC abgefragt wird, usw. aber ich fuerchte, dass eine solche Loesung fehleranfaelliger ist als der Browser selber. Bisher habe ich nur Haenger durch fehlerhafte Javascripte provozieren koennen, die Firefox allerdings detektiert. Die Rendering-Engine ist m.E. sehr stabil, besser also so manche Delphi-Loesung.
Martin S. schrieb: > Es gab da auch schon andere lustige Ideen mit Nonce als 2D-Barcode, der > per VNC abgefragt wird, usw. aber ich fuerchte, dass eine solche Loesung > fehleranfaelliger ist als der Browser selber. Sowas könnte man ganz gut über das Canvas-Zeug im Browser machen. Eine VNC-Lösung (oder ähnliches) würde ich mir da nicht antun wollen, wenn das auf PCs, Android,... laufen soll, wird das ziemlich viel Aufwand und vermutlich anfällig. > Die Rendering-Engine ist m.E. sehr stabil, besser > also so manche Delphi-Loesung. Ja, das Rendering in den Browsern ist über die letzten Jahre schon ziemlich gut und zuverlässig geworden. Was ich hin und wieder beobachtet hatte war massiver Speicherverbrauch wenn schlecht designte, komplexe Seiten länger genutzt wurden. Das war vermutlich kein Speicherleck im Browser, sondern das Javascript der Seiten was einfach tonnenweise Objekte im Speicher hielt und nicht freigab. Hauptsächlich wenn zig verschiedene Javascript-Frameworks übereinandergestapelt und untereinander verwebt wurden. Das hast Du mit dem Design der Seite natürlich selbst in der Hand. Quäl den Prototypen mal für ein paar Tage bis Wochen, schließe den Browser nicht und beobachte dabei den Speicherbedarf.
Gerd E. schrieb: > Was ich hin und wieder beobachtet hatte war massiver Speicherverbrauch > wenn schlecht designte, komplexe Seiten länger genutzt wurden. Das war > vermutlich kein Speicherleck im Browser, sondern das Javascript der > Seiten was einfach tonnenweise Objekte im Speicher hielt und nicht > freigab. Hauptsächlich wenn zig verschiedene Javascript-Frameworks > übereinandergestapelt und untereinander verwebt wurden. Genau da bin ich auch schon mit jquery und einem Toolkit reingerannt. Man kann in der Tat eine Menge Mist mit Javascript machen, und natuerlich das System so auch vermuellen. Aber es liess sich alles per Debugger relativ gut aufspueren. Der User kann da auch nicht viel reinfuschen. Im Prinzip 'abonniert' er nur Telemetriedaten oder eine 'Property' auf seiner Monitorconsole, und das nicht allzu dynamisch. Fuer den Monitor wird dann sowieso nichts mehr veraendert. Wer es anders will...naja, da gaebe es Node-RED. Es gibt auch die Anwender, die sich eine fertige Zeichnung (DXF oder SVG) nur noch animieren lassen wollen. Da ist dann gar nichts mehr dynamisch. In die Richtung geht z.B. OSHMI, was offenbar auch kein Spielzeug ist.
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.