# S7 Projekt für siemens-fremden OPC Server projektieren? Zugriffsrechte verwalten??



## Schöffi (16 Dezember 2010)

Hallo ich hab mal eine Frage:

Ich habe ein S7-Projket. In diesem Projekt gibt es einen DB der PLS-Daten enthält. Diese Daten werden vom Kunden angefordert. Der Kunde hat einen OPC Server von softing. Somit ist eine Projektierung in NetPro nicht umsetztbar oder? 

Ich hab mir zum testen mir die Demo (softing:server und client) runtergeladen.
Ich konnte durch Anlegen eine Alias.txt (Import der symbole -export der ItemIDs) den "sichtbaren" Zugriff auf meine SPS auf den geforderteten DB beschränken. Für den Zugriff, war keine Proketierung in NEtPro notwendig.

Jedoch musste ich noch feststellen, dass nur der OPC Server Zugriffsrechte vergeben kann. Somit wäre der Kunde in der Lage, wenn ihm alle Adressen bekannt wären auch auf alle Prozessdaten in der SPS zuzugreifen und zwar lesend und schreibend. Lesend kann er gerne auf alle Daten zugreifen - jedoch das Schreiben will/muss ich vermeiden.

Wie kann ich die Zugriffsrechte noch beschränken, wenn es mir nicht möglich ist den OPC Server selbst zu konfigurieren???  

Kann ich evtl. in meinem S7 Projekt eine PC station anlegen mit einem OPC Server (welcher den vom Kunden darstellt) bestücken und dann im Anschluss die verschiedenen Verbindungen projektieren und auch die Zugriffsrechte definieren? Im Anschluss würde ich mit AG_send meinen DB versenden?

Sehe ich das richtig so oder wie kann man hier verfahren, daß ich kontrollieren kann, auf was der Kunde zugreift?

Vielen Dank im vorraus!!


----------



## Rainer Hönle (16 Dezember 2010)

Dieser OPC-Server greift nicht über AG_Send bzw. AG_Receive auf die Daten zu sondern liest diese direkt aus der Steuerung bzw. schreibt diese direkt in die Steuerung. Ein SPS-seitiger Zugriffsschutz ist somit nicht machbar.


----------



## Schöffi (16 Dezember 2010)

Rainer Hönle schrieb:


> Dieser OPC-Server greift nicht über AG_Send bzw. AG_Receive auf die Daten zu sondern liest diese direkt aus der Steuerung bzw. schreibt diese direkt in die Steuerung. Ein SPS-seitiger Zugriffsschutz ist somit nicht machbar.



Leider habe ich genau das festgestellt beim Testen des OPC servers.

Der OPC Server kann aber nur auf die Prozessdaten (E,A, M, T, DB, PAW, PEW) zugreifen und sich nicht das Projekt von der SPS holen oder?

Alle FB und FC bleiben für ihn verborgen oder?


----------



## Rainer Hönle (16 Dezember 2010)

Im FB und FC sind ja auch keine Daten, die der OPC-Server verwenden kann. Was soll er also mit diesen Bausteinen anfangen?
Das Projekt liegt, wenn es sich auf der SPS befinden sollte, auf der (M)MC. Darauf hat dieser OPC-Server keinen Zugriff.


----------



## MSB (16 Dezember 2010)

Also zum einen,
der Zugriff auf Variablen lässt sich so weit ich weiß S7-seitig gar nicht einschränken,
wenn ich weiß worauf ich zugreifen will/muss dann kann ich das.

Der Zugriff auf das Programm mit all seinen Bausteinen lässt sich nur mehr oder weniger wirksam
mit einem entsprechenden Passwort unter "Zugriffsschutz" in der HW-Konfig beschränken,
dann ist es ohne dieses Passwort nicht mehr möglich, das Programm auszulesen, oder selbiges zu ändern.
Wobei mir jetzt eigentlich kein OPC-Server geläufig wäre, welcher das Programm auslesen und oder verändern kann.

Die ganz neuen CPU's welche jetzt bei Siemens rauskommen, unterstützen nun auch die "Bausteinverschlüsselung",
welche mit Step7 V5.5 gekommen ist.

Prinzipiell halte ich den diesartigen Know-How Schutz von SPS-Programmen mal pauschal für Blödsinn.
Ich kann mittlerweile schon gar nicht mehr zählen, wie viele Programme von mir schon neu geschrieben wurden,
weil irgendwas nicht mehr funktioniert hat, der ehemalige Hersteller aber:
a) das Programm nicht rausrückt
b) vom Markt bereinigt wurde (Insolvenz)

Mfg
Manuel


----------



## Schöffi (16 Dezember 2010)

Vielen Dank für die hilfreichen Antworten! 
Ich muss jetzt so viel Vertrauen haben, daß der Kunde mir die Daten nicht überschreibt.

Oder ich verwende evtl. Baugruppen Zugriffschutz des CP! 
Baugruppen Zugriffsschutz:

·	Option "Schutzstufe"
Mit dieser Option können Sie den CP vor unbeabsichtigten oder nicht autorisierten Eingriffen schützen. Folgende Optionen sind in der Klappliste wählbar:

-	Nicht gesperrt
-	Zustandsabhängig

In dieser Einstellung kann nur auf den CP zugegriffen werden, wenn sich die CPU im Betriebszustand STOP befindet.

Jedoch bin ich mir nicht sicher, ob der CP überhaupt die Daten bereit stellt, wenn ich das AG_Send oder AG_receive nicht verwende.

Vielen Dank

Sanne


----------



## MSB (16 Dezember 2010)

