Frage zu Industrie 4.0 und IoT

[oberallgeier]

.. Du sagtest .. das verantwortliche Entwickler 1 bis 2 Tage vor Ort verbringen sollten .. ist aber eben kein Standard .. enorm hohen Aufwand ..

Also ich kenn das auch nicht als Standard. Standard sind eher ein bis zwei Wochen, teils mehr - soweit ich das von den mir bekannten Softwareentwicklern kenne. Ist aber bei Maschinen etc oft auch der Fall. Leider eben (schon wieder standardmässig) NACH SAT statt vor Pflichten-/Lastenheft. Murphy lässt grüßen.

[SPSAmeise]

Das hängt in der Tat stark von der Lösung ab, denn wenn der Entwickler 2 Wochen braucht nur um sich mit den Abläufen vertraut zu machen, zweifelt ein Kunde wohl eher an der Planung des Dienstleisters
und weniger an der Servicequalität. Teuer und aufwendig bleibt beides , daher sind individuelle Einzellösungen in geschlossenen Systemen auch nicht mehr ganz Zeitgemäß.

[Peter(TOO)]

Hallo,

Also ich kenn das auch nicht als Standard. Standard sind eher ein bis zwei Wochen, teils mehr - soweit ich das von den mir bekannten Softwareentwicklern kenne. Ist aber bei Maschinen etc oft auch der Fall. Leider eben (schon wieder standardmässig) NACH SAT statt vor Pflichten-/Lastenheft. Murphy lässt grüßen.

Ist halt immer auch eine Frage, ein wie helles Kerlchen der Entwickler ist und was er über die Branche und deren Abläufe weiss! Dazu gehört aber auch die jeweilige Fachsprache. Wenn ich mit einem Textilfärber über Farbmetrik rede ist das eine andere Sprache als mit einem Offset-Drucker.

Als die SBB auf Computern bei den Ticketschaltern umgestellt hat, haben sie erst einmal 1 oder 2 Schalter in Bern mit Prototypen ausgerüstet, dann haben einige normale SBB-Ticketverkäufer an diesen Schaltern gearbeitet und ihren Senf dazu abgegeben. Anschliessend wurde das ganze System nochmals überarbeitet.
Den unterschied merkt man, wenn man ein Ticket bei der DB und der SBB am Schalter holt. Am DB-Schalter dauert es ewig ...

Ein Problem ist, dass Pflichten-/Lastenheft fast immer von Leuten erstellt werden, welche mit dem Ergebnis nicht selbst arbeiten müssen!
Hinzu kommt noch, dass sie, oft ohne das nötige Fachwissen, mitdenken. Da werden dann Wünsche ausgeschlossen, weil man denkt es sei zu teuer oder man mal von Problemen gehört hat, oft weil das dann später nachgerüstet werden musste.

Ich habe meine Kunden immer angewiesen das Pflichten-/Lastenheft zuerst dreiteilig zu erstellen:
1. Alles was das Produkt können muss.
2. Dinge die hübsch wären, wenn man sie hat.
3. Hyper-Super-Duper Features.

Im nächsten Schritt hat man dann über die Machbarkeit und Kosten der einzelnen Ideen gesprochen und ein definitives Pflichten-/Lastenheft erstellt.
Oft sind da Dinge von 3. in 1. gerutscht, besonders früher, als noch viel Hardware war. Irgendeine zusätzlich LED macht bei der Entwicklung keine zusätzlichen Kosten, ausser den paar Cent für LED und Widerstand. Wenn man aber das Layout des Prototypen neu entflechten muss, ist es ein Kostenpunkt.
Hinzu kam, dass man auch nur die Löcher für einen zusätzlichen Stecker vorgesehen hat, um später Features nachrüsten zu können, auf Grund der Kategorie 3. konnte man abschätzen wohin die Weiterentwicklungen gehen wird.

Grundsätzlich gilt dies auch für Softwarelösungen. Da kann man einen µC wählen, zu welchem es einen pinkompatiblen grossen Bruder gibt. Oft liegt der Unterschied nur in einem Pull Down oder Up Widerstand, was keine zusätzlichen Kosten erzeugt.
Dies gilt aber auch, wenn man die Hardware fertig zukauft. Bei der Evaluation stolpert man meist über viele, fast identische Produkte. Wenn es mit kleinem Aufwand möglich war, habe ich immer versucht, dass man auch andere Module, ohne Aufwand, verbauen kann. Das hat uns öfters "das Leben gerettet", wenn ein Hersteller nicht liefern konnte oder sein Produkt eingestellt hat. Oder aber, wenn neue Anforderungen an ein bestehendes Gerät gestellt wurden.

Ähnliches gilt auch für die Software. Wenn spätere Erweiterungen schon bekannt sind, kann man die Software von Anfang an, entsprechend modularisieren und/oder Software-Schnittstellen vorsehen. Ähnliches gilt z.B. auch für Timer, heutige µCs besitzen meistens jede Menge davon. Einen einfachen periodischen Interrupt kann ich mit jedem von diesen Erzeugen. Aber einzelne Timer können noch spezielle Aufgaben erfüllen, wie z.B. PWM oder Quadraturdekoder. Für eine einfache spätere Erweiterung, belegt man diese speziellen Timer möglichst nicht. Ähnliches gilt auch für die I/O-Pins.

Aber das ist meine Denkweise und die meisten Entwickler denken leider anders.
Ich habe einige meiner Brötchen damit verdient, indem ich Projekte "geerbt" habe. Entweder weil die Entwickler nicht weiter kamen oder weil das Produkt erweitert werden sollte.

MfG Peter(TOO)