TIA Datentyp im Instant-DB eines Know-How geschützten FB ändern und ohne Passworteingabe übersetzen können

freshmar97

Level-1
Beiträge
11
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

mein Problem ist, dass unser Kunde für den Fall ohne Fernwartung Datentypen von Instant-DB's ändern können muss (über HMI) und diesen übersetzen. Dies geht auch weil der DB nicht Know-How geschützt ist (TIA V15.1). Danach meckert aber der geschützte FB logischerweise und möchte zur Aktualisierung der Schnittstelle das Passwort. Dieses soll natürlich nicht herausgegeben werden. Gibt es eine Möglichkeit, dass der Kunde also übersetzen bzw. aktualisieren kann ohne dass Passwort eingeben zu müssen?

Danke und schöne Grüße,
Marcel
 
Also der Kunde sitzt schon noch mit seinem Rechner an der Maschine, da war ich etwas unpräzise. Stell dir einen Telefonsupport vor, wenn der Kunde keine Fernwartung gekauft hat.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum soll überhaupt der Kunde irgendwas an FB-Schnittstellen usw. ändern? Ist das dem seine Aufgabe?
Also der Kunde sitzt schon noch mit seinem Rechner an der Maschine, da war ich etwas unpräzise. Stell dir einen Telefonsupport vor, wenn der Kunde keine Fernwartung gekauft hat.
Wie wäre es z.B. mit Teamviewer, dann kannst du es machen und das Passwort eingeben
 
Die Idee war, um dies sehr sicher zu gestalten jeden FB mit einem eigenen Passwort zu versehen, sodass nicht einmal jeder Mitarbeiter an alles dran kommt, sondern nur derjenige der es dürfen soll). Problem ist, dass es sehr aufwendig wird dann u.A. auch über sowas wie TeamViewer alles FB's zu aktualisieren (das mit dem sehr hohen Grad an Passwortschutz kommt nicht von mir, darüber diskutieren wir lieber nicht, ich darf das Thema halt anschauen ob es gehen könnte). Wie ich dich verstehe geht dies so einfach nicht Ausnahmen zu machen. Würdest du dann ein einheitliches Passwort auf einer Ebene an Code empfehlen, sodass man alle FB auswählt und für diesen Bereich dann einmalig dass Passwort eingeben würde um zu aktualisieren?
 
mein Problem ist, dass unser Kunde für den Fall ohne Fernwartung Datentypen von Instant-DB's ändern können muss (über HMI) und diesen übersetzen. Dies geht auch weil der DB nicht Know-How geschützt ist (TIA V15.1).
Wie soll das gehen? Datentypen von Variablen in Instanz-DB können nicht im DB geändert werden sondern werden im zugehörigen FB festgelegt und dann muß neu übersetzt werden, damit sich alle Instanz-DB anpassen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Idee war, um dies sehr sicher zu gestalten jeden FB mit einem eigenen Passwort zu versehen,
OK, verstehe. Ihr baut also Atomkraftwerke

Würdest du dann ein einheitliches Passwort auf einer Ebene an Code empfehlen
Ich würde prinzipiell gar kein Passwort empfehlen. Was habt ihr schon schützenswertes.
Wir als Endkunde hätten dies vorab schon per Lastenheft untersagt.

Meine Meinung zu dem Ganzen:
Ihr habe auf jedem eurer Bausteine ein eigenes Passwort und euer Kunde sitzt jetzt am PG und soll irgendwelche
FB-Schnittstellen ändern. Merkst du glaube ich selber dass da irgendwas gewaltig schief läuft.
 
Die Idee war, um dies sehr sicher zu gestalten jeden FB mit einem eigenen Passwort zu versehen, sodass nicht einmal jeder Mitarbeiter an alles dran kommt, sondern nur derjenige der es dürfen soll).
Wie kann ein Kunde sowas kaufen bzw. sich andrehen lassen? Dann wird im Problemfall niemand helfen können/wollen, weil der Fehler natürlich immer in dem Baustein ist, wo der eine Mitarbeiter, der das Passwort weiß, gerade längere Zeit nicht da ist...

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Welcher Kunde akzeptiert denn freiwillig einen PW-Schutz in seinen Programmen? Damit man bei jeder Störung nur den Dienstleister anrufen kann und sonst steht die Produktion?
 
Die Idee kam natürlich von höherer Ebene, da möchte man natürlich gar kein Know-How abgeben. Kunden haben auch schon den Passwortschutz mittels Lastenheft untersagt, einige ist es egal und nehmen die teurere Fernwartung, wobei es kein Problem geben wird. Das letzte was diskutiert wird, wenn ein Kunde vor Ort mittels Telefonsupport die Worte in Taten umsetzen soll (hierbei dann evtl. die Änderung im DB), ob es hier Möglichkeiten gibt dies zu dürfen trotz Know-How Schutz?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Will der Kunde die vielen Passwörter weil seine Mitarbeiter das eine oder andere Teil der Software ändern können sollen, oder Ihr als Lieferant, weil Eure Software so einzigartig ist und Ihr noch nicht mal Euren eigenen Mitarbeitern traut?

Wäre es vielleicht denkbar, vorbereitete Flexibilitäten über HMI-Einstellwerte z.B. Rezepturen einzubauen, so daß der Passwortschutz auf die Änderungserlaubnis am HMI wirkt und nicht auf den KnowHow-Schutz der Bausteine?

Harald
 
oder Ihr als Lieferant, weil Eure Software so einzigartig ist und Ihr noch nicht mal Euren eigenen Mitarbeitern traut?
Harald, ich mache seit Jahren Logistik- Palettier, Verpackungs- und Komissionieranlagen. Sortieranlagen und vieles mehr
aus der Branche. Das ist alles kein Hexenwerk und ich wüsste nicht was da schützenswert ist.

Unsere schnellste Anlage steht in Ungarn, ein Palettierer mit 10.000 Tray´s / h Palettierleistung. Was will man da schützen.
Die Konkurenz hat da kein Interesse weil die das alles genauso können und der Instandhalter darf zur Fehlersuche gerne ins
Programm schauen, dann werde ich wenigstens nicht um 2 Uhr nachts geweckt.
 
Will der Kunde die vielen Passwörter weil seine Mitarbeiter das eine oder andere Teil der Software ändern können sollen, oder Ihr als Lieferant, weil Eure Software so einzigartig ist und Ihr noch nicht mal Euren eigenen Mitarbeitern traut?

Wäre es vielleicht denkbar, vorbereitete Flexibilitäten über HMI-Einstellwerte z.B. Rezepturen einzubauen, so daß der Passwortschutz auf die Änderungserlaubnis am HMI wirkt und nicht auf den KnowHow-Schutz der Bausteine?

Harald
Das möchte das Management als Lieferant. Es soll so wenig wie möglich rausgegeben werden, ohne die Produktion des Kunden zu stark einzuschränken. Das Thema mit den mehreren Passwortstufen finde ich persönlich auch zu unpraktikabel und führt nur zu Ärger, werde ich auch so präsentieren. Es wird wohl dann auf einer Ebene bleiben. Letzteres wäre dann denkbar.
 
Zurück
Oben