Hallo Zusammen,
hat jemand einen Tipp bezüglich der Überwachung/Steuerung mit einem
MiniRechner. Es gibt Raspberry P, BeagleBone, PCDuino, etc... Dieser
soll Systemkritische Parameter aufzeichnen und gegebenenfalls eine
Anlage ausschalten. Daher ist die Leistung nur zweitrangig. Die Größe
dürfte jedoch eine Rolle spielen. Der Odroid U3 hat beispielsweise keine
GPIO, nur per externen Modul. Daher würde für mich Raspberry PI2 B und
BeagleBone in die nähere Auswahl kommen. Auch pcDuino 3 scheint
interessant zu sein.
Ha. Ja. Dann mach doch einfach mal.
Die Hardware muss zuverlaessig sein. Das Interface zur realen Welt muss
zuverlaessig sein. Und die Software muss zuverlaessig sein.
Mike29 schrieb:> hat jemand einen Tipp bezüglich der Überwachung/Steuerung mit einem> MiniRechner. Es gibt Raspberry P, BeagleBone, PCDuino, etc... Dieser> soll Systemkritische Parameter aufzeichnen und gegebenenfalls eine> Anlage ausschalten.
Schön, also eine Echzeitanwendung. Damit kannst du all den aufgezählten
Quatsch nahezu komplett vergessen. Das wäre nur als Hardwaregrundlage
geeignet, aber nicht mit dem OS, was da jeweils ab Werk drauf läuft. Das
ist meist ein mehr oder weniger räudiges Linux, was sich bestenfalls
notdürftig echtzeitfähig machen läßt, aber harten Echtzeitforderungen,
wie sie für die Notauschaltung von Anlagen verpflichtend sind, nicht
standhalten kann.
> Daher ist die Leistung nur zweitrangig.
Das stimmt. Mit wirklichen Echtzeitsystemen reicht oft ein Bruchteil der
Leistung dieser Linux-gebremsten Scheiße, um die Anforderungen zu
erfüllen. Allerdings ist das Programmieren dafür ein "klein wenig"
anstrengender, man muß nämlich tatsächlich wissen, was man tut.
C&P-"Programmieren" funktioniert auf solchen Plattformen nur sehr
eingeschränkt...
Mike29 schrieb:> Dieser> soll Systemkritische Parameter aufzeichnen
und wie kommt er an die ran? Per I2C, SPI, UART, RS485, USB, TCP/IP,
Gedankenübertragung,...?
> und gegebenenfalls eine> Anlage ausschalten.
Und wie soll er das machen? Aus seinem Gehäuse kriechen und auf das
Not-Aus hauen?
Wie schnell muss das Teil reagieren? ns, µs, ms, s,...?
Nach der Aufgabenstellung bist du mit einem stinknormalen uC besser
bedient. Vielleicht auch ein STM32 oder irgendein PIC (evtl. auch mit
einem RTOS). Aber dafür ein Raspberry, dass mit einem Linux über zig
Abstrahierungsebenen auf die Hardware zugreift? Eher nicht. Und
einfacher ist es wahrscheinlich auch nicht.
c-hater schrieb:> Schön, also eine Echzeitanwendung. Damit kannst du all den aufgezählten> Quatsch nahezu komplett vergessen.
Nahezu...ja. Der BeagleBone hat aber extra dafür noch 2 PRUs.
Nils Friess schrieb:> Nach der Aufgabenstellung bist du mit einem stinknormalen uC besser> bedient.
Je nach dem was für "systemkritische Parameter" das sind. Bei ein paar
Sensorwerten stimme ich dir zu.
Die GPIO Schnittstellen eines Raspberry sind so lahm, da kannst du
gleich jeden anderen PC nehmen und mit USB Adaptern arbeiten.
Wobei ich den anderen Antworten zustimme, dass Linux und Windows für
Echtzeitanwendungen (wenn es denn diese Anforderung gibt) denkbar
schlecht geeignet sind.
Nicht ohne Grund wird jeder normale Tischcomputer durch zahlreiche
Mikrocontroller unterstützt, nämlich da, wo exaktes Timing nötig ist
oder kurzzeitige Aussetzer nicht akzeptabel sind: Mäuse, Tastaturen,
Soundchip, Batterie-Management, WLAN, Bluetooth ...
Was soll denn genau Überwacht/Gesteuert/Abgeschaltet werden?
Wie kritisch ist es, was passiert im Fehlerfall (z.B. Personenschaden)
und wie schnell muss die Steuerung/Abschaltung sein?
Es gibt noch eine Art Treiber-Karte, die dazwischengeschaltet werden
soll. Es ging viel mehr darum einen kleinen Computer zu wählen, der
bestimmte Paramter wie aufzeichnet, aber nicht im Millisekunden-Bereich
sondern alle paar Minuten einen Wert. Eine Art Slow Control System
Stefan Us schrieb:> Wobei ich den anderen Antworten zustimme, dass Linux und Windows für> Echtzeitanwendungen (wenn es denn diese Anforderung gibt) denkbar> schlecht geeignet sind.
Kommt drauf an. Es wurde nirgends erwähnt, welche Reaktionszeiten das
Gerät einhalten muss. Wenn die unter 40 µs liegt, wird's dann
tatsächlich auch mit einem Echtzeit-Kernel + gut gewählten Board nicht
mehr hinhauen.
Frank schrieb:> Nils Friess schrieb:>> Nach der Aufgabenstellung bist du mit einem stinknormalen uC besser>> bedient.>> Je nach dem was für "systemkritische Parameter" das sind. Bei ein paar> Sensorwerten stimme ich dir zu.
Ich würd ganz allgemein sagen, daß das Überwachungssystem immer
möglichst einfach aufgebaut sein sollte. Je geringer die Komplexität,
desto weniger kann ausfallen.
Blinky schrieb:> Was soll denn genau Überwacht/Gesteuert/Abgeschaltet werden?> Wie kritisch ist es, was passiert im Fehlerfall (z.B. Personenschaden)> und wie schnell muss die Steuerung/Abschaltung sein?
Außerdem: Was soll bei einem Ausfall des Überwachungssystems passieren?
Wenn der RasPi nicht mehr bootet, weil die SD-Karte korrupt ist, sollte
das ja irgendwie bemerkt werden, sonst ist die Überwachung komplett
nutzlos.
Vielleicht habe ich mich falsch ausgedrückt. Im Prinzip gibt es eine Art
Treiberkarte, die alles steuert. Diese kann auf Sensoren reagieren etc..
Über den MikroComputer sollen nur die Werte der Treiberkarte gespeichert
oder aufgezeichnet werden. Also wie ein normaler Computer, der über eine
Software Werte aufzeichnet. Das man per Eingabefelder bestimmte
maximalwerte eingibt und an die Treiberkarte übermittelt. Diese hat z.b.
auch I²C Verbindung. Das Sysystem muss nicht schnell laufen und auch
keine Anlagen direkt ausschalten. Deswegen auch die Bezeichnung Slow
Control System!!!
Mach mal Butter bei die Fische und nenne endlich mal zahlen.
Sampelrate?
Wieviele Sensoren?
Was für eine physikalische Schnittstelle?
Was für Protokolle?
