Authentication, negotiation of supported services and optional communication parameters

This sample shows how a plain text password can be activated and configured to authenticate the connection in a TwinCAT IEC 61850 client or server application. This sample also shows how the server application can control the authentication process itself at runtime. This means that the application can accept or reject the connection depending on the password received. This sample also shows how the services and parameters supported by the IEC 61850 server are enabled and configured in the TwinCAT client and server application. The sample also shows how the server can control the negotiation of the supported services and parameters itself at runtime. The TwinCAT IEC 61850 server application can, for example, reject the services and/or parameters proposed by the client depending on the password received and thus restrict access to these services or parameters for certain connections or users. If you are using an older version of the TwinCAT IEC 61850 Telecontrol Configurator, the functionalities presented in this sample may not yet be supported. To be able to compile and test this sample without errors, you need a newer version of the TF6510 IEC 61850 Telecontrol.

System requirement

TF6510 IEC 61850 Telecontrol v3.2.98.0 or newer

Download TwinCAT XAE Project (*.zip): Sample31.zip

General information about this sample project

The sample consists of two separate TwinCAT IEC 61850 projects. After unpacking the zip file, you will find a TwinCAT IEC 61850 client project in the subfolder \Client\Sample31 and a TwinCAT IEC 61850 server project in the subfolder \Server\Sample31. Both projects are coordinated, only the IP address of the server has to be adjusted in the code of both projects. The client will establish a connection to the server when you download, activate and start the projects on two TwinCAT target systems connected via LAN.

The Client - basic sample project and Server - basic sample project serve as the basis for the sample project.

Activation and configuration of the authentication function in the TwinCAT Telecontrol Configurator

In the simplest variant, the authentication function can already be activated in the TwinCAT Telecontrol Configurator. The settings required for this can be found in the configuration dialog of the IED device. As shown in the image below, please set the parameter: Authentication mode to the value: Password.

Authentication, negotiation of supported services and optional communication parameters 1:

The IEC 61850 client or server project code generation generates the code required to activate the authentication function and configures a default password with the value: "PASSWORD" and a default mechanism with the name: "2.2.3.1". Bit 0 of the protocol setting: "nRequirements" activates the authentication function.

Standard authentication parameters in the generated TwinCAT IEC 61850 project

Namespace: TcTelecontrol

Type: Global Variable List (GVL)

Client project:

Authentication, negotiation of supported services and optional communication parameters 2:

Server project:

Authentication, negotiation of supported services and optional communication parameters 3:

The default values can only be adjusted in the generated PLC code and not in the TwinCAT Telecontrol Configurator, as the authentication password and the mechanism name cannot be saved in the SCL file. Currently, the TwinCAT IEC 61850 implementation only supports the "Password" authentication method defined in the SCL. Other authentication methods "weak", "strong" or "certificate" are not supported. However, you can use TLS to encrypt all client-server communication. You can find a sample of this here: TLS - Secure client-server communication with the help of certificates or PSK.

Unilateral vs. mutual authentication mode

The unilateral authentication mode (one-way authentication) is the standard mode for IEC 61850 authentication and is also supported by most devices. The mutual authentication mode (two-way authentication) is rather uncommon. With unilateral authentication, the password is only sent in one direction, from the client to the server. The server verifies the password and, if successful, the connection is maintained (accepted) or closed (rejected) in the event of an error. With mutual authentication, both communication partners verify the password of the other. First, the server verifies the password received from the client. If successful, the server also sends a password back to the client as a response. The client also verifies the password received from the server and if successful, the connection is maintained (accepted) or closed (rejected) if an error occurs. The unilateral authentication mode is configured by default in the TwinCAT IEC 61850 implementation.

Configuration of the optional client and server communication parameters

