With very limited functionality, yes. Simple tests shows it works, but more complex tests shows this connection is not recommended (actually it doesn't work properly).

OPC DA works in polling mode. Between two pollings, everything that is changed meanwhile remains unnoticed. This means that fast informations, such as Fault Indications remain unnoticed.

In WinCC it'seven worse, because you cannot define the polling cycle for OPC. The way the information is used determines the polling cycle. For example, if a variable is used on a screen, the "update cycle" here configured is the polling cycle. WinCC reads what it needs and when it needs, and thisisn't controlled on the communication channel. If the screen is not showned, the variable is never polled.

For AlarmLogging the default update time(polling) is 500ms. This time can be changed to 250ms, but this value is not recommended (see link) and faster alarms will still remain unnoticed:

https://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=en&objid=22269712&caller=view

This situation happens with any system connected to Simatic WinCC. It works only if the OPC Server has a method to buffer the events and release then on a cycle bigger than WinCC polling cycle. See the discussion on A&D Forum:

/tf/WW/en/Posts/5970

- Double indications: AlarmLogging doesn't work with them, not even OPC AE. In WinCC an event must becreated for Open and another Close position. For intermediate (00) and fault (11) positions extra events should be created.PAS CC handles these informations without problems.

-In event list onlytime stamps, free text and values/indications (e.g.: open/close)are available. No validity, cause of transmission, additional cause and other indications are available.

- Importing data into WinCC is easy (OPC Browser), but then these information must be configured manually in Alarm Logging and TagLogging.

- For commands issued from HMI there will be not messages about interlockings, command executions and feedbacks. If the command is executed and it has a feedback, there will be a normal event showing the command was executed. If the command is not executed, there'll be nothing. Surely this can be done configuring flags to monitor commands and these flags may generate events on event lists, demanding more engineering time and testing.