Also OPC UA ist aus meiner Sicht die richtige Technologie für dich. Und zwar aus folgenden Gründen:
Wenn Du ein HMI System entwickelst/erweiterst und Daten von Fremdsystemen vor allem Messgeräten konsumierst, wirst du bei diesen "Geräten" zwangsläufig auf OPC UA Server stoßen. Denn nur OPC UA (und nicht OPC Xi) Server können in diesen Geräten, die z.B. auf vxWorks oder embedded Linux oder noch exotischeren OS laufen, implementiert werden. Deine Datenlieferanten werden also OPC UA Server sein. Wenn du in deinem HMI nun aber einen Xi-Client reinbaust, der .NET(WCF) voraussetzt, kannst du nicht mehr "direkt" mit der nicht-Windows-basierten Gerätewelt kommunizieren, denn OPC UA und OPC Xi sind nicht "protokollkompatibel". Wenn du hier also nicht schon wieder irgendwelche Gateways oder Umsetzer verwenden willst, bleibt dir selbst als "rein-auf-Windows-HMI-System" das auf einem leistungsstarken XP/7 PC mit .NET Framework sitzt, nichts anderes übrig als auch OPC UA zu machen.
Nun ist das auch nicht die schlechteste Wahl denn OPC UA ist der Standard der Zukunft und wird von deutlich mehr Herstellern unterstützt als beispielweise Xi (ausser Emerson und Advosol macht das praktisch niemand). Auf der OPC UA Seite stehen mitlerweile die großen wie Siemens, ABB, Bosch, Phönix, Beckhoff, Mitsubishi, ... also aus meiner Sicht ist damit OPC UA damit zumindest in Europa als neue Schnittstelle zur SPS gesetzt. Auch die HMI Systeme werden UA unterstützen WinCC mit dem nächsten ServicePack (ging vorher schon mit einem Optionspaket), Iconics Genesys64, Yokogawa und andere werden sicher folgen.
OPC UA ist an sich Sprachunabhängig, es gibt derzeit drei Kommunikationsstacks (C, .NET und Java) alle diese drei UA-Stacks sind "auf dem Kabel" kompatibel. Ein in Java entwickelter OPC UA Client kann also problemlos mit einem in ANSI C programmierten OPC UA Server kommunizieren. Wenn also dein HMI schon in .NET entwickelt ist, spricht nichts dagegen diesen um einen UA Client Kanal zu erweitern. Du nimmst die einfach den .NET Stack der OPC Foundation und kannst loslegen.
Von OPC Xi würde ich die Finger lassen da es (nur) ein "Abklatsch" der alten klassischen OPC Schnittstellen auf WCF-Basis ist. Das mag auf den ersten Blick (funktional) ähnlich aussehen, ist aber ganz anders als ein "echtes" OPC UA das (auch / unter anderem) in .NET programmierbar ist. Die Modellierungen der Daten, die derzeit von vielen anderen organisationen betrieben wird setzt auf OPC UA auf, z.B. FDI, PLCopen, SmartGrid, ISA95, ... erst damit kommt der eigentliche "Mehrwert" von OPC UA erst zustande (Xi bietet hier nichts, da kannst du auch gleich das "alte" OPC weiterbenutzen)
Apropos "altes" OPC, hier muss man natürlich davon ausgehen dass es das noch eine ganze Weile geben wird, nicht jeder ist so schnell wie Siemens

und Beckhoff und hat schon einen UA Server auf dem Markt (der UA Server von Siemens wohnt ja auch immer noch auf einem PC und nicht der S7). Für die "Übergangszeit" der nächsten 5-10 Jahre, werden "alte" OPC Server über sogenannte Wrapper integriert. Sie liefern dann nicht alle schicken Features von UA aber lesen/schreiben/beobachten und ein paar Alarme wird es immerhin geben (mehr konnten die "alten" OPC Server ja nicht). Neue Dinge wie Transaktionssicherheit, feingranulare Zugriffsrechte, verschlüsselte Übertragung, komplexe Datentypen, Redundanz, robuste/fehlertolerante Verbindungen, Auditfunktionalität, ... gibt es halt nur bei OPC UA.