Some communication parameters in the protocol settings are optional parameters. It is not absolutely necessary for these parameter values to be transmitted. Nevertheless, it is possible that missing optional communication parameters may lead to the connection being terminated or communication errors. The connection request is often rejected by the other communication partner due to missing optional parameters. There are also devices that respond to the receipt of the optional parameters by terminating the connection. In such cases, you can adjust the protocol settings and activate or deactivate the transmission of the optional communication parameters according to the requirements. Adjust the protocol settings in the global variable list "TcTelecontrol" of the server or client project. In the sample projects described here (server and client), the transmission of the following optional parameters is activated:

"nCalled_AP_InvID:=0"
"nCalled_AE_InvID:=0"
"nCalling_AP_InvID:=0"
"nCalling_AE_InvID:=0"

The value: 0 (null) is a valid value for these parameters and this value is also transmitted. The value: 16#FFFFFFFFFF configures a parameter as optional and in this case no value is transmitted.

Simple authentication with a master password

In the simplest variant of authentication, the server only accepts a single authentication password. In this case, you only need to adjust the already generated default password: "PASSWORD" in the created server or client application. For this functionality, no further changes or extensions to the generated PLC code are required for the time being.

This one password can also be referred to as the master password. Any client using this password can successfully connect to the server. If your server implementation allows multiple connections, then multiple clients can also establish a connection to the server with the same master password. In the documented server sample, the main password is: "GeneralPass". This password can be configured via the server's protocol settings. In the sample code, you will find the parameter value in the global variable list: "TcTelecontrol" (see image below). The important/relevant code sections are highlighted in bold.

Namespace: TcTelecontrol

Type: Global Variable List (GVL)

VAR_GLOBAL

    (*…*)

    (* IED data model *)
    fbIED: FB_IED_IED;
    bMutual: BOOL:=FALSE;
    (* Server container *)
    fbIEDServer: FB_iec61850ServerClass:=(
        ipIED:=fbIED,
        settings:=( bEnable:=TRUE,
                    sLocalHost:='127.0.0.1',
                    sAuthent_Value:='GeneralPass',
                    sMechanism_Name:='2.2.3.1',
                    nRequirements:=16#01,
                    eAcse_Authent:=SEL(bMutual, E_AcseAuthentication.Unilateral, E_AcseAuthentication.Mutual),
                    sResponding_Value:='RespondingPass',
                    nCalled_AP_InvID:=0,
                    nCalled_AE_InvID:=0,
                    nCalling_AP_InvID:=0,
                    nCalling_AE_InvID:=0));
    (* Server connections *)
    fbIEDServerSession1: FB_IEDServerSession:=(
        fbConnection:=(
            ipServer:=fbIEDServer,
            settings:=( bEnable:=TRUE,
                        sAuthent_Value:='Session1Pass')));

    (*…*)

END_VAR

Authentication with a connection-specific password

In the TwinCAT IEC 61850 server implementation, an additional connection-specific password can optionally be configured for each available server connection in addition to the main password. This password can be configured via the configuration settings of the server connection (e.g. "fbIEDServerSession1.fbConnection.settings"). The server in our sample above only accepts one connection. The configured connection-specific password is "Session1Pass". The server only accepts the server connection if the client sends either the main password or the configured connection-specific password via this server connection (in the sample above "GeneralPass" or "Session1Pass"). For servers with only one configured (permitted) server connection, you can assign a second password equivalent to the main password in this way and use it like a main password.

During the connection establishment at the TCP/IP level, a free (unoccupied) server connection instance is assigned to a client that wants to connect to the server by default. However, it is possible to bind a client to a specific server connection via the client's IP address. In the sample below, we bind a client with the IP address "192.168.10.140" to the connection instance "fbIEDServerSession1" and another client with the IP address "192.168.10.160" to the connection instance "fbIEDServerSession2".

A client with the IP address: "192.168.10.140" can only connect to the instance "fbIEDServerSession1" if it sends the master password or the password "Session1Pass". The client with the IP address "192.168.10.160" can only connect to the instance "fbIEDServerSession2" if it sends the master password or the password "Session2Pass".

Namespace: TcTelecontrol

Type: Global Variable List (GVL)

