This section describes examples of how to use the FipCore library. All examples are based on the FipLabs design model 2sta_worldfip_xxx.labpro. The XML station configuration files associated are sta0_worldfip_xxx.xml [Station 0 - Tank A] and sta1_worldfip_xxx.xml [Station 1 - Tank B].
These files are located by default at the following paths:
To test this program, open a terminal and enter the following commands:
On Windows
$ cd C:\Program Files (x86)\Exoligent\WorldFipTools\6.x\bin\
$ fipcore_rawframe.exe 1 1 0 2
On Linux
$ cd /usr/local/Exoligent/WorldFipTools/6.x/bin/
$ ./fipcore_rawframe 1 1 0 2
Note: In the example, we attach a PCI/PCIe (1) FipArbiter device (Index 1) with the FIP Station (Addr 0) XML configuration file for a 2.5Mbps (2) FIP network.
Windows console - Raw Frame example
Mnemonic Exchanges
This example is based on the above example (Raw Frame Exchanges).
However, instead of manipulating the raw FIP frames as before, the aim here is to read/write targeted and formatted data from/to the FIP network using the mnemonics (called also tags).
Here we present the code for the FIP Node with the address 0.
Tank A station produces the tags: TAVolume, TAPumpTemperature, TAPumpAlarm, TAPumpAmps, TAPumpPressure and TANotification.
Tank A station consumes the tags: TBVolume, TBPumpTemperature, TBPumpAlarm, TBPumpAmps, TBPumpPressure.
To test this program, open a terminal and enter the following commands:
On Windows
$ cd C:\Program Files (x86)\Exoligent\WorldFipTools\6.x\bin\
$ fipcore_mnemo.exe 1 1 0 2
On Linux
$ cd /usr/local/Exoligent/WorldFipTools/6.x/bin/
$ ./fipcore_mnemo 1 1 0 2
Note: In the example, we attach a PCI/PCIe (1) FipArbiter device (Index 1) with the FIP Station (Addr 0) XML configuration file for a 2.5Mbps (2) FIP network.
Windows console - Mnemonic example
PT100 Sensor Example (Adam-5000)
This example is based on the above example (Mnemonic Exchanges).
Here, we focuse on retrieve the value of a temperature sensor (PT100) and attach its value to a FIP mnemonic. We use an AdvantechADAM-5000 I/O Rack with the ADAM-5013 (3-ch RTD Input) module that communicates with a serial port (RS-232).
Here we present the code for the FIP Node with the address 0.
Tank A station produces the TAPumpTemperature tag.
To test this program, open a terminal and enter the following commands:
On Windows
$ cd C:\Program Files (x86)\Exoligent\WorldFipTools\6.x\bin\
$ fipcore_pt100.exe 1 1 0 2
On Linux
$ cd /usr/local/Exoligent/WorldFipTools/6.x/bin/
$ sudo ./fipcore_pt100 1 1 0 2
Note: In the example, we attach a PCI/PCIe (1) FipArbiter device (Index 1) with the FIP Station (Addr 0) XML configuration file for a 2.5Mbps (2) FIP network.
To display the pt100 sensor measurement, here we use a FipWatcher device with the FipLabs GUI (FipWatcher tab). The curve below shows a measurement result over ~24 hours :
This example is based on the above example (Mnemonic Exchanges).
The main difference is that we want here to expose the state and context of the FIP node to a remote system (SCADA, HMI ...).
To do this, the FipCore library has embedded functions to start an OPC Unified Architecture (OPC UA) server inside your program.
For more information about OPC UA, see link: OPC Foundation.
In our example, we need to continue to manipulate our FIP communication locally using FipCore library functions, so we will use a non-blocking architecture for our server.
These functions must be used when the FIP communication is in operation (ie after calling the fipcore_start_network function and before calling the fipcore_stop_network function).
To test this example, open a terminal and enter the following commands:
On Windows
$ cd C:\Program Files (x86)\Exoligent\WorldFipTools\6.x\bin\
$ fipcore_opcua_nonblocking.exe 1 1 0 2
On Linux
$ cd /usr/local/Exoligent/WorldFipTools/6.x/bin/
$ ./fipcore_opcua_nonblocking 1 1 0 2
Note: In the example, we attach a PCI/PCIe (1) FipArbiter device (Index 1) with the FIP Station (Addr 0) XML configuration file for a 2.5Mbps FIP network.
Windows console - OPC UA non-blocking example
Once the sample is started, you can connect an OPC UA client to the following address: opc.tcp://localhost:16664
UAExpert Example - OPC UA client
Ignition SCADA Example - OPC UA client
OPC UA - Blocking Mode
The FipCore library has embedded functions to start an OPC Unified Architecture (OPC UA) server inside your program.
For more information about OPC UA, see link: OPC Foundation.
In this example, we use the OPC UA server in blocking mode. It requires only 1 function : fipcore_opcua_run
In this mode, it is not possible to switch locally on the FIP network using the FipCore functions. All manipulations will be done from the OPC client.
The execution of the program remains blocked in this function until the opc_is_running boolean is set to false.
To test this example, open a terminal and enter the following commands:
On Windows
$ cd C:\Program Files (x86)\Exoligent\WorldFipTools\6.x\bin\
$ fipcore_opcua_blocking.exe 1 1 0 2
On Linux
$ cd /usr/local/Exoligent/WorldFipTools/6.x/bin/
$ ./fipcore_opcua_blocking 1 1 0 2
Note: In the example, we attach a PCI/PCIe (1) FipArbiter device (Index 1) with the FIP Station (Addr 0) XML configuration file for a 2.5Mbps FIP network.
Windows console - OPC UA blocking example
Once the sample is started, you can connect an OPC UA client to the following address: opc.tcp://localhost:16664
OPC UA - Control Access & Security Policies
We will see here how to secure the OPC-UA server embedded into the FipCore library.
For more information about the different security layers of OPC-UA, please refer to this great documentation from CERN: OPC-UA Security.
OPC-UA security is based on x509 certificates. The OPC-UA specification provides security at different levels:
[Certificates] : Clients can only create sessions with trusted servers. Servers only accept sessions from trusted clients.
[Security Policies] : Session traffic can be "Signed", "Signed and Encrypted" or "Neither".
[Control Access] : Clients can pass a token to the server which identifies a user.
1 - Certificates - Creation and Use
Certificates establish a trusting relationship between client and server. We will see in this part how to create our own self-signed certificate.
WARNING: A self-signed certificate is a certificate that is not signed by an official certificate authority (CA). It is not advisable to use this method for on-site deployment. This method is only used to illustrate the mechanism in this tutorial.
Here we are on GNU/Linux, and we use openssl to create our own certificate authority (CA).
The commands below create the following:
CA's key: This public and private key pair will be contained into the Certificate Authority (CA).
Certificate Authority (CA): This is a trusted entity which also has its own public and private keys and a certificate (signed by itself, or self-signed). By "trusted" it is meant that clients willingly and knowingly install the CA's certificate (CA's information and public key) in their software.
Certificate Revocation List (CRL): This file contains the list of certificates revoked by a CA.
Shell language - CA certificate creation
The CA and CRL files have been converted to DER format. This is the most common format for the OPC-UA applications.
ca.crt.der
ca.crl.der
These two files will be necessary for the OPC-UA clients that will connect to the server integrated into the FipCore library.
In this example we use the UA Expert client. To install the CA's certificate and CRL for this client:
Open UA Expert.
In the user interface go to Settings -> Manage Certificates....
Click on the Open Certificate Location button. This action opens the location where to copy the files.
Copy ca.crt.der file to $SOME_PATH/unifiedautomation/uaexpert/PKI/trusted/certs/ folder.
Copy ca.crl.der file to $SOME_PATH/unifiedautomation/uaexpert/PKI/trusted/crl/ folder.
The OPC client is now ready to accept connections signed by this new CA certificate.
We will now create the OPCUA server certificate which will be used by FipCore library.
The steps of creation are:
Create the server public and private key pair.
Create an exts.txt which contain the Certificate Extensions required by the OPC UA standard.
Create its own unsigned certificate, and with it a Certificate Sign Request.
Give the Certificate Sign Request to the CA to sign it.
Shell language - Own unsigned certificate creation
We create the exts.txt file which contains the required Certificate Extensions used by CA to be able to sign.
We can now sign the server's Certificate Sign Request using the CA and the Certificate Extensions file.
Shell language - Own certificate signing
Output files:
server.key.der
server.crt.der
We can now pass these fields to the FipCore library. To do this, fill in the private_key_der and server_certificate_der fields of the OPCUA_USERCONF structure with the paths to the respective files server.key.der and server.crt.der.
In addition, the UA Expert client must be registered by the server in order to be considered as trust. To do this, the "trust_list_folder" field must point to a folder containing the client's certificate:
Here we copy $SOME_PATH/unifiedautomation/uaexpert/PKI/own/certs/uaexpert.der file to our app folder: certificates/server/trust/.
C language - Configuring OPC-UA server certificates
At this stage, our server is now recognized as trustworthy by our OPC-UA client and vice-versa.
We are now going to see the setting of the Security Policies.
2 - Security Policies - Encryption
OPC UA defines Security Policies and a unique URI for each policy:
Sign&Encrypt: All messages are signed and encrypted.
WARNING: For security reasons, the Security Policies Basic128Rsa15 and None as well as the Message Security Mode None should be deactivated by default.
These fields are configurable via the OPCUA_USERCONF structure of the FipCore library.
C language - Configuring OPC-UA server security policies
Once the server started, you can connect UA Expert client to the following address: opc.tcp://localhost:16664. The new security policies are now visible.
3 - Control Access - Login (Username/Password)
It is also possible to protect connections to the OPC-UA server with a Username Identity Token. The user must then identify himself with an username and a password registered in the server.
To do this, first you have to disable the Anonymous Identity Token connection via the disable_anonymous field of the OPCUA_USERCONF structure. Then you have to register the username/password pairs via OPCUA_LOGIN structures.
C language - Configuring Username Identity Tokens
It is now no longer possible to connect anonymously to the server. The user has to enter its credentials.
To test this example, open a terminal and enter the following commands:
On Windows
$ cd C:\Program Files (x86)\Exoligent\WorldFipTools\6.x\bin\
$ fipcore_opcua_security.exe 1 1 0 2
On Linux
$ cd /usr/local/Exoligent/WorldFipTools/6.x/bin/
$ ./fipcore_opcua_security 1 1 0 2
Note: In the example, we attach a PCI/PCIe (1) FipArbiter device (Index 1) with the FIP Station (Addr 0) XML configuration file for a 2.5Mbps FIP network.
The previous examples use a polling method to get the FIP network events. Another way available for PCI/PCIe devices type is the use of the hardware interrupt (IRQ) of the board to be alerted via a user callback function.
WARNING : USB FIP Arbitrator device does not support this method.
To test this example, open a terminal and enter the following commands:
On Windows
$ cd C:\Program Files (x86)\Exoligent\WorldFipTools\6.x\bin\
$ fipcore_irq.exe 1 1 0 2
On Linux
$ cd /usr/local/Exoligent/WorldFipTools/6.x/bin/
$ ./fipcore_irq 1 1 0 2
Note: In the example, we attach a PCI/PCIe (1) FipArbiter device (Index 1) with the FIP Station (Addr 0) XML configuration file for a 2.5Mbps FIP network.