Im Prinzip kommuniziert der OPC-Server relativ ähnlich wie Step7 auch.
Der Betriebszustand der CPU spielt dabei überhaupt keine Rolle.

d.H. Du könntest mit Step7, dem OPC-Server, irgend einen Bediengerät, Parameter auch bei CPU-Stop verändern.
Allerdings ist das für dich imho keine Option, weil ich:
a) Wenn ich jetzt böswillig wäre immer noch mit Profibus/MPI kommunizieren könnte
b) Die Kommunikation deines OPC-Servers bei CPU-Stop vermutlich nicht allzu viel sinn haben dürfte,
oder soll das nur ein Progrämmchen von dir werden mit dem man nur Parameter verändern kann,
und keinerlei Prozessdaten beobachten soll.

Mfg
Manuel


----------



## Rainer Hönle (16 Dezember 2010)

MSB schrieb:


> b) Die Kommunikation deines OPC-Servers bei CPU-Stop vermutlich nicht allzu viel sinn haben dürfte,


Es können zumindest die Daten in DBs so verändert werden, dass man sich beim nächsten Stop-Run-Übergang wundert


----------



## Schöffi (16 Dezember 2010)

Ich möchte Prozessdaten aus der SPS nur Beobachten lassen.
Der Kunde nutzt einen OPC-Server um sich die Informationen abzuholen.

Mein Problem liegt nur darin, daß ich Bedenken habe, weil der Kunde durch die Anbindung seines OPC-Servers auch die Prozessdaten steuern kann. Dies wollte ich vermeiden. Das geht aber nicht, den der OPC server ist der, welche die Lese-und Schreibrechte vergibt.

Ich selbst nutze keinen OPC-Server!
Meine Aufgabe war es, Prozessdaten für den Kunden über IE bereit zustellen.

Ich habe dies auch anfangs über eine UDP verbindung projektiert, was auch geklappt hat.

Jetzt habe ich erfahren, daß der Kunde einen OPC-Server hat und wollte schaun, wie "sicher" eine solche Kommunikation ist....


----------



## Ralle (16 Dezember 2010)

Du könntest die Prozessdaten in einen extra DB umkopieren und diesen DB für den Kunden dokumentieren. Wenn er darin Daten überschreibt, dann werden sie beim nächsten "Datenupdate" von der SPS eh wieder korrigiert. Außerdem dienen sie ja nur zur Anzeige, die SPS arbeitet mit ihren eigenen Daten.


----------



## PN/DP (17 Dezember 2010)

Ralle schrieb:


> Du könntest die Prozessdaten in einen extra DB umkopieren und diesen DB für den Kunden dokumentieren.


Genau das würde ich auch empfehlen. Der Kunde bekommt nur diese Daten-Kopien dokumentiert.
Versehentliches oder absichtliches Schreiben auf diese Daten-Kopien hat keine negativen Auswirkungen, da die SPS diese Daten nicht verarbeitet sonder nur überschreibt.

Harald


----------



## Dr. OPC (20 Dezember 2010)

> Mein Problem liegt nur darin, daß ich Bedenken habe, weil der Kunde durch die Anbindung seines OPC-Servers auch die Prozessdaten steuern kann. Dies wollte ich vermeiden. Das geht aber nicht, den der OPC server ist der, welche die Lese-und Schreibrechte vergibt.


Die Zugriffsrechte lassen sich beim OPC Server normalerweise einstellen (und zwar für jeden DB und sogar für jeden Datenpunkt einzeln). Ob das beim Softing auch so ist weiß ich nicht, wenn du den SimaticNET OPC Server (von Siemens) nehmen würdest, dann geht das auf jeden Fall. Dort kannst du z.B. der gesamten S7-Verbindung, die der OPC Server verwendet, ein Default-Leserecht geben. Dann kann über OPC NUR gelesen werden nicht aber geschrieben. Über die Symbol-Datei geht sogar noch mehr dort kannst du ganze DBs "unsichtbar" machen, damit kann (zumindest symbolisch) auch nicht auf sie zugegriffen werden.

Das Umkopieren (der relevanten Daten) in einen eigenen DB ist auch ein Ansatz, der dir die Konfiguration erleichtert. Dann brauchst du NUR diesen einen DB über OPC "sichtbar" machen und kannst allen anderen Daten nur leserecht "R" geben. Weiterhin könntest du in der SPS sicherstellen das in diesen DB nur "reinkopiert" wird aber die Daten selber nicht im restlichen ProgrammCode verwendet werden. So könntest Du den Softing OPC Server vielleicht "austricksen" indem du nur diesen "spezial DB" in der konfiguratin übrig lässt.

Die Angst das jemand (der die genaue ItemID kennt) trotzdem an deinen mühsam eingestellten Zugriffsrechten vorbei auf die Daten zugreift besteht beim SimaticNET OPC Server nicht. (vielleicht ist er deshalb auch etwas teurer als der von Softing)


----------



## winnman (20 Dezember 2010)

sollte der Kunde wirklich so "heikel" sein bzw ews geht um eine wirklich sehr sensieble Anlage, dann würde ich folgendes machen: eine Seperate SPS in die die Anlagenführende SPS den entsprechenden Zustand schreibt, OPC, . . . holt sich hir die Daten ab.
Die "Befehle" werden auch in diese CPU geschrieben, die anlagenführende SPS holt sich hier die Daten Ab und prüft sie auf entsprechende Gültigkeit.
Wenn die Übertragung zwischen den CPU´s nicht auf MPI, Ethernet, .. . beruht, dann kann auch von aussen nicht auf das Programm der "Anlagenführenden CPU" zugegriffen werden. Mit allen nachteilen der Fernwartung, . . .


----------