VAR_GLOBAL

    (*…*)

    fbIEDServerSession1: FB_IEDServerSession:=(
        fbConnection:=(
            ipServer:=fbIEDServer,
            settings:=(bEnable:=TRUE,
                       sAuthent_Value:='Session1Pass',
                       sAcceptHost:='192.168.10.140',
                       eAccept:=E_SocketAcceptMode.eACCEPT_SEL_HOST)));

    fbIEDServerSession2: FB_IEDServerSession:=(
        fbConnection:=(
            ipServer:=fbIEDServer,
            settings:=(bEnable:=TRUE,
                       sAuthent_Value:='Session2Pass',
                       sAcceptHost:='192.168.10.160',
                       eAccept:=E_SocketAcceptMode.eACCEPT_SEL_HOST)));

    (*…*)

END_VAR

Authentication with several additional passwords

If the server is to accept multiple passwords, or the client is to establish the connection to the server not only with one password, but with several different passwords (sometimes with one, sometimes with the other), then you must add a few lines to the generated code yourself.

Six different sample passwords were defined in the "passList" array variable of the client sample project in order to present the different authentication options:

"GeneralPass"
"Session1Pass"
"AnotherPass"
"MorePass"
"FurtherPass"
"UnknownPass"

The variable "passIndex" selects the password that the client should use the next time a connection is established (see below). The global variable "bMutual" can be used to switch between the two authentication modes unilateral and mutual. By default, the authentication mode is configured unilaterally in the sample.

Namespace: TcTelecontrol

Type: Global Variable List (GVL)

VAR_GLOBAL

    (*…*)

    (* IED data model *)
    fbIED: FB_IED_IED;
    bMutual: BOOL:=FALSE;
    passIndex: DINT(0..5):=0;
    (* Authentication passwords *)
    passList: ARRAY[0..5] OF STRING:=['GeneralPass',
                                    'Session1Pass',
                                    'AnotherPass',
                                    'MorePass',
                                    'FurtherPass',
                                    'UnknownPass'];
    (* Client connection *)
    fbIEDClient : FB_IEDClient:=(
        fbConnection:=( ipIED:=fbIED,
                        settings:=( sRemoteHost:='127.0.0.1',
                                    sAuthent_Value:=passList[LIMIT(0, passIndex, 5)],
                                    sMechanism_Name:='2.2.3.1',
                                    nRequirements:=16#01,
                                    eAcse_Authent:=SEL(bMutual, E_AcseAuthentication.Unilateral, E_AcseAuthentication.Mutual),
                                    sResponding_Value:='RespondingPass',
                                    nCalled_AP_InvID:=0,
                                    nCalled_AE_InvID:=0,
                                    nCalling_AP_InvID:=0,
                                    nCalling_AE_InvID:=0)));

    (*…*)

END_VAR

You will find some additional variables in both the client and the server sample application. These variables, such as "bAccepted", "eAareResult", "eAareDiagnostic" or "sPassword" can be used for visual monitoring in online mode or for diagnostic purposes. The values of these variables are set, for example, in the client sample project in the implementation code of the "OnAssociateCnf" event handling routine of the "FB_IEDClient" function block. In the server sample project, these values are set in the implementation code of the "OnAssociateInd" event handling routine of the "FB_IEDServerSession" function block.

FUNCTION_BLOCK FB_IEDClient IMPLEMENTS I_ScsmAbortIndEventSink,
                    I_ScsmAssociateCnfEventSink,
                    I_ScsmGetServerDirectoryCnfEventSink,
                    I_ScsmGetLogicalDeviceDirectoryCnfEventSink,
                    I_ScsmGetLogicalNodeDirectoryCnfEventSink,
                    I_ScsmGetDataValuesCnfEventSink,
                    I_ScsmSetDataValuesCnfEventSink,
                    I_ScsmReportIndEventSink,
                    I_ScsmControlCnfEventSink,
                    I_ScsmLastApplErrorIndEventSink,
                    I_ScsmCommandTerminationIndEventSink
