Diskussion:Hardware in the Loop

Fehlernachtest und Regressionstest

Nur um Missverständnisse zu vermeiden: Ich hatte bei meinem Edit als Kommentar geschrieben: "typo + retest -> wobei Regressionstests hier auch passen würden)". Retest und Regressionstest sind verschieden, gemeint war: eine Verlinkung zu Regressionstests ist auch sinnvoll, da nach Modifikationen auch überprüft werden kann, ob die Modifikationen Veränderungen bewirkt haben, z.B. eine Modifikation hat einen bisher maskierten Fehler offen gelegt. ----Erkan Yilmaz (bewerte mich!, Diskussion) 18:40, 14. Jan. 2007 (CET)

"der Kreis schließt sich"

Tut mir leid, aber das ist doch Blödsinn: "...über seine Ein- und Ausgänge an ein angepasstes Gegenstück angeschlossen wird und dadurch den Kreis (Loop) schließt"

Es handelt sich hierbei um die Hardware Evolution bei der Entwicklung. Wie bisher aus dem Bereich des SW-Engineerings wird hier im Iterationsverfahren eine neue Hardware entwickelt. Also grob: Anforderungen analysieren, Spezifikation, ..., Design,..., Entwurf eines Prototyps und dann wieder von vorn mit der Entwiclungsschleife. Betonung dabei auf SCHLEIFE (Loop), nicht Kreis!!!! Und schon gar nicht, so wie beschrieben!

Bisher habe ich Wiki teilweise - mit vorsichtigem Misstrauen natürlich - genutzt. Bei solchen Einträgen wird man da allerdings stutzig! Man sollte nicht einfach etwas schreiben, ohne wirklich Ahnung zu haben. VORSICHT AN ALLE KONSUMENTEN! vielleicht besonders bei diesem Autor!(nicht signierter Beitrag von 84.171.187.29 (Diskussion) 13:29, 8. Mär. 2007)

Du verwechselst aber nicht gerade Hardware in the Loop mit Rapid Control Prototyping? Nichts desto trotz habe ich den unsäglichen Kreisvergleich entfernt und den Text verdeutlicht. Ich war allerdings nicht der vorige Autor...--Ma-Lik ? +/- 12:54, 29. Nov. 2007 (CET)

Ich weiß nicht genau, was dort stand, aber es scheint, als sei Kreis im Sinne von Regelkreis gemeint gewesen. Und das wäre keineswegs falsch. -- Chillvie (Diskussion) 22:11, 7. Aug. 2012 (CEST)

SIL Erklärung ist falsch/inkonsitent/inkomplett

Unsinn ist in dem Kontext: "Das erstellte Modell der Software wird lediglich in den für die Zielhardware verständlichen Code umgewandelt." Eben nicht, es wird in für den Entwicklungsrechner verständlichen Code umgewandelt, (kompiliert), nicht für die Zielplatform. Siehe auch: https://de.wikipedia.org/wiki/Eingebettetes_System

Erklärung: SIL geht aus meiner Sicht auf mehrere Arten. Die zwei extremsten dabei sind wohl:

A) Ich bette meinen zu testenden Code für die Zielhardware direkt in ein Umgebungsmodell ein, kompiliere alles zusammen für die Versuchsplatform/den Entwicklungsrechner, wo es getested werden soll und lasse es dann dort laufen. Hier kann ich nur funktional testen, das korrekte Zusammenspiel mit einem OS des Zielsystems und seiner HW-Komponentnen kann ich nicht testen, da sie nicht da sind. Ich muss mein Simulations-Modell entsprechend anpassen bzw. eine Adaptionsschicht vorsehen (mit antsprechenden Funktionen, die sonst das Zielsystem-OS bzw. die Ziel-HW zur Verfügung stellen würde), wenn ich später vielleicht den Großteil des Modells für HIL verwenden möchte. Oder B) ich habe in meinem Umgebungsmodell auch ein Modell meiner Zielhardware, was den für diese Zielhardware kompilierten Code verarbeiten kann. In dem Fall habe ich zwei getrennte Kompilationen: 1) Das Umgebungsmodell inklusive Simulations-Code für die Zielhardware (auch inklusive OS), kompiliert auf der und für die Versuchsplatform/den Entwicklungsrechner und 2) den zu testenden Code für die Zielplatform, den ich (auf dem Entwicklungsrechner) für die Zielplatform cross-kompiliere und dann in dem (Prozessor-)Modell laufen lasse (langsam). Mischformen dieser Extreme sind denkbar. Welche Form ich wähle hängt von Fokus, Zeit, Aufwand etc. meiner Tests ab. (nicht signierter Beitrag von 62.159.244.133 (Diskussion) 12:57, 3. Sep. 2015 (CEST))

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.joerg.frochte.de/echtzeit.html
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.joerg.frochte.de/echtzeit.html

– GiftBot (Diskussion) 18:03, 4. Dez. 2015 (CET)