The note may be interessting to those of you who wonder .... why a OPC UA setup with a updated device_admin is not working anymore, .... why the UaExpert testclient is responding unexpeted with ... badhostUnknown .... why WinStudio OPC UA client is not appropreate anymore to get access to the ctrlX. At the beginning of ctrlX ( device_admin <=250) unsecure connection/request had been accepted by that ctrlX- device_app. Access to data had been provided and security_features had not been focused on. Nowadays the security token restriction had been implemented inside the device_admin ignoring unsecure requests at all. -> Without securitytoken no answer. (Bad communication .... ) According to that - either fullfill the requirement and get answers or the speak unsecure and do not receive any reply. Hence, e.g. OPC UA server app needs to talk in a secure manner toward device_admin...which is provide in the updated app. In addition the communication of the WinStudio located OPC UA client and (ctrlX CORE placed )OPC UA server is not fullfilling the security standards regarding the security-politics. the client does not talk the "security-languages" the server offers. Unfortunatly the client security features are not update-able yet. Unsecure communication inbetween both OPC UA is only feasible which is not acceptable in many cases. Further info available: https://www.unified-automation.com/news/news-details/article/user-authentication-token-exploit.html https://apps.opcfoundation.org/ProfileReporting/index.htm?ModifyProfile.aspx?ProfileID=45f01bb8-4a15-44f0-94ac-ff28f15869a5 In case the WinStudioHMI is supposed to ignore that security standards - WinStudio can be most likely enabled to get permission to the datalayer-data by operating with a modified OPC UA server app. That needs to be checked/tested and judged seperately and in dialog with the corresponding R&D colleagues/application.
... View more