VAR_INPUT
    fbConnection : FB_iec61850ClientClass:=(ipAbortInd:=THIS^,
                        ipAssociateCnf:=THIS^,
                        ipGetServerDirectoryCnf:=THIS^,
                        ipGetLogicalDeviceDirectoryCnf:=THIS^,
                        ipGetLogicalNodeDirectoryCnf:=THIS^,
                        ipGetDataValuesCnf:=THIS^,
                        ipSetDataValuesCnf:=THIS^,
                        ipReportInd:=THIS^,
                        ipControlCnf:=THIS^,
                        ipLastApplErrorInd:=THIS^,
                        ipCommandTerminationInd:=THIS^);
END_VAR
VAR

    (*…*)

    bAccepted       : BOOL:=FALSE;
    sPassword       : STRING:='';
    sMechanismName  : STRING:='';
    sRespondingPass : STRING:='';
    eAareResult     : E_ACSE_AareResult:=E_ACSE_AareResult.Accepted;
    eAareDiagnostic : E_ACSE_AareDiagnostic:=E_ACSE_AareDiagnostic.Null;
    eAbrtDiagnostic : E_ACSE_AbrtDiagnostic:=E_ACSE_AbrtDiagnostic.Null;

    (*…*)

END_VAR


    (*…*)

CASE state OF
    0:
        IF _bAbort THEN
            _bAbort:= FALSE;
            bSuccess:= fbConnection.AbortReq(ipReason:=fbAbortReason, ipSink:=0, ipResult=>ipResult);
            state:= SEL(bSuccess, 100, 1);
        ELSIF eState = E_AsyncEnvironmentState.Idle AND (_bConnect OR _bReconnect) THEN
            _bConnect:= FALSE;
            bGetAllServerValues:= SEL(_bReadAllData, bGetAllServerValues, TRUE);

            fbConnection.settings.eAcse_Authent:= SEL(TcTelecontrol.bMutual, E_AcseAuthentication.Unilateral, E_AcseAuthentication.Mutual);
            fbConnection.settings.sAuthent_Value:= TcTelecontrol.passList[LIMIT(0, passIndex, 5)];
            bSuccess:= fbConnection.AssociateReq(ipSink:=0, ipResult=>ipResult);
            state:= SEL(bSuccess, 100, 1);

    (*…*)

END_CASE

Control of the authentication process in the server application

The server in the standard implementation automatically verifies the mechanism name and the received password internally. If the result of this check is positive, the connection is accepted (maintained) by the server and rejected (closed) if the result is negative. This functionality does not require any special extensions to the automatically generated PLC code. However, it is also possible to actively control the authentication process at runtime in the server application. This means that the server can decide itself (spontaneously) whether to accept or reject a connection. In this case, if conditions allow, a connection rejected by internal verification can still be accepted, and an internally accepted connection can still be rejected.

As an example of the unilateral authentication mode with additional passwords, the following behavior is implemented in the server sample:

With the main password "GeneralPass", the server should accept the connection. This password is configured in the global variable list "TcTelecontrol" and the server would have accepted the password even without a special code extension.
The client password "Session1Pass" should be rejected by the server. In the standard implementation, the server would have accepted the connection as this password is also configured as a connection-specific password in the global variable list "TcTelecontrol".
Three additional client passwords "AnotherPass", "MorePass" and "FurtherPass" should be accepted by the server. In the standard implementation, the internal verification would have rejected the connection requests with these passwords.
The connection with the password "UnknownPass" and all other unknown passwords should be rejected by the server. The internal verification in the standard implementation would also have rejected the connection requests with these passwords.

An additional PLC code in the "OnAssciateInd" event handling routine allows the server application to subsequently change the result of the internal verification; this is used in the server sample. The values of the additional local variables of the "FB_IEDServerSession" function block are set in the implementation code of the event handling routine: "OnAssociateInd".

FUNCTION_BLOCK FB_IEDServerSession IMPLEMENTS I_ScsmAbortIndEventSink, I_ScsmAssociateIndEventSink, I_ScsmReleaseIndEventSink
VAR_INPUT
    fbConnection : FB_iec61850ConnectionClass:=(ipAbortInd:=THIS^,
                                        ipAssociateInd:=THIS^,
                                        ipReleaseInd:=THIS^);
