Herstellerspezifische Protokolle
Kommen Softwaretool und Automatisierungskomponente vom selben Hersteller, dann kommen oft proprietäre Kommunikationsprotokolle zum Einsatz. Eine SPS wird üblicherweise nicht über einen Feldbus programmiert. Auch diese Art der Kommunikation kann mit FDT realisiert werden, wie in Bild 4 dargestellt ist. In diesem Fall kommen der Comm-DTM und der DTM für die SPS vom selben Hersteller. Die Befehle, die zwischen den beiden DTMs verwendet werden, sind herstellerspezifisch. Es gibt keine Annex-Spezifikation von der FDT Group und daher kann diese Kommunikation auch nicht von DTMs anderer Hersteller verwendet werden. Warum macht die Verwendung von FDT hier überhaupt Sinn, speziell für die Abbildung einer SPS? Die Antwort darauf lautet: Die DTMs können nicht nur im eigenen Softwaretool, sondern auch in anderen Tools verwendet werden. Für eine SPS bedeutet dies, dass der entsprechende DTM nicht nur im eigenen Programmiertool verwendet werden kann, sondern z.B. auch in einfachen Inbetriebnahme- oder Diagnose-Tools. Darin werden dann nur die vom DTM bereitgestellten Diagnose-Benutzeroberflächen oder die Gateway-Kommunikation zu den angeschlossenen Sensoren/Aktoren verwendet. Die eigentlich SPS-Programmierfunktion ist üblicherweise nicht in einem solchen DTM enthalten.
Fazit
FDT definiert eine Kommunikationsarchitektur, die sich in der Praxis in vielen Anwendungsfällen bewährt hat. FDT unterstützt die Kommunikation über alle Ebenen und Protokolle hinweg. Auch herstellerspezifische Protokolle können unterstützt werden. Die Softwaretools, die FDT unterstützen, können einfach um weitere Kommunikationsarten erweitert werden, indem entsprechende Comm- und Gateway-DTMs integriert werden. Für viele auf dem Markt erhältlichen PC-Einsteckkarten, Modems und Koppler gibt es DTMs. Diese können einfach verwendet werden, was eigene Entwicklungskosten einspart.
