Kommunikationsaufbau, interner Datenpunkt
Die Anbindung an den Fernwirkkopf SK-1703 von SAT wird mittels TCP/IP realisiert. Als Schnittstelle werden BSD 4.3 Sockets verwendet. Die SK-1703 Station benötigt für den TCP/IP Anschluss folgende Komponenten:
ein SK-KE/ET Systemelement mit
KR-GPU2 Hardwaremodul, worauf die Application Software Layer laufen, ein KR-ET Ethernet Interface mit Standard D-15 MAU KE/ET Firmware
Ethernet Transceiver 10BASE2 oder 10BASE5
Im KE/ET müssen folgende TCP/IP Parameter konfiguriert werden:
| Länge | Parameter |
|---|---|
| 4 Byte | Eigene Internetadresse |
| 4 Byte | Adressen für jeden Remote Host |
| 2 Byte | TCP/IP Portnummer (Default 2073 - sollte nicht verändert werden) |
| 4 Byte | Internetadresse des Gateway, falls notwendig (Default: nicht definiert) |
| 4 Byte | Subnet mask (Default: nicht definiert) |
| Länge | Parameter |
|---|---|
| 4 Byte | Eigene Internetadresse |
| 4 Byte | Adressen für jeden Remote Host |
| 2 Byte | TCP/IP Portnummer (Default 2073 - sollte nicht verändert werden) |
| 4 Byte | Internetadresse des Gateway, falls notwendig (Default: nicht definiert) |
| 4 Byte | Subnet mask (Default: nicht definiert) |
| Länge | Parameter |
|---|---|
| 4 Byte | Eigene Internetadresse |
| 4 Byte | Adressen für jeden Remote Host |
| 2 Byte | TCP/IP Portnummer (Default 2073 - sollte nicht verändert werden) |
| 4 Byte | Internetadresse des Gateway, falls notwendig (Default: nicht definiert) |
| 4 Byte | Subnet mask (Default: nicht definiert) |
Auf WinCC OA Seite sind folgende Parameter für einen erfolgreichen Verbindungsaufbau notwendig:
Internetadresse der Gegenstation(en=
Optional Hostname(n) der Gegenstation(en) in /etc/hosts
TCP/IP Portnummer(n) in der Konfigurationsdatei - siehe Abschnitt Konfigurationsdatei.
Je Verbindung ein Eintrag in der Konfigurationsdatei - siehe Abschnitt Konfigurationsdatei.
Beim Systemhochlauf sollten die Verbindungen nacheinander aufgebaut werden, um eine Überlastung zu vermeiden. Eine Generalabfrage nach dem Verbindungsaufbau wird von SK 1703 automatisch ausgelöst.
Zur Leitungsüberwachung stellt der SSI Treiber je vorgelagerter Systemkomponente einen Alive-Mechanismus zur Verfügung, je Treiber kann ein Alive-Datenpunkt vom Typ _SSI_Alive angelegt werden.
Datenpunkt _SSI_Alive_1
| Blatt | Datentyp |
|---|---|
| AliveSndDp | natürliche Zahl |
| AliveSndTimeOut | natürliche Zahl |
| AliveRcvDp | natürliche Zahl |
| AliveRcv2Dp | natürliche Zahl |
| AliveRcvTimeOut | natürliche Zahl |
| ActivateDataTypes | Bit |
| WhichDataTypes | Bitmuster |
Dieser Datenpunkt muss den Namen _SSI_Alive_<num> tragen, wobei <num> die Treibernummer angibt. Die Alive-Überwachung zwischen KE/ET und Treiber ist mit Impulsbefehlen realisiert. Das Element AliveSndDp dieses Datenpunkts vom Typ natürliche Zahl kann mit einer Peripherieadresse ausgestattet werden. Ein SendeTimeOut (Element AliveSndTimeOut) gibt dann an, in welchen Abständen dieser Alive-Datenpunkt vom Treiber verschickt werden soll. Dieser Datenpunkt wird zyklisch vom Treiber selbst verschickt, der Eventmanager wird davon nicht verständigt, daher kann das Versenden dieses Datenpunktes auch nicht angezeigt werden.
Ebenso gibt es einen Mechanismus in Empfangsrichtung, der prüft, ob innerhalb einer parametrierbaren Zeit Telegramme von der vorgelagerten Komponente empfangen werden (realisiert durch die Elemente AliveRcvDp und AliveRcvTimeOut des Alive-Datenpunktes). Der AliveRcvDp sollte ein Glättungskonfig (z.B. Alt-Neu-Vergleich oder zeitabhängige Glättung, falls sich der empfangene Wert jedes Mal ändert) erhalten, da er sonst jedes Mal an den Eventmanager weitergeschickt wird. Falls der Timeout erreicht wird ohne ein Telegramm von der Komponente erhalten zu haben, wird diese Komponente solange auf invalid gesetzt bis erneut ein Telegramm von ihr empfangen wird.
Nachdem eine vorübergehend gestörte Verbindung wiederhergestellt ist, führt das KE/ET automatisch eine GA durch und schickt die Daten an den Host.
Der Alive-Datenpunkt stellt außerdem zwei Elemente zur Befehlsverriegelung für jeden Treiber zur Verfügung: Das Datenpunktblatt ActivateDataTypes (vom Typ Bit) bietet eine Sperre für vom Treiber ausgehende Befehle (wenn auf "1" gesetzt). Das Datenpunktblatt WhichDataTypes (vom Typ Bitmuster) bietet dabei einen zusätzlichen Filtermechanismus für ausgehende Befehle (wenn ActivateDataTypes auf "1"). Es werden nur Befehle jener Datenarten verschickt, für die das entsprechende Bit (0...31 für die jeweilige DA) im Blatt gesetzt ist. Wenn ActivateDataTypes auf "0" gesetzt ist, dann werden alle Befehle verschickt, WhichDataTypes hat dann keine Bedeutung.