END_VAR
VAR

    (*…*)

    bAccepted       : BOOL:=FALSE;
    sPassword       : STRING:='';
    sMechanismName  : STRING:='';
    sRespondingPass : STRING:='';
    eAareResult     : E_ACSE_AareResult:=E_ACSE_AareResult.Accepted;
    eAareDiagnostic : E_ACSE_AareDiagnostic:=E_ACSE_AareDiagnostic.Null;
    eAbrtDiagnostic : E_ACSE_AbrtDiagnostic:=E_ACSE_AbrtDiagnostic.Null;

    (*…*)

END_VAR

The Boolean variable "bAccepted" will be "TRUE" if the internal verification accepts the authentication data and thus also the connection. However, this variable will also be "TRUE" if the server authentication function has not been activated in the protocol settings.

User-defined OnAssociateInd event handling routine of the server

The result of the internal verification can only be subsequently influenced if the authentication function of both communication partners is active and all other framework conditions (communication parameters such as mechanism name and password) have been correctly configured or received. The server application can access the interface pointer "ipAuthentication" of type I_ScsmAuthenticationClass via the input variable "ipAA" of the event handling routine "OnAssociateInd". The interface pointer belongs to the authentication object, which also carries out the verification internally. The internal verification is already carried out by the server before the "OnAssociateInd" event handling routine is called. The first result is already known when the method is called. The interface pointer "ipAuthentication" provides the application methods to query the result of the verification, to accept a connection rejected by the internal verification, or to reject an accepted connection. A connection that has already been rejected by internal verification cannot be rejected again and a connection that has been accepted by internal verification cannot be accepted again. In this case, the "Accept" or "Reject" method calls will return FALSE (error).

METHOD OnAssociateInd : BOOL
VAR_INPUT
    ipAA     : I_ScsmAssociationClass;
END_VAR
VAR_OUTPUT
    ipResult : I_AsyncServiceResultClass;
END_VAR


(*…*)

bAccepted:= FALSE;
sMechanismName:= '';
sPassword:= '';
sRespondingPass:= '';
eAareResult:= E_ACSE_AareResult.Accepted;
eAareDiagnostic:= E_ACSE_AareDiagnostic.Null;
eAbrtDiagnostic:= E_ACSE_AbrtDiagnostic.Null;
IF (ipAA <> 0) AND_THEN (ipAA.ipAuthentication <> 0) THEN
    IF ipAA.ipAuthentication.GetVerifyResult(bAccepted=>bAccepted,
                            sMechanismName=>sMechanismName,
                            sPassword=>sPassword,
                            sRespondingPass=>sRespondingPass,
                            eResult=>eAareResult,
                            eDiagnostic=>eAareDiagnostic,
                            eAbrtDiagnostic=>eAbrtDiagnostic)
    THEN
        IF bAccepted THEN
            IF (sPassword = 'GeneralPass') THEN
                ;
            ELSIF (sPassword = 'Session1Pass') THEN
                bSuccess:= ipAA.ipAuthentication.Reject();
            ELSE
                ;
            END_IF
        ELSE
            IF (sPassword = 'AnotherPass') OR_ELSE (sPassword = 'MorePass') THEN
                bSuccess:= ipAA.ipAuthentication.Accept(sRespondingPass:='RespondingPass');
            ELSIF (sPassword = 'FurtherPass') THEN
                bSuccess:= ipAA.ipAuthentication.Accept(sRespondingPass:='InvalidRespondingPass');
            ELSIF (sPassword = 'UnknownPass') THEN
                ;
            ELSE
                ;
            END_IF
        END_IF
        ipAA.ipAuthentication.GetVerifyResult(bAccepted=>bAccepted,
                            sMechanismName=>sMechanismName,
                            sPassword=>sPassword,
                            sRespondingPass=>sRespondingPass,
                            eResult=>eAareResult,
                            eDiagnostic=>eAareDiagnostic,
                            eAbrtDiagnostic=>eAbrtDiagnostic);
    END_IF

    (* Negotiation example of max. number of outgoing called and calling services: *)
    ipAA.ipAuthentication.nNegotiatedMaxServOutCalled:= 5; (* Default: 10 *)
    ipAA.ipAuthentication.nNegotiatedMaxServOutCalling:= 5; (* Default: 10 *)

    (* Example of supported services negotiation: *)
    IF ipAA.ipAuthentication.ipNegotiatedServicesSupported <> 0 THEN
        (* Disable support for file services *)
        ipAA.ipAuthentication.ipNegotiatedServicesSupported.bFileClose:= FALSE;
        ipAA.ipAuthentication.ipNegotiatedServicesSupported.bFileDelete:= FALSE;
        ipAA.ipAuthentication.ipNegotiatedServicesSupported.bFileDirectory:= FALSE;
        ipAA.ipAuthentication.ipNegotiatedServicesSupported.bFileOpen:= FALSE;
        ipAA.ipAuthentication.ipNegotiatedServicesSupported.bFileRead:= FALSE;
        ipAA.ipAuthentication.ipNegotiatedServicesSupported.bFileRename:= FALSE;
        ipAA.ipAuthentication.ipNegotiatedServicesSupported.bObtainFile:= FALSE;
    END_IF
END_IF

(*…*)

OnAssociateInd:= fbConnection.AssociateRsp(ipResult=>ipResult);

In this server sample, the "GetVerifyResult" method call first reads the result of the internal verification and some diagnostic information. The internally already accepted connection with the password "Session1Pass" is then rejected with the "Reject" method call and the internally already rejected connections with the passwords "AnotherPass", "MorePass" and "FurtherPass" are still accepted with the "Accept" method call. Finally, the verification result is read again. Only then may the response be sent to the client with the "AssociateRsp" method call.

Dynamic negotiation of supported server services and parameters

In most use cases, the services and parameters supported by the server can be configured via protocol settings in the global variable list "TcTelecontrol". The settings made there then apply to all connections on the server. This means that all clients can only negotiate with the server those services that have been globally configured (activated) for all connections.

In some use cases, however, it may be necessary to negotiate different server services and parameters depending on the client connection (e.g. depending on the client's IP address or authentication password). The server could allow/support more services with a specific client connection and fewer with another client connection.

The event handling routine "OnAssociateInd" can be used to negotiate the supported services and parameters at runtime (connection-dependent). A server application can access the internal result of the negotiated services and parameters via the interface variable "ipAA.ipAuthentication". The result can still be manipulated as required at this stage. In the sample code above, the maximum number of incoming and outgoing confirmed requests (MMS request) is limited from the default value of 10 to 5 and support for all MMS file services is disabled. Only then is the new result sent back to the client in the answer telegram.

Simple authentication in mutual authentication mode

The mutual authentication mode must be supported by both communication partners and is rather unusual in IEC 61850. In this mode, the server sends a password back to the client as a response. This response password is already configured in the server sample project with the value "RespondingPass" in the global variable list "TcTelecontrol". In the client sample project, a password "RespondingPass" is also configured in the global variable list "TcTelecontrol". This is the password that the client expects as a response from the server. The client's internal verification function will compare this password with the password received from the server. If successful, the connection is maintained and if unsuccessful, it is closed again. In the simplest configuration, the response passwords only need to be adjusted/configured in the generated server and client sample projects and the mutual authentication mode activated in the protocol settings. Additional code in the "OnAssociateInd" or "OnAssociateCnf" event handling routines is not required for mutual authentication in the basic function.

User-defined OnAssociateCnf event handling routine of the client

In mutual authentication mode, the client, like the server, can also actively control the authentication process at runtime. However, the server must have already accepted the password received from the client. A connection rejected by the server (negative response) can no longer be accepted on the client side. In unilateral mode, it is not necessary to implement the "OnAssociateCnf" event handling routine. The user-defined implementation of the "OnAssociateCnf" event handling routine presented here is only useful in mutual authentication mode.

To present the various available options, the following behavior was implemented in the sample:

The server responds to the client password "FurtherPass" with an incorrect password "InvalidRespondingPass". In the standard implementation, the client would have closed the connection again due to the incorrect response. In our sample, the wrong password is accepted and the connection is maintained.
With the client password "Session1Pass", "UnknownPass", the connection is already rejected by the server.
The server responds to all other client passwords with the password "RespondingPass". With the client password "MorePass", however, the client should still reject the connection.

METHOD OnAssociateCnf
VAR_INPUT
    ipAA   : I_ScsmAssociationClass;
    eError : E_AcsiServiceError;
END_VAR
VAR
END_VAR

sLastAbortReason:= '';
sLastErrorResult:= '';

bAccepted:= FALSE;
sMechanismName:= '';
sPassword:= '';
sRespondingPass:= '';
eAareResult:= E_ACSE_AareResult.Accepted;
eAareDiagnostic:= E_ACSE_AareDiagnostic.Null;
eAbrtDiagnostic:= E_ACSE_AbrtDiagnostic.Null;
IF (ipAA <> 0) AND_THEN (ipAA.ipAuthentication <> 0) THEN
    IF ipAA.ipAuthentication.GetVerifyResult(bAccepted=>bAccepted,
                            sMechanismName=>sMechanismName,
                            sPassword=>sPassword,
                            sRespondingPass=>sRespondingPass,
                            eResult=>eAareResult,
                            eDiagnostic=>eAareDiagnostic,
                            eAbrtDiagnostic=>eAbrtDiagnostic)
    THEN
        IF bAccepted THEN
            IF (sPassword = 'GeneralPass')
            OR_ELSE (sPassword = 'AnotherPass') THEN
                ;
            ELSIF (sPassword = 'MorePass') THEN
                bSuccess:= ipAA.ipAuthentication.Reject();
            ELSE
                ;
            END_IF
        ELSE
            IF (sPassword = 'FurtherPass') THEN
                bSuccess:= ipAA.ipAuthentication.Accept(sRespondingPass:='RespondingPass');
            ELSE
                ;
            END_IF
        END_IF
        
        ipAA.ipAuthentication.GetVerifyResult(bAccepted=>bAccepted,
                            sMechanismName=>sMechanismName,
                            sPassword=>sPassword,
                            sRespondingPass=>sRespondingPass,
                            eResult=>eAareResult,
                            eDiagnostic=>eAareDiagnostic,
                            eAbrtDiagnostic=>eAbrtDiagnostic);
    ELSE
        ;
    END_IF
END_IF

As with the "OnAssociateInd" event handling routine of the server described above, the client application can also access the "ipAuthentication" interface pointer of type I_ScsmAuthenticationClass via the "ipAA" input variable of the "OnAssociateCnf" event handling routine. With the "GetVerifyResult" method call, the client application can query the result of the internal verification and modify it if necessary.

Test

To be able to carry out a simple test, the network address (IPv4 address) of the TwinCAT IEC 61850 server must first be adapted in the server and client sample project. If the client and server sample project is downloaded and started on two TwinCAT target systems, the client will use the "GeneralPass" password for authentication and establish a connection to the server. The password used is selected in the global variable list "TcTelecontrol" of the client project using the index variable "passIndex" from the array "passList". In the sample, the variable "passIndex" has the initial value "0" and selects the first password from the "passList" array with the value "GeneralPass".

Next, you can set the password index variable "passIndex" to the value "2" and the Boolean variable "fbIEDClient._bAbort" to the value "TRUE" in online mode, for example (see image below).

Authentication, negotiation of supported services and optional communication parameters 4:

The client will first close the old connection and then establish a new one with the password "AnotherPass". In this way, you can try out the different passwords implemented in the sample. If the "passIndex" value is 1 or 5, for example, the server will reject the connection request. Please note that it may take a few seconds before a new connection can be established. By default, the minimum time for re-establishing a connection is set to 45 seconds in the configuration settings "fbIEDClient.fbConnection.settings.tConnect".